Gitlab CI/CD

前言：公司Gitlab项目里面需要用到需要用到Gitlab CI/CD调度编译上传到OSS上，这边来进行学习下

参考文章：https://docs.gitlab.com/ee/ci/introduction/index.html
参考文章：https://docs.gitlab.com/ee/ci/enable_or_disable_ci.html

传统应用发布模式

这边可以对比下通过Gitlab的CI/CD调度和传统应用发布模式的区别之处

上面的结果就有可能导致如下的情况发生，简单的理解多人工作导致相关意见的不统一就有可能造成分歧影响开发上线效率

关于CI/CD

CI/CD 属于 DevOps（开发和运营团队的联合），结合了持续集成和持续交付的实践。CI/CD 自动执行传统上将新代码从提交导入到生产中所需的大部分或全部手动人工干预，包括生成、测试（包括集成测试、单元测试和回归测试）、部署阶段以及基础结构预配。

个人理解CI/CD是是把测试、打包、发布都交给自动化的工具，提高效率，减少失误，开发人员只需要开发和提交代码到git就可以完成后续工作，比起传统应用发布模式提高了不少的效率。

持续集成 (CI)

持续集成是尽早并经常将所有代码更改集成到共享源代码存储库的主分支中的做法，在您提交或合并每个更改时自动测试它们，并自动启动构建。通过持续集成，可以在开发过程中更早地更轻松地识别和修复错误和安全问题。

通过频繁合并更改并触发自动测试和验证过程，可以最大程度地减少代码冲突的可能性，即使多个开发人员在同一应用程序上工作也是如此。第二个优势是，您不必等待很长时间才能获得答案，并且在必要时可以在该主题仍然记忆犹新时修复错误和安全问题。

常见的代码验证过程从验证代码质量的静态代码分析开始。代码通过静态测试后，自动化CI例程将打包并编译代码以进行进一步的自动化测试。CI 流程应具有跟踪更改的版本控制系统，以便您知道所用代码的版本。

持续交付/持续部署 (CD)

当开发人员在主分支合并一个提交时，这个分支将被构建，测试，如果一切顺利，则部署到生产环境中。

从GitLab8.0开始，GitLab全面集成了GItLab-CI，且对所有项目默认开启。只要在项目仓库的根目录添加.gitlab-ci.yml文件，并且配置了Runner（运行器），那么每一次合并请求（MR）或者push都会触发 CI pipeline。

每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。

问题：看了下上面的ci和cd都存在部分的构建，测试阶段，这两个阶段分别在ci和cd中是一样的吗？

CI阶段中看到的构建，测试，部署，这通常是指把程序部署到一个测试或者预生产环境，而不是真正的生产环境。而在CD阶段，"部署"通常指的是把程序部署到生产环境。

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

下面是一张GitLab在DevOps的每个阶段可用的功能生命周期，感觉CI部分更加注重代码的可运行性以及代码质量的检测。