手把手教您构建自己的 DevOps 流水线（二）
导读：传统的软件研发模式中瀑布式的工作方式深入到软件研发的各个环境，软件的发布过程中充满了各种等待，最终的结果就是软件产品迟迟不能发布甚至延期。构建持续交付流水线则是解决这一问题的最佳方式，在上一期《手教您构建自己的 DevOps 流水线（一）》（快来温故知新！）中我们介绍了持续交付的定义、目标和预备步骤，那么今天我们一起来看看如何实现这样一条简单但是关键的流水线吧。
Part 1：关于持续交付
Part 2：目标
Part 3：预备步骤
Part 4：实现持续交付流水线
Part 5：持续交付最佳实践及其他
交付流水线是一个简单但关键的模式，为您提供实现持续交付的框架。
流水线的描述如下：
软件在从源代码控制到生产的路径之间的显示阶段
确定哪些阶段是自动化的，哪些阶段需要手动步骤
在流水线阶段之间的移动标准是什么，捕获哪些网关是自动化的，哪些是手动的，哪些步骤可以并行
重要的是，交付流水线的概念让我们了解到：我们发布候选人的生产准备情况。
例如，如果您知道您在 UAT 中有发布候选，以及有即将通过测试的具有附加功能的发布候选，您可以使用它来决定如何，何时以及将哪个版本发布到生产。
实现持续交付流水线
交付流水线是一个简单但关键的模式，为您提供实现持续交付的框架。
流水线的描述如下：
软件在从源代码控制到生产的路径之间的显示阶段
确定哪些阶段是自动化的，哪些阶段需要手动步骤
在流水线阶段之间的移动标准是什么，捕获哪些网关是自动化的，哪些是手动的，哪些步骤可以并行
重要的是，交付流水线的概念让我们了解到：我们发布候选人的生产准备情况。
例如，如果您知道您在 UAT 中有发布候选，以及有即将通过测试的具有附加功能的发布候选，您可以使用它来决定如何，何时以及将哪个版本发布到生产。
➤ Step 1：建立您的流水线
建立交付流水线的第一步就是识别出从源码控制到生产部署之间的各个阶段。
典型的软件开发团队有一些选项可供选择，其中一些是自动化的，另一些是手动的：
在实施持续交付的同时，您可能希望借此机会添加一些更有帮助的内容。
例如，也许增加自动验收测试将减少所需手动测试的范围，加快开发周期并增加您的持续交付能力。也许添加自动性能测试或手动用户测试可以缩短周期时间，进一步实现更频繁地发布。
确定了哪些阶段对您很重要，然后您应该考虑如何将阶段安排到有序的流程中，并注意到每个阶段的投入和产出。流水线的一个非常简单的例子可能如下所示：
不过，每个软件团队都会以不同的方式做事情。例如，根据您的舒适度和自动化测试的水平，您可以决定跳过任何形式的探索性测试，并完全依赖于自动测试过程，将流水线的长度缩短到非常短的全自动化过程：
其他团队可能会选择并行化流程和测试，这在手动测试和耗时较多的时候特别有用。
与 UAT 同时运行性能测试可能是这种并行化的一个例子，当事情进展顺利的时候，这显然可以加快端到端的交付过程，但如果流水的一个分支发生故障，并且发布候选人被拒绝，可能导致先前的努力被浪费：
上述的流水线非常简单，但说明了您需要在建模流程和实施流水线时做出的决策。好流水线的定义并不那么明显，一切都需要权衡:
| 理想情况 | 折中考虑 |
|---|---|
|
所有阶段和网关都将自动化 |
需要大量投资自动化测试和发布自动化 |
|
始终避免昂贵的人工返工 |
如果测试阶段较慢且手动，则需要将测试阶段并行化，从而降低在流水线的另一个阶段出现失败候选人的风险 |
|
始终执行自动化测试 |
详细的自动测试在诸如环境的生产中也是昂贵的 |
|
准备大量环境来支持各测试阶段 |
维护环境具有相关的管理和财务成本 |
无论您对各种权衡采取何种立场，交付流水线建模的输出应该是一个基本的流程图，记录了软件从源代码到生产的路径。
➤ Step 2：识别非自动化的活动和网关
如前所述，您最好将流水线的所有阶段自动化。
在这个理想的世界中，开发者将要提交代码，然后通过流水线将发布候选者发布出去，每个步骤和各阶段之间的每个网关都自动化。合格的发布候选版本将被放在流水线的末端以备部署，而你会对每个人都抱有信心。但是，由于各种原因，这并不总是行得通。例如，常见的问题是要求手动用户验收或 beta 测试的自动化测试或业务需求量不足。即使在高度自动化测试的地方，许多企业在构建通过流水线到达生产之前都需要人工签字。
因为这些原因，我们的交付流水线的确需要通知，建模，以及在过程中允许人为和手工操作。
在某些情况下，你会发现各个阶段的网关也可以自动化。比如，如果软件在持续集成服务器中通过了自动化测试，你将会允许它进入一个开发-性能测试自动化的环境。但是你可能希望由 QA 同事去掌控测试环境发布的探索性，这种方式是人工的，甚至是自我服务的步骤。
对于自动化和人工化两个途径，你都希望去确定通过它们的标准。如果有一个标准没有被满足，那么系统就应该从交付流水线中去阻止候选者的发布。
➤ Step 3：实现你的流水线
一旦你为了流水线流建立了模型，你将在之后的实际实现中感到乐趣。如果你能使编译、测试、和发布都变得自动化，那么你就会很好的在一个发布流水线上下文中把它们变得紧密。
➤ 软件和工具
为了管理你的流水线，你将要在构建合适的脚本和致力于实现过程的现成的应用发布自动化工具二者之间做出选择。
不要在供应工具上打折扣，因为这将会解放优秀的开发者和系统管理员的时间，省下的时间或者可以用于管理内部基础设施或者开发发布自动化胶水代码。这种优秀的软件将会：
标准化流水线各阶段和流程；
定义发布候选者在流水线中流转的标准；
在合适的地方让你在流水线并行；
为管理和操作提供部署的报告和审计；
让你能监视流水线，构建进度以及各个发布候选者之间显著的改变；
给你的团队自服务的基础设施，比如让操作者发布产品以及在其就绪的时候让 QA 把版本放置于他们的测试环境；
可以进行权限管理，以便只有某些授权人员具有部署权限。
