CI/CD基础

CI和CD是现代开发实践和DevOps中经常使用的两个缩写词。CI表示持续集成（continuous integration），这是基础的DevOps最佳实践，开发人员频繁地将代码变更合并到代码仓中，在该代码仓中运行自动化构建和测试。CD有两种缩写，可以表示持续交付（continuous delivery）或持续部署（continuous deployment）。

CI、CD和CD之间有什么区别？

Continuous integration（持续集成）

实践持续集成的开发人员尽可能经常地将他们的代码变更合并回主分支。通过构建并针对构建运行自动化测试来验证开发人员的变更。通过这样做，您可以避免在计划发布日期前集中将代码变更合并到发布分支时可能发生的集成崩溃。

持续集成非常重视测试自动化，它可以检查新的代码变更集成到主分支时是否会破坏应用程序。

Continuous delivery（持续交付）

持续交付是持续集成的扩展，因为它会在构建之后自动将所有代码变更部署到测试或生产环境。

这意味着除了自动化测试之外，您还有一个自动化的发布流程，您可以随时通过点击按钮来部署您的应用程序。

理论上，通过持续交付，您可以按需要进行发布，可以是每天、每周、每两周或任意时刻。但是，如果您真的想得到持续交付的好处，则应尽早将变更部署到生产环境中，这样可以确保小批量发布，以便在出现问题时易于排查。

Continuous deployment（持续部署）

持续部署比持续交付更进一步。在这种做法下，每个代码变更都会通过全自动的流水线发布给您的客户。没有人为干预，只有测试失败时才会阻止将新的变更部署到生产中。

持续部署是加速与客户的反馈循环并减轻团队压力的绝佳方式，因为不再需要规划发布日期。开发人员可以专注于编写软件，他们会在完成工作后的几分钟内看到他们的成果立即上线。

CI、CD和CD之间是什么关系？

简单地说，持续集成是持续交付和持续部署的一部分。持续部署和持续交付很像，只是生产环境中的部署是自动发生的。

CI、CD和CD的好处？

我们已经解释了持续集成、持续交付和持续部署之间的区别，但我们还没有研究采用它们的原因。实施每种做法都有明显的投入，但它们的收益在很大程度上超过了投入。

We've explained the difference between continuous integration, continuous delivery, and continuous deployments but we haven't yet looked into the reasons why you would adopt them. There's an obvious cost to implementing each practice, but it's largely outweighed by their benefits.

	投入	收益
持续集成	您的团队需要为每个新功能、改进或缺陷修复编写自动化测试。您需要一个持续集成服务器，它可以监控主代码仓并为每个推送的新提交自动运行测试。也可以，用云服务替代CI服务器，就像Bitbucket Pipelines或GitLab CI等开发人员需要尽可能频繁地合并他们的代码变更，至少每天一次。	由于自动化测试尽可能早地完成了回归测试，因此生产环境中会出现的Bug更少。发布过程很容易，因为所有集成问题都已提前解决。更少的工作切换，开发人员一旦提交了有问题的代码就会收到报警，就可以在转移到下一个任务之前及时修复它。测试成本大幅降低，您的CI服务器可以在几秒钟内运行数百个测试。解放您的QA团队，他们花在测试上的时间更少，可以专注于质量文化的重大改进。
持续交付	您需要在持续集成方面打下坚实的基础，并且您需要足够的测试用例覆盖全部代码。部署过程需要自动化。触发器仍然是手动的，但是一旦开始部署，就不需要人工干预了。您的团队很可能需要运用功能开关（feature flag），以确保没开发好的功能不会影响生产系统	部署软件的复杂性已被消除。您的团队不必再花几天时间来准备发布。您可以更频繁地发布，从而加速与客户的反馈循环。小变化的决策压力要小得多，因此大家都愿意更快地迭代。
持续部署	您的测试文化需要处于最佳状态。测试用例的质量将决定发布的质量。您的文档流程需要跟上部署的步伐。功能开关（feature flag）成为发布重大功能过程的固有部分，以确保您可以与其它部门（支持、营销、公关...）进行协调。	您可以更快地开发，因为无需为发布而暂停开发。每次代码变更都会自动触发部署流水线。当您部署小批量变更时，发布风险更小，并且在出现问题时更容易修复。客户每天都会看到持续的改进和质量的提高，而不是每月、每季度或每年。

从持续集成到持续部署

如果您刚刚开始一个没有用户的新项目，您可能很容易将每次提交部署到生产环境中。您甚至可以从自动化部署开始，然后将初始版本发布到没有客户的生产环境中。然后，您将提升您的测试文化，并确保在编写程序时增加代码覆盖率。当您准备好加入用户时，您已经拥有一个很好的持续部署过程，可以让所有新的代码变更在自动部署到生产环境之前都经过完整测试。

但是，如果您已经与客户有一个现有的应用程序，您应该放慢速度并从持续集成和持续交付开始。从实现自动执行的单元测试开始，无需专注于运行复杂的端到端测试。相反，您应该尽快尝试自动化部署，并进入一个自动完成部署到您的准生产环境的阶段。原因是通过自动部署，您能够将精力集中在改进测试上，而不必定期停下来协调发布工作。

一旦您可以开始每天发布软件，您就可以考虑持续部署，但要确保组织中的其他团队也已准备就绪。文档、技术支持、营销等等。这些团队也需要适应新的发布节奏，特别是不要错过可能影响客户的重大变化。

	投入	收益
持续集成	您的团队需要为每个新功能、改进或缺陷修复编写自动化测试。您需要一个持续集成服务器，它可以监控主代码仓并为每个推送的新提交自动运行测试。也可以，用云服务替代CI服务器，就像Bitbucket Pipelines或GitLab CI等开发人员需要尽可能频繁地合并他们的代码变更，至少每天一次。	由于自动化测试尽可能早地完成了回归测试，因此生产环境中会出现的Bug更少。发布过程很容易，因为所有集成问题都已提前解决。更少的工作切换，开发人员一旦提交了有问题的代码就会收到报警，就可以在转移到下一个任务之前及时修复它。测试成本大幅降低，您的CI服务器可以在几秒钟内运行数百个测试。解放您的QA团队，他们花在测试上的时间更少，可以专注于质量文化的重大改进。
持续交付	您需要在持续集成方面打下坚实的基础，并且您需要足够的测试用例覆盖全部代码。部署过程需要自动化。触发器仍然是手动的，但是一旦开始部署，就不需要人工干预了。您的团队很可能需要运用功能开关（feature flag），以确保没开发好的功能不会影响生产系统	部署软件的复杂性已被消除。您的团队不必再花几天时间来准备发布。您可以更频繁地发布，从而加速与客户的反馈循环。小变化的决策压力要小得多，因此大家都愿意更快地迭代。
持续部署	您的测试文化需要处于最佳状态。测试用例的质量将决定发布的质量。您的文档流程需要跟上部署的步伐。功能开关（feature flag）成为发布重大功能过程的固有部分，以确保您可以与其它部门（支持、营销、公关...）进行协调。	您可以更快地开发，因为无需为发布而暂停开发。每次代码变更都会自动触发部署流水线。当您部署小批量变更时，发布风险更小，并且在出现问题时更容易修复。客户每天都会看到持续的改进和质量的提高，而不是每月、每季度或每年。