GitLab CI/CD

时间 2020-02-06

标签 gitlab 栏目 Git 繁體版

原文原文链接

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

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

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

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

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

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

1. GitLab CI/CD 介绍github

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

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

Continuous Integration（持续集成）api

假设一个应用程序，其代码存储在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:
 script:
 - 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 页面

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

回顾一下：

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

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

三、最后，配置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:
 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

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