如果代码每天都被提交到版本控制中，则可以对其进行自动化测试，并且在引入代码之日会标记出任何构建、测试或集成错误，从而可以立即进行修复。这确保代码总是处于可部署和可运送的状态，称为绿色构建。
自动测试允许开发人员提高测试和集成的频率——从周期性执行到持续测试集成，并在约束最少的情况下发现问题。最糟糕的情况也不过是一天的工作都浪费了。
关于版本控制的争议关于是否改在版本控制中存储敏感信息（如 access token、密钥和密码）进行了一些讨论。一方面，有人认为应该将一切（包括secret）都存储在这里，从而将这一方法推向极限。但是有人认为这是不良做法，并认为敏感信息应该单独存储。
版本控制允许开发人员比较、合并和还原以前的修订。通过允许他们在出现问题时将生产中的系统快速还原到以前的版本，从而将风险降到最低。为此，无论版本多小，所有更新和更改都必须在版本控制中进行跟踪。如果不是这样，生产中的代码将开发和测试环境中的代码不匹配，从而导致不一致。
简而言之，版本控制是事实的单一来源，包含了系统的预期状态以及所有以前的状态。通过将所有生产环境中的组件放置到版本控制中，开发人员可以重复可靠地重现工作软件系统中的所有组件。这是启用所谓的不可变基础架构的关键，我们将在稍后讨论。
持续交付：扩展CI以实现流畅的代码部署即使使用了持续集成，将代码部署到生产中的过程依旧是手动、乏味且容易出错的。如果真是这样，那么显然不会频繁地将代码部署到生产中。IT部门会尽可能避免执行艰巨而危险的任务，这会导致要部署的代码与生产中运行的代码之间差异越来越大，进一步加具危险，然后形成一种恶性循环。那么解决这一恶性循环的答案是启用CI/CD中的CD部分。
CD扩展了CI，确保在将代码推广到整个用户群之前让代码在生产环境中能够平滑运行。最常见的CD方法是金丝雀和蓝绿部署。
进行蓝绿部署期间，IT会与当前版本一起部署一个新的组件或应用程序版本。新版本（绿）被部署到生产中并对其进行测试，与此同时当前版本（蓝）依旧可以使用。如果新版本的代码运行良好，那么所有用户将会切换到新版本中。
金丝雀部署也有两个版本：当前版本和更新版本。IT开始将一小部分用户请求路由到新版本。代码和用户的行为会被持续监控。如果错误率或用户投诉并没有增加，则路由到新版本的请求份额将逐渐增加（例如，1%、10%、50%最后到100%）。一旦所有请求都发送到新版本中，那么旧版本就会自动退休或删除。
通过按需环境创建自助服务现在，我们已经研究了CI、CD及其各自的工具和方法，下面我们来讨论环境和基础架构。CI / CD需要一种创新的方法。
如我们所见，自动化测试使开发人员可以自己执行QA。为了确保一切都能在生产中正常运行，他们必须在整个开发和测试过程中使用类似于生产的环境。
传统上，开发人员必须向Ops团队请求（手动）设置的测试环境。此过程可能需要数周，有时甚至数月。此外，手动部署的测试环境通常会出现配置错误，或者与生产环境有很大差异，因此即使代码通过了所有预部署测试，仍然会导致生产问题。
CI / CD的关键部分是为开发人员提供按需类似于生产的环境，使其可以在自己的工作站上运行。为什么这很重要？开发人员只有在相同的条件下进行部署和测试时，才能知道代码在生产中的行为。如果他们在不同的环境中测试代码，则当最终将代码部署到生产环境中时，他们可能会发现代码不兼容，那么此时对客户造成了重大影响，再解决问题已经为时已晚。
不可变基础设施：牛与宠物在讨论版本控制系统时，我们谈到了将环境与所有其他应用程序组件进行编码的需求，接下来让我们进一步讨论这些环境。