GitLab CI/CD

分类：Git作者：编程之家用户

GitLab CI/CD 是一个内置在GitLab中的工具，用于通过持续方法进行软件开发：

  • Continuous Integration (CI)  持续集成
  • Continuous Delivery (CD)     持续交付
  • Continuous Deployment (CD)   持续部署

持续集成的工作原理是将小的代码块推送到Git仓库中托管的应用程序代码库中，并且每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。

持续交付和部署相当于更进一步的CI，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。

这些方法使得可以在开发周期的早期发现bugs和errors，从而确保部署到生产环境的所有代码都符合为应用程序建立的代码标准。

GitLab CI/CD 由一个名为 .gitlab-ci.yml 的文件进行配置，改文件位于仓库的根目录下。文件中指定的脚本由GitLab Runner执行。

1. GitLab CI/CD 介绍

软件开发的持续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码，他们几乎不需要人工干预，甚至根本不需要干预。 

它涉及到在每次小的迭代中就不断地构建、测试和部署代码更改，从而减少了基于已经存在bug或失败的先前版本开发新代码的机会。

Continuous Integration（持续集成）

假设一个应用程序，其代码存储在GitLab的Git仓库中。开发人员每天都要多次推送代码更改。对于每次向仓库的推送，你都可以创建一组脚本来自动构建和测试你的应用程序，从而减少了向应用程序引入错误的机会。这种做法称为持续集成，对于提交给应用程序（甚至是开发分支）的每项更改，它都会自动连续进行构建和测试，以确保所引入的更改通过你为应用程序建立的所有测试，准则和代码合规性标准。 

Continuous Delivery（持续交付）

持续交付是超越持续集成的更进一步的操作。应用程序不仅会在推送到代码库的每次代码更改时进行构建和测试，而且，尽管部署是手动触发的，但作为一个附加步骤，它也可以连续部署。此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发以必输此次变更。

Continuous Deployment（持续部署）

与持续交付类似，但不同之处在于，你无需将其手动部署，而是将其设置为自动部署。完全不需要人工干预即可部署你的应用程序。 

1.1. GitLab CI/CD 是如何工作的

为了使用GitLab CI/CD，你需要一个托管在GitLab上的应用程序代码库，并且在根目录中的.gitlab-ci.yml文件中指定构建、测试和部署的脚本。

在这个文件中，你可以定义要运行的脚本，定义包含的依赖项，选择要按顺序运行的命令和要并行运行的命令，定义要在何处部署应用程序，以及指定是否 要自动运行脚本或手动触发脚本。 

为了可视化处理过程，假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同。

一旦你已经添加了.gitlab-ci.yml到仓库中，GitLab将检测到该文件，并使用名为GitLab Runner的工具运行你的脚本。该工具的操作与终端类似。

这些脚本被分组到jobs，它们共同组成一个pipeline。一个最简单的.gitlab-ci.yml文件可能是这样的：

before_script: 
  - apt-get install rubygems ruby-dev -y 

run-test: 
  script: 
    - ruby --version 6

before_script属性将在运行任何内容之前为你的应用安装依赖，一个名为run-test的job（作业）将打印当前系统的Ruby版本。二者共同构成了在每次推送到仓库的任何分支时都会被触发的pipeline（管道）。

GitLab CI/CD不仅可以执行你设置的job，还可以显示执行期间发生的情况，正如你在终端看到的那样：

为你的应用创建策略，GitLab会根据你的定义来运行pipeline。你的管道状态也会由GitLab显示： 

最后，如果出现任何问题，可以轻松地回滚所有更改：

 

1.2. 基本 CI/CD 工作流程

一旦你将提交推送到远程仓库的分支上，那么你为该项目设置的CI/CD管道将会被触发。GitLab CI/CD 通过这样做： 

  • 运行自动化脚本（串行或并行） 代码Review并获得批准
    • 构建并测试你的应用
    • 就像在你本机中看到的那样，使用Review Apps预览每个合并请求的更改　 
  • 代码Review并获得批准
  • 合并feature分支到默认分支，同时自动将此次更改部署到生产环境
  • 如果出现问题，可以轻松回滚

通过GitLab UI所有的步骤都是可视化的 

 

1.3. 深入了解CI/CD基本工作流程

如果我们深入研究基本工作流程，则可以在DevOps生命周期的每个阶段看到GitLab中可用的功能，如下图所示：

1. Verify

  • 通过持续集成自动构建和测试你的应用程序
  • 使用GitLab代码质量（GitLab Code Quality）分析你的源代码质量
  • 通过浏览器性能测试（Browser Performance Testing）确定代码更改对性能的影响
  • 执行一系列测试，比如Container Scanning,Dependency Scanning,JUnit tests
  • 用Review Apps部署更改，以预览每个分支上的应用程序更改 

2. Package

  • 用Container Registry存储Docker镜像
  • 用NPM Registry存储NPM包
  • 用Maven Repository存储Maven artifacts
  • 用Conan Repository存储Conan包 

3. Release

  • 持续部署，自动将你的应用程序部署到生产环境
  • 持续交付，手动点击以将你的应用程序部署到生产环境
  • 用GitLab Pages部署静态网站
  • 仅将功能部署到一个Pod上，并让一定比例的用户群通过Canary Deployments访问临时部署的功能（PS：即灰度发布）
  • 在Feature Flags之后部署功能
  • 用GitLab Releases将发布说明添加到任意Git tag
  • 使用Deploy Boards查看在Kubernetes上运行的每个CI环境的当前运行状况和状态
  • 使用Auto Deploy将应用程序部署到Kubernetes集群中的生产环境 

使用GitLab CI/CD，还可以：

  • 通过Auto DevOps轻松设置应用的整个生命周期
  • 将应用程序部署到不同的环境
  • 安装你自己的GitLab Runner
  • Schedule pipelines
  • 使用安全测试报告（Security Test reports）检查应用程序漏洞 

2. GitLab CI/CD 快速开始

.gitlab-ci.yml文件告诉GitLab Runner要做什么。一个简单的管道通常包括三个阶段：build、test、deploy

管道在 CI/CD > Pipelines 页面

2.1. 创建一个 .gitlab-ci.yml 文件

通过配置.gitlab-ci.yml文件来告诉CI要对你的项目做什么。它位于仓库的根目录下。

仓库一旦收到任何推送，GitLab将立即查找.gitlab-ci.yml文件，并根据文件的内容在Runner上启动作业。

下面是一个Ruby项目配置例子：

image: "ruby:2.5" before_script: - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs - ruby -v - which ruby - gem install bundler --no-document - bundle install --jobs $(nproc) "${FLAGS[@]}" rspec: script: - bundle exec rspec rubocop: - bundle exec rubocop

上面的例子中，定义里两个作业，分别是 rspec 和 rubocop，在每个作业开始执行前，要先执行before_script下的命令 

2.2. 推送 .gitlab-ci.yml 到 GitLab

git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml" 
git push origin master

2.3. 配置一个Runner

在GitLab中，Runner运行你定义在.gitlab-ci.yml中的作业（job）

一个Runner可以是一个虚拟机、物理机、docker容器，或者一个容器集群

GitLab与Runner之间通过API进行通信，因此只需要Runner所在的机器有网络并且可以访问GitLab服务器即可

你可以去 Settings ➔ CI/CD 看是否已经有Runner关联到你的项目，设置Runner简单又直接 

 

2.4. 查看 pipeline 和 jobs的状态

在成功配置Runner以后，你应该可以看到你最近的提交的状态 

为了查看所有jobs，你可以去 Pipelines ➔ Jobs 页面 

通过点击作业的状态，你可以看到作业运行的日志

 

回顾一下：

1、首先，定义.gitlab-ci.yml文件。在这个文件中就定义了要执行的job和命令

2、接着，将文件推送至远程仓库

3、最后，配置Runner，用于运行job

3. Auto DevOps

Auto DevOps 提供了预定义的CI/CD配置，使你可以自动检测，构建，测试，部署和监视应用程序。借助CI/CD最佳实践和工具，Auto DevOps旨在简化成熟和现代软件开发生命周期的设置和执行。

借助Auto DevOps，软件开发过程的设置变得更加容易，因为每个项目都可以使用最少的配置来完成从验证到监视的完整工作流程。只需推送你的代码，GitLab就会处理其他所有事情。这使得启动新项目更加容易，并使整个公司的应用程序设置方式保持一致。

下面这个例子展示了如何使用Auto DevOps将GitLab.com上托管的项目部署到Google Kubernetes Engine

示例中会使用GitLab原生的Kubernetes集成，因此不需要再单独手动创建Kubernetes集群

本例将创建并部署一个从GitLab模板创建的应用

3.1. 从GitLab模板创建项目

在创建Kubernetes集群并将其连接到GitLab项目之前，你需要一个Google Cloud Platform帐户

下面使用GitLab的项目模板来创建一个新项目

给项目起一个名字，并确保它是公有的

3.2. 从GitLab模板创建Kubernetes集群

点击 Add Kubernetes cluster 按钮，或者 Operations > Kubernetes

安装Helm,Ingress,和 Prometheus

 

3.3. 启用Auto DevOps (可选)

Auto DevOps 默认是启用的。

导航栏 Settings > CI/CD > Auto DevOps

勾选 Default to Auto DevOps pipeline

最后选择部署策略

一旦你已经完成了以上所有的操作，那么一个新的 pipeline 将会被自动创建。为了查看pipeline，可以去 CI/CD > Pipelines 

3.4. 部署应用

到目前为止，你应该看到管道正在运行，但是它到底在运行什么呢？ 

管道内部分为4个阶段，我们可以查看每个阶段有几个作业在运行，如下图：

构建 -> 测试 -> 部署 -> 性能测试

现在，应用已经成功部署，让我们通过浏览器查看。

首先，导航到 Operations > Environments 

在Environments中，可以看到部署的应用的详细信息。在最右边有三个按钮，我们依次来看一下：

第一个图标将打开在生产环境中部署的应用程序的URL。这是一个非常简单的页面，但重要的是它可以正常工作！ 

紧挨着第二个是一个带小图像的图标，Prometheus将在其中收集有关Kubernetes集群以及应用程序如何影响它的数据（在内存/ CPU使用率，延迟等方面）

第三个图标是Web终端，它将在运行应用程序的容器内打开终端会话。 

4. Examples

使用GitLab CI/CD部署一个Spring Boot应用 

示例 .gitlab-ci.yml

image: java:8 stages: - build - deploy before_script - chmod +x mvnw build: stagebuild script./mvnw package artifacts paths - target/demo-0.0.1-SNAPSHOT.jar productiondeploy - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io - ./cf push only - master

5. Docs

https://about.gitlab.com/solutions/kubernetes/

https://docs.gitlab.com/ee/ci/README.html

https://docs.gitlab.com/ee/ci/introduction/

https://docs.gitlab.com/ee/topics/autodevops/

https://docs.gitlab.com/ee/ci/examples/README.html

 

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。

相关推荐

Git安装和使用
Git安装和使用 Git安装和使用 刚开始用git的小白适用，，转自http://www.cnblogs.com/qijunjun/p/7137207.html 实际项目开发中，我们经常会用一些版本控制器来托管自己的代码，今天就来总结下Git的相关用法，废话不多说，直接开写。 目的：通过Git管理g
fatal: remote origin already exists.解决方法
fatal: remote origin already exists.解决方法 第一个问题git remote add origin**************fatal: remote origin already exists.（报错远程起源已经存在。）上网查了下，有很多小白遇到过这个问题，以
git常用命令（二）查看历史记录 git log [--pretty=oneline] [ --oneline] / reflog
git常用命令（二）查看历史记录 git log [--pretty=oneline] [ --oneline] / reflog Eniac-W 于 2020-10-18 18:12:38 发布 2368 收藏 3分类专栏： git 文章标签： git版权 git专栏收录该内容10 篇文章0 订阅
git之如何把本地文件上传到远程仓库的指定位置
git之如何把本地文件上传到远程仓库的指定位置 git专栏收录该内容2 篇文章0 订阅订阅专栏2018.11.26添加内容： 对于自己的仓库，我们建议将远程仓库通过clone命令把整个仓库克隆到本地的某一路径下。这样的话我们从本地向远程仓库提交代码时，就可以直接把需要提交的文件拖到我们之前克隆下来的
代码规范之 lint-staged
代码规范之 lint-staged 在代码提交之前，进行代码规则检查能够确保进入git库的代码都是符合代码规则的。但是整个项目上运行lint速度会很慢，lint-staged能够让lint只检测暂存区的文件，所以速度很快。 安装与配置 安装husky和lint-staged： yarn add hu
git怎样还原修改
方法：1、文件没有git操作时用“git checkout--文件”命令还原；2、文件提交到暂存区时用“git reset HEAD”命令回退当前版本还原；3、文件提交到仓库区时用“git reset HEAD^”命令回退上一个版本还原。 本文操作环境：Windows10系统、Git2.30.0版、
使用Git将本地文件提交到远程仓库
使用Git将本地文件提交到远程仓库 一 操作准备条件： git远程仓库已经建好了，本地文件已经存在了，现在要将本地代码推到git远程仓库保存。 解决办法如下： 1、（先进入项目文件夹）通过命令 git init 把这个目录变成git可以管理的仓库 git init 2、把文件添加到版本库中，使用命令
GitHub克隆代码到本地全教程
GitHub克隆代码到本地全教程 因为工作原因更换电脑，想要从GitHub上拉取代码的话需要重新配置ssh keys，时间过的久了怕忘记就把步骤给记录下来。 具体步骤： 1.安装git 这我就不说了 2.在TortoiseGit的安装文件中找到 puttygen.exe应用程序 ，默认应该都是 ：C
github上传项目的时候报出git@github.com: Permission denied (publickey). fatal: Could not read from remote repo
github上传项目的时候报出git@github.com: Permission denied (publickey). fatal: Could not read from remote repo 前言 会不会有程序员小伙伴在刚开始使用github的时候上传项目的时候困难重重，但是又基于自己本身
git查看历史和根据历史里面的id切换
查看历史 git log --pretty=onelinegit log （然后一直按enter键） 一个是切换根据历史里面的id切换git checkout ID git log 需要不断按enter键出来历史提交记录 git log --pretty=oneline 是直接出来历史记录
Git工作原理及常用命令
Git工作原理及常用命令 欧怼怼发布于 2020-12-08 git介绍 git（读音/ɡɪt/）是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。 git
git----git提交项目的具体流程
git git提交项目的具体流程 git项目流程：以下主要有3个角色：负责人、成员A、成员B（若负责人也要修改代码，则负责人同时兼任2个角色：负责人、成员） 主要负责人：搭建项目架构且提交到git上1.github官网登录后，新建仓库，生成地址url,复制线上仓库.git结尾的地址url2.在一个空
git上传项目全部流程
git上传项目全部流程 一、下载git 进入网址：https://git-scm.com/downloads； 点击中的Download 2.16.0 for Windows; 在中选择蓝色字段点击，根据电脑64或32位选择适合的下载，点击即可进行下载，下载完成后傻瓜式安装，一直点击下一步即可完成安
Your local changes to the following files would be overwritten by checkout问题的解决
Your local changes to the following files would be overwritten by checkout问题的解决 于 2018-07-17 11:38:27 发布 Git 的本地版本管理有三个部分 名称	说明工作区（Working Directory）	
Git配置SSH Keys步骤
Git配置SSH Keys步骤使用教程 1.若是首次安装使用git，先配置用户名称和邮箱（如果有就不需要配置） 打开Git Bash，输入 git config --global user.name "姓名"git config --global user.email &quot
git上传项目
基本配置完成，接下来就是上传你要上传的项目了。 1、初始化git 进入你要上传的项目的文件夹，在文件夹内鼠标右击，选择“Git Bash Here”打开git命令行，输入： $ git init 目的是初始化git，并且会创建个“.git”文件夹，里面有个“config”就是用来保存远程厂库路径地址
gitee如何上传代码
本篇内容主要讲解“gitee如何上传代码”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“gitee如何上传代码”吧! ...
从gitee上下的代码如何用
这篇“从gitee上下的代码如何用”文章的知识点大部分人都不太理解，所以小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这...
gitee如何下载仓库里的项目
这篇文章主要介绍“gitee如何下载仓库里的项目”，在日常操作中，相信很多人在gitee如何下载仓库里的项目问题上存在疑惑，小编查阅了各式资料，整理出简单好用的...
怎么在Gitee上更新代码
本篇内容主要讲解“怎么在Gitee上更新代码”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么在Gitee上更新代...
pythonJavaScriptjavaHTMLPHPreactjsC#AndroidCSSNode.jssqlrpython-3.xMysqLjQueryc++pandasFlutterangularIOSdjangolinuxswifttypescript路由器JSON路由器设置无线路由器h3c华三华三路由器设置华三路由器电脑软件教程arraysdocker软件图文教程Cvue.jslaravelspring-boot