了解持续部署
持续部署 (CD) 是对持续集成和持续交付 (CI/CD) 流程的扩展，它将每个成功的代码更改自动部署到生产中。
什么是持续部署？
对于自动执行构建、测试和部署步骤的 DevOps 做法，持续部署可以将其逻辑发挥到极致。 当代码更改成功通过管道的每个阶段时，更改将自动部署到生产中，无需任何手动干预。 采用持续部署意味着您可以在不影响产品质量的情况下，尽快向用户提供新功能。
持续部署以成熟且经充分测试的持续集成和持续交付流程为基础：
- 团队成员定期小批量提交代码更改。
- 每次提交都会触发自动化测试和构建流程。
- 然后，构建经过各种预生产环境，进行进一步自动化测试。
- 如果没有发现问题，新版本的软件就会向用户发布。
拥有稳健可靠的 CI/CD 流程后，您就可以自动执行最后一步，开始自动向用户部署更改。 通过持续部署，发布将成为每天多次发生的小事件。
尽管如此，持续部署不应被视为所有 DevOps 团队的最终目标。 如果您正在构建应用、API 或已安装的软件，您的用户可能不希望每天收到多次更新。 在这种情况下，持续交付可能更适合。
即使您不想要完全自动化的部署管道，您可能也会希望挑出一些做法，并将它们应用到自己的 CI/CD 流程。 我们来探究一下持续部署究竟涉及什么，以及在迈向持续的“一切”之前需要考虑哪些问题。
持续部署与持续交付
很容易将两者混淆，但持续部署和持续交付都是 CI/CD 管道 CD 部分的不同组成元素。 在持续交付中，最终生产发布必须手动触发，而在持续部署中，只要前面的所有步骤都已成功完成，发布就会自动进行。
比较持续部署和持续交付
| 持续部署 | 持续交付 | |
|---|---|---|
| 发布模式 | 每次代码更改成功完成管道的每个阶段时自动触发。 | 对已成功完成管道每个阶段的更改手动启动。 |
| 发布频率 | 每小时最多多次（取决于团队规模和管道速度）。 | 通常是每周或每月一次，但您也可以任意调整。 |
| 最适合 | 网站和 Web 应用程序。 | 移动应用、桌面软件和 API。 它们还可用作实现持续部署的垫脚石。 |
| 测试流程 | 必须完全自动化，并且非常稳健。 质量门有助于让开发者和利益相关者相信测试能够发现 bug。 | 自动化测试应当尽可能多地使用。 较低频率的发布流程为手动验收和探索性测试留出了空间。 |
| 额外注意事项 | 金丝雀部署和蓝绿构建可以最大限度地降低发布到生产中的任何问题的影响。 监控对于尽早发现生产中的问题至关重要。 | 虽然发布是手动触发，但流程本身应该是自动的。 仍需考虑快速回滚或部署修正的选项。 |
通过我们的持续集成、交付与部署指南详细了解差异。
使持续部署成为现实
如果您的集成和部署流程是完全手动的，您需要执行代码冻结、采用全员参与的测试策略并在产品发布之日保持高度紧张的状态，那么执行以小时为单位的部署听起来则可能无异于幻想。
不过，现实情况是许多组织正在转向这种更常规的方式。 从 Netflix、Etsy 和 Amazon 等巨头到规模较小、知名度较低的公司，许多企业都在采用持续部署系统来尝试跟上市场的步伐。 这种方法使许多软件创建者能够将发布时间从数周或数月缩短到几小时。
随着交付功能和快速响应反馈的压力越来越大，持续部署提供了一种在不影响质量的情况下定期发布的策略。
实现持续部署系统
作为持续集成和交付的扩展，持续部署以全自动构建、测试和部署流程为基础。 这种方式可以确保在提高速度的同时不会以牺牲质量为代价。 不过，有效实施持续部署不仅仅需要扎实的基础。
质量门
在开始发布无需任何手动参与的更改之前，您需要对 CI/CD 流程完全抱有信心。 特别是，您需要确保您的自动化构建和自动化测试能够有效验证您的代码。 这一步是代码质量门可以提供帮助的地方。
质量门指定了代码进入管道下一阶段的标准。 对于某些阶段，您可以设置一个简单的阈值，例如要求单元测试的通过率达到 100%，代码覆盖率达到 90%。 对于其他自动化测试，您可能会允许一定比例的警告，但在出现错误时使步骤失败。 有时，您可能希望在步骤失败之前标记错误或警告以供手动审查。
在管道的关键阶段使用自动化质量门，可以让您控制和了解流程，并对每次发布执行的尽职调查进行完整的审核跟踪。
考虑发布策略
在计划如何实施持续部署系统时，要考虑到的关键问题是如何发布您的更改。 每次部署都让服务器离线会导致在线服务频繁中断，因此滚动更新策略通常是首选。 您还可以使用金丝雀部署，将部署作为自动化测试流程的扩展。
金丝雀部署
金丝雀部署会将更新代码的部署有限地发布给一小部分用户，这些用户将成为生产期间不知情的测试者。 通过监控用户行为和用法指标，您可以在将新版本部署到更广泛的受众之前检查以确保其中未引入新的问题。
金丝雀置信度分数
一些公司通过金丝雀置信度分数进一步完善了自动化，该分数可以自动将大量指标与基准进行比较。 只有分数超过指定阈值时，自动化部署才会继续。 如果分数过低，指标分析将为进一步调查潜在问题提供一个起点。
蓝绿构建部署
蓝绿构建部署流程是组织实现持续部署系统的常用技术。 蓝绿部署通过使旧代码保持在线可以在出现问题时让您更轻松地回滚到之前版本，直到您确信更改可以如期运行为止。 如果需要，您可以在初始金丝雀部署之后采取蓝绿部署。
监测生产指标
无论您是运行蓝绿部署还是直接部署以替换旧版本，都需要监测生产系统的运行状况，以便能够快速响应自动化测试过程中遗漏的任何 bug。
首先，确定表明系统运行状况的关键指标。 这可能包括系统运行状况指标，例如磁盘空间和 CPU 使用率，以及使用情况指标，例如请求或事务的数量。 将这些指标与运行状况基线进行比较，可以在出现问题时提供早期预警信号。 然后，您可以决定是回滚更改还是在管道中放置修正。
持续部署的注意事项
在跟随持续部署的潮流之前，花点时间考虑一下您需要做的一些事情，确保成功采用 CD。
让利益相关者参与进来
软件开发生命周期不仅涉及到代码更改。 用户研究、产品营销、交互设计、文档、商业、法务和支持团队都要履行其职责。
如果没有与利益相关者共同奠定良好基础并且没有让他们充分参与以了解其在发布流程中的需求，贸然转型到自动化发布可能会使他们感到开发工作不受控制。 这可能导致利益相关者要求手动检查点和审查阶段，从而减慢流程并削弱 CI/CD 的优势。 在最坏的情况下，整个持续部署系统可能会被视为失败的实验而被拒绝。
鼓励协作
营造协作文化对于持续部署的顺利进行至关重要。 让其他团队充分参与整个开发流程，以便他们在设计、安全性问题、术语或合规性方面的意见能够尽早得到采纳，这便是通过简短反馈循环来提高软件开发生命周期效率的一个示例。
让所有人都了解情况
与广收意见同样重要的是提供有关发布时间及内容的直观信息。 借助 CI 服务器自动向利益相关者通报情况。 根据您选择的持续构建部署工具，您应该能够通过仪表板和通知传播信息。
使用功能标志或专用分支
有时，仅提供有关未来计划的直观信息还不够。 当您开发较大型的功能或需要控制发布时间时，如果每个提交仅仅通过了全部测试就匆匆部署上线，这种做法往往不够理想。
功能标志是控制代码在生产中可见性的一种选项。 优点是代码是实时的，因此您可以监测软件是否存在意外故障。
另一种方式是使用专用分支和不会自动推送到生产中的单独管道，从而结合持续交付和持续部署以满足您的需求。
持续部署最佳做法
如果操作得当，持续部署可以帮助团队更频繁地向用户交付更改，同时最大限度地减少 bug。 关键在于遵循最佳做法，包括使用指标来优化管道并监测生产环境以确定任何问题的迹象。 认识到所涉及的文化转变并让整个团队参与 CI/CD 流程也很重要。
您可以通过我们的持续部署最佳做法指南详细了解如何简化 CI/CD 流程并获得更好的结果。
总结
- 持续部署是一种 DevOps 做法，可以自动执行构建、测试和发布流程的每个阶段。
- 持续部署的目的是在不影响质量的前提下更快、更频繁地向用户交付功能。
- 持续部署特别适合网站和 Web 应用程序，因为用户不需要自己应用更新。
- 更快、更频繁的发布可以快速获得用户反馈，并降低生产中出现的任何 bug 的影响。
- 自动化测试、生产监测、与其他职能的协作，以及用户行为都为软件开发流程供了宝贵意见。
- 通过将工作拆分成小块并以更高的频率发布，您可以根据反馈不断地进行调整并持续改进交付的产品。
TeamCity 如何提供帮助
TeamCity 通过高度可配置的触发选项和部署构建运行器促进了持续部署的设置流程。 专用部署构建配置意味着您可以限制部署到生产的权限，而灵活的构建触发器则允许您定义发布条件。 使用 TeamCity 对软件包仓库和容器注册表的内置支持来管理构建工件，作为持续部署流程的一部分。
让利益相关者访问 TeamCity 直观的基于 Web 的仪表板，了解进展情况。 强大的基于角色的访问控制确保了您可以保障生产路径安全，内置的审核跟踪则能够全面记录管道中的所有活动。
