ci /cd_没有CI / CD这样的东西！-CSDN博客

ci /cd

最近，我意识到一个太久以来一直在发展的趋势：将CI和CD合并为同一个词组-CI / CD。当营销人员完成此操作时，这与往常一样，都是流行语和炒作的混合，并大喊“看着我！”。但是，当专业软件工程师重复此操作时，我开始担心。而这正是现在正在发生的事情。这篇文章旨在概述我的想法，我可以推荐其他人以消除我认为与CI / CD有关的困惑。

为此，需要一些历史记录。最初，简称为持续集成-CI。尽管过去CI并不是开发项目中严格要求的项目，但是当项目的人员总数从1升至以上水平时，它是必要的：单个开发人员可以使用文件系统进行开发，并使用简单的在线存储系统来保存进度，是否自动。但是，只有一个额外的开发人员，一个人就有覆盖另一个人所做的更改的风险。因此，发明了一种新型软件：版本控制软件。但是，这仅解决了覆盖彼此的源代码文件的问题。

来自同一代码库的多个开发人员还有另一个问题。可以引入不会覆盖任何内容的更改，但是会引入编译错误或更糟的错误-源代码其他部分中的错误。例如，想象一下整个代码库中使用的函数。任何人都可以删除该功能，并防止代码被编译。为了防止这种情况，应该确保没有任何变化会产生这种不利的副作用。解决方案是CI，这是一种自动执行过程以确保没有任何更改会破坏现有代码库的方法。

构成CI流程的确切步骤取决于不同的因素。例如，诸如C或Java之类的编译语言需要一个编译步骤。 CI流程中可能还有许多其他步骤：

单元测试
整合测试
变异测试
源代码质量检查，例如 SonarQube
打包：根据技术堆栈，创建可执行文件，JAR，ZIP存档等
将新建软件包存储在存储库中
等等

CI是一种古老的做法。我认为我从事的前几个项目都没有CI，但是在那之后，他们都拥有了。真正的区别在于，随着时间的流逝，越来越多的步骤（例如上述步骤）逐渐出现。

现在，让我们谈谈CD。首先，让我们提到CD是基于CI构建的 ：如果没有CI，就不会有CD。但是，CD本身可以引用两个相关但不同的事物：

持续交付

持续交付是准备要在CI链末尾部署的程序包的过程。这是在常规配置链中发生还是由其他工具触发都无关紧要。重要的是，最终的生产部署应该一键（或一个命令行）就可以了，这很容易。部署的最后一步仍然是商人的决定。

连续交付可以但不必包括部署到生产环境以外的其他环境，例如暂存。但是，一般来说，这样做是出于测试目的：可能是为了集成测试，但更可能是为了性能测试和安全性测试，条件是登台是生产的精确镜像。

持续部署

持续部署比持续交付进一步迈出了一步。在这一点上，没有涉及“手动”决策。提交会触发整个管道链，而链的最后一个里程碑是在生产中部署增值产品。由于在生产中引入错误的风险很高，因此需要采取一些安全措施：除了进行各种不同类型的测试外，部署本身通常还涉及一定程度的canary发布，因此新版本并非所有人都可以使用。用户，但只占其中的一小部分。监控可确保一切顺利，这时从此新版本中受益的用户百分比将逐渐增加，直到达到100％。