用 GitLab 作 CI/CD 是什么感受，太强了

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 执行。

GitLab CI/CD 介绍

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

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

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

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

• Continuous Deployment（持续部署），与持续交付相似，但不一样之处在于，你无需将其手动部署，而是将其设置为自动部署。彻底不须要人工干预便可部署你的应用程序。

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 显示：

[外链图片转存中...(img-9vXw94DB-1610462909494)]

最后，若是出现任何问题，能够轻松地回滚全部更改：

基本 CI/CD 工做流程

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

• 运行自动化脚本（串行或并行） 代码Review并得到批准

  • 构建并测试你的应用

  • 就像在你本机中看到的那样，使用 Review Apps 预览每一个合并请求的更改

• 代码 Review 并得到批准

• 合并 feature 分支到默认分支，同时自动将这次更改部署到生产环境

• 若是出现问题，能够轻松回滚

经过 GitLab UI 全部的步骤都是可视化的 。

深刻了解CI/CD基本工做流程

若是咱们深刻研究基本工做流程，则能够在 DevOps 生命周期的每一个阶段看到 GitLab 中可用的功能，以下图所示：

[外链图片转存中...(img-ynLeJIxi-1610462909523)]

Verify：

• 经过持续集成自动构建和测试你的应用程序

• 使用 GitLab 代码质量（GitLab Code Quality）分析你的源代码质量

• 经过浏览器性能测试（Browser Performance Testing）肯定代码更改对性能的影响

• 执行一系列测试，好比 Container Scanning，Dependency Scanning，JUnit tests

• 用 Review Apps 部署更改，以预览每一个分支上的应用程序更改

Package：

• 用 Container Registry 存储 Docker 镜像

• 用 NPM Registry 存储 NPM 包

• 用 Maven Repository 存储 Maven artifacts

• 用 Conan Repository 存储 Conan 包

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）检查应用程序漏洞

GitLab CI/CD 快速开始

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

管道在 CI/CD > Pipelines 页面。

建立一个 .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:  
   script:  
     - bundle exec rubocop

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

推送 .gitlab-ci.yml 到 GitLab

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

配置一个 Runner

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

一个 Runner 能够是一个虚拟机、物理机、Docker 容器，或者一个容器集群。

GitLab 与 Runner 之间经过 API 进行通讯，所以只须要 Runner 所在的机器有网络而且能够访问 GitLab 服务器便可。

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

[外链图片转存中...(img-rCvpV5DY-1610462909528)]

查看 Pipeline 和 jobs 的状态

在成功配置 Runner 之后，你应该能够看到你最近的提交的状态。

为了查看全部 jobs，你能够去 Pipelines ➔ Jobs 页面。

[外链图片转存中...(img-kD0oiY6J-1610462909535)]

经过点击做业的状态，你能够看到做业运行的日志。

回顾一下：

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

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

• 最后，配置 Runner，用于运行 job

Auto DevOps

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

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

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

示例中会使用 GitLab 原生的 Kubernetes 集成，所以不须要再单独手动建立 Kubernetes 集群。

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

从 GitLab 模板建立项目

在建立 Kubernetes 集群并将其链接到 GitLab 项目以前，你须要一个 Google Cloud Platform 账户。

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

[外链图片转存中...(img-HZO9EViH-1610462909544)]

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

[外链图片转存中...(img-vZI36UiI-1610462909548)]

从 GitLab 模板建立 Kubernetes 集群

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

[外链图片转存中...(img-EdGVDGxG-1610462909562)]

[外链图片转存中...(img-bZeS2LFK-1610462909567)]

安装 Helm，Ingress 和 Prometheus。

启用 Auto DevOps（可选）

Auto DevOps 默认是启用的。

导航栏 Settings > CI/CD > Auto DevOps。

勾选 Default to Auto DevOps pipeline。

最后选择部署策略。

[外链图片转存中...(img-WE6BVbH6-1610462909578)]

一旦你已经完成了以上全部的操做，那么一个新的 Pipeline 将会被自动建立。为了查看 Pipeline，能够去 CI/CD > Pipelines。

[外链图片转存中...(img-0qKffSoF-1610462909583)]

部署应用

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

管道内部分为4个阶段，咱们能够查看每一个阶段有几个做业在运行，以下图：

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

[外链图片转存中...(img-alHeune8-1610462909587)]

如今，应用已经成功部署，让咱们经过浏览器查看。

首先，导航到 Operations > Environments。

[外链图片转存中...(img-nWpHQ1YO-1610462909591)]

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

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

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

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

Examples

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

示例 .gitlab-ci.yml

image: java:8  

 stages:  
   - build  
   - deploy  

 before\_script:  
   - chmod +x mvnw  

 build:  
   stage: build  
   script: ./mvnw package  
   artifacts:  
     paths:  
       - target/demo-0.0.1-SNAPSHOT.jar  

 production:  
   stage: deploy  
   script:  
   - 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

原文连接：http://www.javashuo.com/article/p-upfenqlj-dx.html