背景
如果您还没有使用过任何 CI / CD 工具来进行过软件工程的持续集成的话，那以下这些问题可能会在你日常的工作中经常遇到。
- 如果应用是使用编译类的语言进行开发的，那么如何保证多平台版本的发布？
- 应用发布时，经常需要我们手动登录到服务器上先
cd /you/application/directory然后在git pull, 如果是首次发布还需要更改 nginx 配置文件。应用发布完成后有可能发现环境缺失。经常会出现为什么在我本地好好的？怎么更新到线上就各种问题呢？ - 也许刚开始时应用并不复杂，部署也简单，可随着后续应用的持续迭代。应用本身或作为辅助应用的一些程序会使用到不同环境。于是我们不得不每次更新之前都需要小心在小心。
- 如果有多个同事使用同一个环境，没准那天他把环境改了。导致应用不能使用了…
- ….
从以上的行为中您不难发现，目前我们的应用处于刀耕火种的时候。不管做什么都需要我们去人工手动的去进行干预。无形中增加了犯错的机率。那有没有什么办法去解决这些问题呢？最理想的状态的是我们开发完一个功能合并到 develop , master ,tag这些分支时能自动帮我们进行单元测试、代码质量检测、编译、发布、制品推送到相应的仓库里、并部署到相应的环境中。其实说到底我们开发人员最后只需要执行一个 git push 命令接下来的工作就交给机器去自动完成。这样我们开发也更能专注于业务功能的开发。
Gitlab CI/CD
为什么是 Gitlab CI/CD, 而不是 Jenkins 呢？首先 Gitlab CI/CD 是开箱即用。不需要像 jenkins 那样去安装一堆插件。而且 Gitlab 提供的C I/CD 也足够的简单。最主要的是够用。当然啦 Jenkins 也有 Jenkins 的好处。因为在开发人员比较完善的团队里去使用它带来的收益会更高。我一直都是使用的 Gitlab 提供的 CI / CD。
CI/CD概念
持续集成(CI)
开发人员每天都会往仓库中多次推送代码的更改要。对于每一次推送我们使用使用一组脚本来自动构建各测试应用程序。
持续交付(CD)
每次将代码更改推送到代码库时，不仅会构建和测试您的应用程序，还会持续部署应用程序。但是，对于持续交付，您需要手动触发部署。
持续部署(CD)
类似于持续交付。不同之处在于，不是手动部署应用程序，而是将其设置为自动部署。不需要人工干预。
CI/CD 工作流程
.gitlab-ci.yml
要使用gitlab提供的 ci/cd 功能我们只需要在项目的根目录中创建名为 .gitlab-ci.yml 的文件即可。在 .gitlab-ci.yml中您可以定义：
- 要运行的脚本
- 要包含的其他配置文件和模板
- 依赖项和缓存
- 要按顺序运行的命令和要并行运行的命令
- 部署应用程序
pipeline
每次 commit 都会触发一个 pipeline 相当于一次构建任务。其中包含声明的流程。如安装依赖、运行测试、编译、制品提交、部署等。
Stages
我们可以在 一个 pipline 中定义多个 stages。这些 stages会有以下特点：
- 按顺序执行，想当于从上至下。上一个 stage 完成后下一个才会开始执行。
- 所有 stages 完成后,该构建任务才会成功。
- 如果有一个 stages 失败，那该 stage 往后的节点都不会在执行。则该构建任务失败。
Jobs
job 是在 stages 中最小执行单位。一般由多个组成。这些 Job 有以下特点：
- 相同 Stage 中的 Jobs 会并行执行
- 相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
- 如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败
Gitlab Runner
有了由 jobs-> stages 组成的 pipeline ，还需要可以运行该 pipeline 的地方。构建任务一般都会占用大量的系统资源。所以 Gitlab 本身没有 Runner ，需要我们手动部署 Runner 。 这些 Runner 可以是本地开发机，也可以是公司的专门用来构建任务的机器。接下来我们需要安装部署 Runner。
常用关键字