软件工程之美学习笔记二十七 26 | 持续交付：如何做到随时发布新版本到生产环境？

最新推荐文章于 2023-09-05 11:49:15 发布

alpha xu

最新推荐文章于 2023-09-05 11:49:15 发布

阅读量657

点赞数

分类专栏： IT技术学习笔记软件工程之美学习笔记

IT技术同时被 3 个专栏收录

74 篇文章 2 订阅

订阅专栏

学习笔记

50 篇文章 0 订阅

订阅专栏

软件工程之美学习笔记

45 篇文章 6 订阅

订阅专栏

《软件工作之美》材料地址：https://time.geekbang.org/column/article/92587

集成、部署和交付的发展史

集成的原始阶段
从手动集成到自动化的持续集成
《重构》的作者 Martin Fowler 说过：“如果一件事很痛苦，那么就更频繁的做（if it hurts, do it more often. ）”

部署和交付的发展史

部署指的是将代码发布到各种环境，比如部署测试环境以供测试。交付则指的是软件产品在测试验收通过后，具备发布到生产环境交付给客户使用的条件。

部署和交付的原始阶段
在早些年，部署是一件很麻烦的事情。需要手动获取最新源代码、编译、再需要针对环境修改很多配置。生产环境就更麻烦了，因为出错了会导致服务中断。
所以为了避免部署出问题，会尽量避免进行生产环境部署，几周甚至几个月才会部署一次。
从手动部署到脚本自动化部署
早期的自动化部署解决方案是每日构建（Daily Build），简单来说，就是大家在每天晚上下班后，每日构建程序自动从源代码管理器下载最新代码，编译、部署程序到测试环境。这样第二天测试人员就可以拿到最新的程序，对前一天修复的 Bug 进行测试。
从脚本部署到持续交付
持续交付，就是在持续集成的基础上，再进一步，在功能合并到主干后，不仅会进行自动化测试，还会打包，并部署到测试环境中。
但部署到生产环境，这个环节需要人工确认

在这里插入图片描述 4. 从持续交付到持续部署
持续部署，和持续交付唯一的不同，就是手动确认的环节都没有了

该不该应用持续交付？

持续集成和用什么开发模型是没有关系的，瀑布模型也可以应用持续集成，应该尽快将持续集成的环境和相应的开发流程搭建起来。

如何搭建持续交付环境？

准备工作

持续集成
需要有源代码管理工具
需要有自动化测试代码
持续交付
对代码构建的过程可以反复进行，并且每次构建的结果是一致的、稳定的；
所有环境的配置都存在于源代码管理工具中，不仅仅是代码；
需要自动创建针对于不同环境的发布包；
所有环境的部署发布步骤都必须是自动化的。

选择合适的持续集成工具
Jenkins
go CD
Travis CI
Gitab CI
Azure Pipelines
根据选择的工具实施

我的留言

cicd中有一个基础能力就是自动化测试。老师能否详细介绍一下自动化测试的不同场景、采用的工具流程、测试条件的准备，输入输出等？谢谢
老师回复: 会的，第29篇就是自动化测试。

另外你说的场景是不是指的单元测试、集成测试、端对端测试这样的场景？

以下转载自风起云飞firim的文章谈谈持续集成，持续交付，持续部署之间的区别

经常会听到持续集成，持续交付，持续部署，三者究竟是什么，有何联系和区别呢？

在这里插入图片描述

假如把开发工作流程分为以下几个阶段：

编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署

正如你在上图中看到，「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」有着不同的软件自动化交付周期。

持续集成

持续集成是指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程（XP），是 XP 最初的 12 种实践之一。
在这里插入图片描述

CI 需要具备这些：

全面的自动化测试。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要；
灵活的基础设施。容器，虚拟机的存在让开发人员和 QA 人员不必再大费周折；
版本控制工具。如 Git，CVS，SVN 等；
自动化的构建和软件发布流程的工具，如 Jenkins，flow.ci；
反馈机制。如构建/测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。

持续集成的优点:

“快速失败”，在对产品没有风险的情况下进行测试，并快速响应；
最大限度地减少风险，降低修复错误代码的成本；
将重复性的手工流程自动化，让工程师更加专注于代码；
保持频繁部署，快速生成可部署的软件；
提高项目的能见度，方便团队成员了解项目的进度和成熟度；
增强开发人员对软件产品的信心，帮助建立更好的工程师文化。

持续集成，该从何入手

最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统，关键在于团队运行的基础设施，团队对持续集成系统的资源投入力度。

对比一下私有部署和托管型持续集成系统，或许能帮助你更好地做出选择。

Self Hosted CI 指的是将软件部署在公司的机房或内网中，需要提供多台服务器来完成 CI 系统的运转，同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ，他们的特点是自由开源，且文档支持广泛。优点在于对构建环境有完全的控制权，能够实现完全定制。但需要搭建环境和配置、维护成本高，需要买专门的机器，花费较多人力物力且更新迁移风险高；
Hosted CI 指的是由 SaaS 型的 CI 服务，全程在线进行构建配置，不需要考虑装机器，装软件，环境搭建等成本。常见的有 CircleCI，Codeship 和 TravisCI 等，还有国内最新的持续集成服务——flow.ci 。SaaS 型的 CI 的特点在于无需额外机器，几分钟就可以用起来。可以根据你的需要动态调度资源。省时，省心，省力。

整体而言，Jenkins 过去一直是大部分公司的选择，但这个现象正在发生改变，随着公有云服务、Docker，SaaS 的普及，越来越多的企业开始选择 Hosted CI，也就是托管型持续集成系统。

另外，在选择合适的持续集成服务时，还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。

选择持续集成系统只是持续集成应用的其中一步，还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成，可为持续交付与持续部署打好坚实基础。

持续交付

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。

在这里插入图片描述

试想想，如果说等到所有东西都完成了才向下个环节交付，导致所有的问题在最后爆发出来，解决成本巨大甚至无法解决。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题，可以继续手动部署到生产环境中。当然，持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。

持续交付的好处

持续交付和持续集成的优点非常相似：

快速发布，能够应对业务需求，并更快地实现软件价值。
编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速反馈；
高质量的软件发布标准。整个交付过程标准化、可重复、可靠，
整个交付过程进度可视化，方便团队人员了解项目成熟度；
更先进的团队协作方式。从需求分析、产品的用户体验到交互设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。

持续部署

持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”.
在这里插入图片描述

为什么说持续部署是理想的工作流程？

“开发人员提交代码，持续集成服务器获取代码，执行单元测试，
根据测试结果决定是否部署到预演环境，如果成功部署到预演环境，
进行整体验收测试，如果测试通过，自动部署到产品环境，全程自动化高效运转。”

实际上，产品在从需求到部署的过程中，会经历若干种不同的环境，例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理，产品在不同环境中的具体部署，状况是比较非常复杂的，从头到尾地全自动持续部署的确困难。那么，如果能做到持续交付，保证代码在模拟环境没问题，也许团队成员做到真正的心理有数。

持续部署的优点

持续部署主要好处是，可以相对独立地部署新的功能，并快速地收集真实用户的反馈。

“You build it, you run it”，这是 Amazon 一年可以完成 5000 万次部署，平均每个工程师每天部署超过 50 次的核心秘籍。

最后

「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」提供了一个优秀的 DevOps 环境，对于整个团队来说，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。