持续交付是一种可以快速，安全和自动化地将软件更改部署到生产中的实践。在持续交付中，发布新功能并不是一件令人痛苦的事件。在没有采用持续交付之前，公司的每个人都在代码完成之后的数周内停止工作，并在开始部署的时候紧张地等待着仪表板。相反向用户发布新软件应该是例行，无聊且容易的，以至于一天可能发生多次。
在本章中，我们将介绍可实现持续交付的组织和技术实践。我们希望它使您相信缩短发布周期的好处，并帮助您了解在Netflix和其他类似组织中交付文化的信息和实践。
1. 发布周期长的问题
服务依赖关系复杂。由于未部署的代码存放的越来越久，它所依赖的库和服务也在不断扩展。当确实需要部署这些更改时，由于上游的库版本已更改，或者是与它访问的服务不再具有该兼容的API，这将出现意外问题。
开发人员也继续前进。功能开发完成后，开发人员自然会倾向于下一个要处理的项目或功能集。信息在创作者的脑海中逐渐忘却，因此，如果确实出现问题，他们需要回去研究一个月、六个月或一年以前的想法。同样，通过发布大量版本，隔离和分类问题根源变得更加困难。我们发布的频率很高，那么我们如何使它变得更容易呢？
2. 持续交付的好处
持续交付消除了围绕软件发布过程的问题，这种方法有几个好处：
**保持最新:**持续交付可确保新功能，配置更改，测试和错误修复的时间更快。积极的发布节奏可确保迅速解决损坏的问题，并在数天而不是数月内带来使用户满意的新方法。
**更快的反馈循环:**频繁部署的较小更改使解决问题变得更加容易。通过将混沌工程或自动化金丝雀分析等自动化测试技术纳入交付流程，可以更快地发现问题并更有效地解决问题。
**提高可靠性和可用性:**为了快速发布，持续交付鼓励使用自动化工具替换易于出错的手动流程。可以进一步设计持续交付管道，以在特定时间和不同的目标云供应商上逐步发布更改。可以在发布过程中内置安全部署实践，并减少不良部署的影响范围。
**开发人员的生产力和效率:**更频繁的发布节奏有助于减少诸如不兼容的上游依赖关系之类的问题。加快提交和部署之间的时间，使开发人员能够在问题浮出水面的同时对问题进行诊断和做出反应。当开发人员负责维护他们部署的服务时，出现问题时就会拥有更大的意识，并且减少了责备问题。持续交付可带来高性能，使开发人员更幸福。
3.有用的做法
随着系统的发展和变更的推动，可能会引入影响系统可用性的错误和不兼容性。进行更频繁更改的唯一方法是投资，以更好的工具，实践和文化来支持他们。我们发现了一些有用的技术和原则，可加快采用持续交付做法的速度：
鼓励自给自足不要将部署过程委派给专门的团队，而应让编写代码的工程师负责部署和运维自己的发行版。通过提供自助服务工具并赋予工程师在准备就绪时就可以推送代码的能力，工程师可以快速进行创新，检测和响应。
自动化所有事情在构建，测试，发布，升级周期的每一步都全面拥抱自动化，从而减少了对部署过程的负担。
使其可见很难改善无法观察到的东西。我们发现，将不同帐户，区域和云提供商之间的所有云资源整合到一个视图中，可以更轻松地跟踪和调试任何基础架构问题。部署管道还使我们的用户可以轻松地遵循跨不同步骤提升工件的方式。
轻松做不需要专家级知识来进行云部署。我们发现，高度重视用户体验，使任何人都可以修改和改进自己的流程，对采用连续交付产生了重大影响。
当为他们提供可以插入的现成模板时，说服团队接受持续交付要容易得多。我们定义了一条“铺平的道路”（有时称为“黄金之路”），其中包含了希望部署到云的团队的最佳实践（图1-1）。随着越来越多的团队开始使用该工具，我们在反馈循环中所做的任何改进都变得可供其他团队使用。最佳做法可能会传染。
图1-1。Netflix为软件发布铺平了道路。上面显示从代码检入到获取流量的步骤，下排显示每个步骤在Netflix使用的工具。
4.总结
迁移到连续交付平台后，我们发现由于不良部署而导致的问题和中断的数量大大减少了。既然我们全神贯注于Spinnaker，就可以更加轻松地进一步推动这些实践，从而大大减少了与部署相关的问题。
关注《Spinnaker实践》课程！ 课程咨询请添加小助手微信（devopsvip）
历史文章
关于作者
泽阳，DevOps领域实践者。专注于企业级DevOps运维开发技术实践分享，主要以新Linux运维技术、DevOps技术课程为主。丰富的一线实战经验，课程追求实用性获得多数学员认可。课程内容均来源于企业应用，在这里既学习技术又能获取热门技能，欢迎您的到来！（微信ID: devopsvip）
DevOps流水线实践课程
👇戳阅读原文，立即购买
本文分享自微信公众号 - DevOps云学堂（idevopsvip）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
