效率云教程⑤| 完成第一次自动化部署

本文作者：HelloDeveloper

原理

开发和发布软件可能是一个复杂的过程，尤其是当应用程序，团队和部署基础架构本身变得复杂时。通常，随着项目的发展，挑战变得更加明显。为了以快速一致的方式开发，测试和发布软件，开发人员和组织需要创建了三种相关但不同的策略来管理和自动化这些过程。

持续集成的重点是每天多次将各开发人员的工作集成到主存储库中，及早捕获集成错误并加速协作开发。持续交付要减少部署或发布过程中的摩擦，自动执行部署构建所需的步骤，以便可以随时安全地发布代码。每次进行代码更改时，通过自动部署，持续部署将更进一步。

持续集成

持续集成是一种鼓励开发人员尽早并经常将其代码集成到共享代码库主干的实践。在一天的开发周期结束时，代码与每个开发人员多次集成到共享代码库中，而不是孤立地构建功能并在开发周期结束时集成它们。

这个方法试图通过尽早集成来降低成本。开发人员可以尽早发现新代码和现有代码之间的冲突，而冲突越早越相对容易协调。一旦冲突得到解决，工作可以继续保证新代码符合现有代码库的要求。

然而，经常集成代码本身并不能保证新代码或功能的质量。在许多组织中，集成是昂贵的，因为通过人工来确保代码符合标准，不会引入错误，并且不会破坏现有功能。当自动化水平与现有的质量保证措施数量不匹配时，频繁的集成会产生摩擦。

为了解决集成过程中的这种摩擦，在实操中，持续集成依赖于强大的测试套件和运行这些测试的自动化系统。当开发人员将代码合并到主存储库中时，自动化流程将启动新代码的构建。然后，针对新构建运行测试套件以检查是否引入了任何集成问题。如果构建阶段或测试阶段失败，团队将收到警报，以便修复。

持续集成的最终目标是使集成成为简单，可重复的过程，这是日常开发工作流程的一部分，以便尽早降低集成成本并对缺陷做出响应。努力确保系统健壮，自动化和快速，同时培养鼓励频繁迭代和响应构建问题的团队文化，这是战略成功的基础。

持续交付

持续交付是持续集成的延伸。它侧重于自动化软件交付流程，以便团队可以随时轻松，自信地将代码部署到生产环境中。通过确保代码库始终处于可部署状态，软件发布不再需要复杂的仪式，成了小事一桩，。团队可以确信他们可以在没有复杂协调或后期测试的情况下随时发布。与持续集成一样，持续交付是一种需要技术和组织改进相结合的实践。

在技术方面，持续交付严重依赖部署流水线来让测试和部署过程自动化。部署流水线是一种自动化系统，能够将一次构件分解成一系列的顺序阶段，并且在这些阶段中运行越来越严苛的测试套件。持续交付取决于持续集成的情况，因此可靠的持续集成设置是实现持续交付的先决条件。

在每个阶段，构建要么未通过测试，要么向团队发出警报，要么通过测试，从而导致自动进阶到下一阶段。随着构建在流水线中移动，后续阶段会将构建制品部署到与生产环境尽可能相似的镜像环境中。这样，可以同时测试构建，部署过程和环境。流水线结束时会产生一个构建制品，这样的话，当希望部署到生产环境中时便可以一步到位。

持续交付的组织方面鼓励将“可部署性”作为主要关注点的优先级。这会对构建功能的方式产生影响，并将其连接到代码库的其余部分。必须考虑到代码的设计，以便功能可以随时安全地部署到生产中，即使在不完整时也是如此。在这方面，行业已经出现了许多成熟的技术实践，比如蓝绿部署、抽象分支、制品库、金丝雀发布、暗启动、部署流水线、特型开关等。

持续交付很有吸引力，因为他可以自动化地执行从代码入库到决定是否将构建上生产环境这段过程。帮助评估代码质量和正确性的步骤是自动化的，但最终决定发布什么掌握在组织的手里，从而保留了最大的灵活性。

持续部署

持续部署是持续交付的扩展，能够自动地通过完整测试周期来部署每个构建制品。连续部署系统不会等待人来决定部署什么、何时部署，而是任何成功通过部署流水线的所有东西都会被自动部署。不过，虽然新代码被自动部署到了生产环境，但仍然有一些技术方法能够让你这之后决定是否激活新功能或者是否只对小范围用户激活新功能。自动部署会将功能和修复代码迅速推给客户，这样做不仅能够鼓励团队在有限范围内进行较小的更改，还能够有助于避免对当前部署到生产环境的内容产生混乱。

持续部署还允许组织受益于一致的早期反馈。功能可以立即提供给用户，而缺陷或无用的实现可以让团队在没有效益的方向上投入大量精力之前被感知到。尽早发现某个功能没用，团队便能尽快转移焦点，而不再将更多的能量投入到影响最小的地方。