前言

不仅仅是企业中，我们平时开发时，也可以使用工作流提高开发效率。其实计算机的各种技术的逻辑都来自于生活，所以也比较好理解。

简介

CICD 是 持续集成（Continuous Integration）和持续部署（Continuous Deployment）简称。指在开发过程中自动执行一系列脚本来减低开发引入 bug 的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。

持续集成(Continuous Integration)

现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是，如果企业安排在一天内将所有分支源代码合并在一起（称为“合并日”），最终可能造成工作繁琐、耗时，而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时，有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境（IDE），而不是让团队就一个基于云的 IDE 达成一致，那么就会让问题更加雪上加霜。

持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。

持续交付(Continuous Delivery)

完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。

持续部署(Continuous Deployment)

对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。

实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。

具体应用

• 博客提交工作流

  我的博客其实就是一个小例子，我一般在VScode修改代码或者写文章，然后使用Git扩展一键提交到GitHub的博客源码库里，再通过GitHub Action使用GitHub服务器的资源创建public文件，最终自动上传到源站库中。这也能算得上是利用了CICD的思想。

  相信大家看了上面CICD的介绍以后，能够把博客一键式开发时的环节和CI、CD对应起来了。

• 其他的具体实现

  有很多集成开发软件/工具也都希望提高程序员的开发效率，那肯定少不了CI/CD的应用。比如下面这些：

  1. GitLab CI
  2. GoCD
  3. Travis CI
  4. Jenkins
  5. Concourse CI
  6. Spinnaker
  7. Screwdriver
     …

最后

我们主要学习这种开发思想，这些工具肯定不止这些，而且不同用户的使用习惯也有所不同，选择合适的使用即可。

另外，上面只是简单介绍了一下CI/CD，实现过程中还有很多细节，大家有兴趣请自行了解，不过我觉得有些东西不需要一头扎进去，容易出不来。