如果在版本控制中定义了环境规范并进行了编码，那么在容量增加（水平扩展）时复制环境就像按一个按钮一样简单（尽管之后它很有可能通过Kubernetes自动化了）。
扩展意味着在高峰时段增加计算能力。例如，Netflix的使用率在每个星期五晚上达到峰值，然后在午夜之后的某个时间再次恢复正常。为了确保享受无缓冲的视频，Netflix复制了其流控制组件（已在版本控制中进行了编码），以满足需求。然后，流量恢复后所有所谓的副本都被破坏，使流容量恢复正常。
为了实现这一点，至关重要的是，每当实施基础架构或应用程序更新时，这些基础架构或应用程序都会自动复制到其他地方并置于版本控制中。这将确保无论何时创建新环境，它都将与整个流水线（从dev到QA到生产）的环境匹配。例如，如果Netflix要更新其流服务而忘了捕获版本控制的更改，它将在高峰时段复制有故障或过时的组件，从而导致问题甚至服务中断。
由于掌握了版本控制中的环境编码，因此手动更改环境不是最佳实践，因为任何手动操作都容易出错。而应该将更改放入版本控制中，并从头开始重新创建环境（和代码）。这称为不可变基础架构。这些与CI / CD部分中讨论的应用于基础架构的原则相同。
你也许听过牛与宠物的比喻。这个比喻放在这里十分合适。以前，基础设施被视为宠物。如果有问题，你会尽力解决它，以便它可以生存。今天，基础设施被视为牛。如果它无法正常工作或需要更新，请杀死它并启动新环境。这非常强大，并且大大降低了问题潜入系统的风险。
发布与部署解耦传统上，软件发布是由市场启动日期驱动的。因此，要发布的新功能会在宣布日期的前一天部署到生产中。但是，我们知道将特性或更新发布到生产中总是有风险的，尤其是如果你一次发布整个特性时。因此，将部署与发布捆绑在一起将使IT部门总是需要为失败胆战心惊。试想一下，如果在广泛推广的前一天发生了重大问题，IT团队就会感到恐慌，并且会在客户和媒体中引起巨大不良反响。
更好的方法是使部署与发布解耦。尽管这两个词经常互换使用，但它们是两个独立的过程。部署意味着将软件版本安装到任何环境（包括生产环境）中。它不一定必须与发布相关联。另一方面，发布意味着向客户群提供新功能。在整个功能开发过程中频繁进行生产部署的目的是降低服务中断的风险，该风险由IT部门承担。另一方面，何时向客户展示新功能应该是业务决策，而不是技术决策。
部署周期长会决定新功能发布的频率。如果IT可以按需部署，那么公开新功能的速度应该成为业务和市场营销的决定。
结 论总而言之，CI要求将代码连续集成到代码库中，以在发生错误时捕获错误，从而最大程度地减少返工。要实现这种方法，需要三个工具：版本控制，以跟踪所有更改并使整个团队都可以使用最新的源代码版本；master，负责自己分支的开发人员每天合并更新；部署流水线将触发一系列测试，基本上是自动进行QA。
CD扩展了CI，以验证代码是否处于可部署状态，并自动将其释放到生产环境中。为此，需要一个成熟的DevOps组织，该组织必须先掌握CI，然后才能尝试使用CD。
如果实施得当，CI（/ CD）将大大提高你的IT团队的生产力。你的系统或应用程序在不断改进，同时将部署风险降至最低，从而增强了生产力和员工满意度的积极循环。此外，快速推出新功能和更新可推动创新，进而更快，更频繁地为用户带来价值。显然，随着越来越多的组织采用这些DevOps方法，由于传统方法无法与CI / CD竞争，因此对那些没有采用DevOps方法的企业，压力会越来越大。
附录：部署流水线测试套件
集成测试检查应用程序如何与其他应用程序和服务交互，以确保代码与这些依赖项正确交互。远程服务的虚拟或模拟版本可用于准确地重新创建生产环境。
验收测试会验证是否满足业务需求，以确保功能或应用程序为最终用户提供所需的价值。
性能测试可验证该应用程序在类似生产的负载下如何在整个堆栈（代码、数据库、存储、网络、虚拟化）中工作。由架构决策或网络、数据库、存储或其他系统的意外限制引起的问题应在此处解决。