最近，我意识到一种趋势已经持续了很长时间：将CI和CD合并为同一个词组：CI/CD。
当营销人员完成此操作时，这与往常一样，是流行语和炒作的混合，并大喊“看着我！”。但是，当专业软件工程师重复此操作时，我开始担心。而这正是现在正在发生的事情。这篇文章旨在概述我的想法，我可以推荐其他人以消除我认为与CI / CD有关的困惑。
为此，需要一些历史记录。最初，CI简称为持续集成。尽管过去CI并不是开发项目中的严格要求，但是当项目的人员总数升至一位以上水平时，CI是必要的：单个开发人员可以使用文件系统进行开发，并使用简单的在线存储系统来保存进度，是否自动。但是，只有一个额外的开发人员，一个人就有覆盖另一个人所做的更改的风险。因此，发明了一种新型软件：版本控制软件。但是，这仅解决了覆盖彼此的源代码文件的问题。
来自同一代码库的多个开发人员还有另一个问题。可以引入不会覆盖任何内容的更改，但是会引入编译错误或更糟的错误-源代码其他部分中的错误。例如，想象一下整个代码库中使用的函数。任何人都可以删除该功能，并防止代码被编译。为防止这种情况，应确保没有任何变化会产生这种不利的副作用。解决方案是CI，这是一种自动执行过程以确保没有任何更改会破坏现有代码库的方法。
构成CI流程的确切步骤取决于不同的因素。例如，诸如C或Java之类的编译语言需要一个编译步骤。CI流程中可能还有许多其他步骤：
- 单元测试
- 整合测试
- 变异测试
- 源代码质量检查，例如 SonarQube
- 打包：根据技术堆栈，创建可执行文件，JAR，ZIP存档等
- 将新建软件包存储在存储库中
- 等等
CI是一种古老的做法。我认为我从事的前几个项目都没有CI，但是在那之后，他们都拥有了。真正的区别在于，随着时间的流逝，越来越多的步骤（例如上面提到的步骤）逐渐出现。
现在，让我们谈谈CD。首先，CD是基于CI构建的：如果没有CI，就不会有CD。但是，CD本身可以指两个相关但不同的事物：
1. 持续交付：
持续交付是准备要在CI链末尾部署的程序包的过程。这是在常规配置链中发生还是由其他工具触发都无关紧要。重要的是，最终生产部署应该一键（或一个命令行）就可以了，这很容易。部署的最后一步仍然是商人的决定。
连续交付可以但不必包括部署到生产环境以外的其他环境，例如暂存。但是，一般来说，这样做是出于测试目的：可能是为了集成测试，但更可能是为了性能测试和安全性测试，条件是登台是生产的确切镜像。
2.持续部署：
持续部署比持续交付进一步迈出了一步。那时，没有涉及“手动”决策。提交会触发整个流水线链，而链的最后一个里程碑是在生产中部署增值产品。由于在生产中引入错误的风险很高，因此需要采取一些安全措施：除了进行各种不同类型的测试外，部署本身通常还涉及一定程度的canary金丝雀发布，因此新版本并非所有人都可以使用。用户，但只占其中的一小部分。监控可确保一切顺利，这时从此新版本中受益的用户百分比将逐渐增加，直到达到100％。
结论
持续集成，持续交付和持续部署密切相关：它们都依赖于自动化，而后者则依赖于前者。但是，相似之处到此为止。
一方面，我建议您不要为没有CI的公司工作。如今，没有充分的理由不使用CI。缺少它对于软件工程文化是一个非常糟糕的信号。
另一方面，截至目前，没有多少公司实施持续部署。而且我不确定它会在不久的将来改变。持续部署需要在许多不同领域中具有高度的成熟度：自动化流程的成熟度，测试流程的成熟度，技术人员与业务人员之间信任的成熟度等。
我希望到现在为止，您已经确信CI和CD不应混为一谈，并且可以随意使用。