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 显示：
最初，如果呈现任何问题，能够轻松地回滚所有更改：
根本 CI/CD 工作流程
一旦你将提交推送到近程仓库的分支上，那么你为该我的项目设置的 CI/CD 管道将会被触发。GitLab CI/CD 通过这样做：
- 运行自动化脚本（串行或并行）代码 Review 并取得批准
- 构建并测试你的利用
- 就像在你本机中看到的那样，应用 Review Apps 预览每个合并申请的更改
- 代码 Review 并取得批准
- 合并 feature 分支到默认分支，同时主动将此次更改部署到生产环境
- 如果呈现问题，能够轻松回滚
通过 GitLab UI 所有的步骤都是可视化的。
深刻理解 CI/CD 根本工作流程
如果咱们深入研究根本工作流程，则能够在 DevOps 生命周期的每个阶段看到 GitLab 中可用的性能，如下图所示：
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 简略又间接。
查看 Pipeline 和 jobs 的状态
在胜利配置 Runner 当前，你应该能够看到你最近的提交的状态。
为了查看所有 jobs，你能够去 Pipelines ➔ Jobs 页面。
通过点击作业的状态，你能够看到作业运行的日志。
回顾一下：
- 首先，定义 .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 的我的项目模板来创立一个新我的项目。
给我的项目起一个名字，并确保它是私有的。
从 GitLab 模板创立 Kubernetes 集群
点击 Add Kubernetes cluster 按钮，或者 Operations > Kubernetes。
装置 Helm，Ingress 和 Prometheus。
启用 Auto DevOps（可选）
Auto DevOps 默认是启用的。
导航栏 Settings > CI/CD > Auto DevOps。
勾选 Default to Auto DevOps pipeline。
最初抉择部署策略。
一旦你曾经实现了以上所有的操作，那么一个新的 Pipeline 将会被主动创立。为了查看 Pipeline，能够去 CI/CD > Pipelines。
部署利用
到目前为止，你应该看到管道正在运行，然而它到底在运行什么呢？
管道外部分为 4 个阶段，咱们能够查看每个阶段有几个作业在运行，如下图：
构建 -> 测试 -> 部署 -> 性能测试
当初，利用曾经胜利部署，让咱们通过浏览器查看。
首先，导航到 Operations > Environments。
在 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
原文链接：https://www.cnblogs.com/cjsbl…