前言
在项目迭代过程，可能有一个专门负责 CI/CD 的人员，但当想做一些静态代码检查，依赖检查，图片大小检查等事情的时候，就自己需要了解 CI/CD，编写特定 Pipeline Job。本文将做一些 CI/CD 基本介绍，看完后能够在 .gitlab-ci.yml 中配置需要的 Job 就行，所以这篇文章适合未接触过，或者刚想入手Gitlab CI/CD 的人。
本文不算原创，内容来源自于官网 GitLab CI/CD 和自己的理解，以及部分项目经验。
基础概念
CI/CD
CI/CD 是一种持续开发软件的方法，可以不断的进行构建、测试和部署代码迭代更改。这种迭代有助于减少基于错误或失败的版本进行开发新代码的可能性。使用这种方法，从新代码开发到部署，可以减少人工干预甚至不用干预。
达到持续的方法主要是：持续集成，持续交付，持续部署。
CI（Continuous Integration）：
持续集成，也就是当每一次更改的代码被推送到远程分支后，可以创建一组脚本来自动地构建和测试这些更改，确保这些更改可以通过一些基本的准则，减少引入错误的机会。
CD :
Continuous Delivery：持续交付，在持续集成的基础上更进一步，当每一次更改的代码落库后，不仅会构建和测试，也会进行部署，但是部署需要人工干预，手动的有目的进行部署。 Continuous Deployment：持续部署，持续集成之外的另一个步骤，类似于持续交付。不同之处在于，它不是手动部署应用程序，而是将其设置为自动部署。不需要人为干预。 Gitlab CI/CD Gitlab CI/CD 也就是 Gitlab 提供了上面的 CI/CD 能力，可以进行持续集成，持续交付和持续部署。
Gitlab CI/CD 适用于通用的开发工作流程。
当将本地 commits 推送到在 Gitlab 上的远程分支上，就会触发项目的 CI/CD pipeline：
自动运行（串行或并行）脚本：
构建和测试应用程序； 在应用程序中查看修改，检查是否和本地运行一样。 当达到预期以后：
Review 和 Approve 更改的代码； 合并分支，然后 GitLab CI/CD会自动地将更改部署到生产环境中。
