持续交付的最后一英里
原文出自Hackernoon
作者：CodeClimate
京东智联云开发者社区编译
如果开发人员的变更集在集成时并没有实现长期部署就绪的状态，那么你的团队其实就没有真正的实践持续交付。
想要完全优化产品开发周期，你需要在团队中强调无缝部署的重要性，使每位工程师都对主要生产线负责，使主要生产线保持在可发布状态。
真正的持续交付中很多团队大概率都会遇到的以下三类阻碍：
实施过程：你的开发过程中存在很多人为制造的阻碍，包括质量检查和手动部署。
操作推进：你的经理或工程师缺乏信心。他们不确定是否能够在集成前发现系统漏洞，或无法确定能否应对那些系统部署后才发现的问题。
技术工具：你现在所用的开发工具不充分、效率太低或者经常出故障。
这篇文章将会告诉你如何降低每一类障碍，从而在你的工程师团队中实现部署就绪文化。
01
实施过程中的阻碍
在团队从传统交付状态过渡到持续交付的过程中，需要开发团队中的每个人都尽可能有策略地管理时间。实现这种严苛的时间管理方法的前提就是要在部署过程中尽可能地自动执行所有操作，尤其是那些非常阻碍部署的手动操作。
在许多团队中，最困难的实施障碍不只单单存在于人力管理和发布流程管理（例如人工质量检查和安全检查）。持续交付工程中代表“批准许可”标志的存在会让团队有信心相信他们交付的产品是符合要求的。因此，解决软件开发工程中的品控问题不能是只放在最后一步实施的，在每个环节都进行严格把控是消除流程实施中的障碍最关键的一步。
| 移除部署过程中的障碍——QA（质量测试） |
无论是手动还是自动，测试的目的是确保软件质量符合标准。持续交付中的许多操作，例如小批量工作和代码审查，都自带质量管控监测的特性。任何在开发过程中没有被团队所发现的重大缺陷都应该通过自动检测来发现。
为了降低因QA带来的风险，你的团队应该：
在整个开发过程中采用自动化测试（而不仅仅是在最后一步）。虽然在哪里测试以及测试对象取决于各种各样的因素，但将测试尽早融入到开发过程中，能够有效防止在开发者投入大量工作之前及时发现问题。
不要过度测试。过度测试可能会导致过长的构建时间，并且会制造出自动化瓶颈。我们建议你应确保测试的范围充分，这样一来如果系统在半夜里出了故障，你们也无需叫醒工程师来处理。
使用特性切换和灰度发布。如果系统中存在尚未解决的部署风险，请使用特性切换在内部或对少量客户群样本进行更改。如想进一步了解相关研究，请查看Launch Darkly关于有效特性管理的完整版电子书。
满足以上三种要求之后，还将需要确保系统中存在有效的检测系统，这样做有一个很大的好处就是让你的系统能够及早显现出目前所存在的问题。故障诊断所需平均时间（MTTD）和故障恢复所需平均时间时间（MTTR）将帮助你持续跟踪并提高管控和部署前测试套件的效率。
| 安全合规检查 |
安全检查是部署前最重要的检查之一，这就是为什么安全检查不能容忍人为错误。你团队的安全专家应该策略性地考虑应该进行哪种测试，同时将大部分战略性的安全工作留给计算机去完成。
如果你的团队想把安全性全程融入到软件交付的过程中，你应考虑如下操作：让团队中的安全专家参与软件规划和设计过程。每当处理特别敏感数据的功能在持续交付流程中减弱时，请在计划和设计过程中让你的安全团队参与进流程中来。这样，在你的团队构建功能时，安全注意事项就融入了整个流程并成为团队的首要考虑因素。
自动源代码扫描（SAST）：由于80％的攻击针对应用程序层，SAST一直是确保应用程序安全的最佳方法之一。自动化的SAST工具可检测所有最具威胁性的应用程序风险，例如身份验证失败，敏感数据暴露和配置错误。自动化动态测试（DAST）：通常被称为黑盒测试，这些测试试图从外部渗透应用程序。任何DAST工具都会帮助发现两个最常见的风险 -- SQL注入攻击（SQLi）和跨站脚本攻击（XSS）。
依赖于常见漏洞（CVE）的自动测试：CVE是由网络安全局和基础结构安全局维护的代码字典，你可以把CVE作为参考，以确保你的自动测试涵盖了足够的范围。
为团队构建安全且可重用的基础架构。在实现了上面的几项操作之后，你的安全团队可以运用他们的专业知识，以模块或原语的形式为团队创建工具。这样一来，未经过安全培训的开发人员也能够编写出默认为安全的系统。
安全团队的工作不能完全由机器代替，例如渗透测试。但是，如果你将安全性纳入整个开发流程中，人为工作便不会在开发流程的最后阶段成为瓶颈，导致功能无法推向客户。02
克服操作过程中的障碍
在DevOps Group进行的一项调查中发现，组织文化是CD实施的最大障碍。
构建持续交付文化所需的工作模式/行为改变是适应真正的CD实践最困难、但讨论最少的方面。你的团队需要有信心，他们的测试基础架构和响应变更的能力都应该足够强大，能够支持持续部署。
为了像团队输出这种确定性想法，你需要围绕CD的优势进行调整，并在整个软件交付过程中鼓励最佳实践。
| 建立持续交付的组织一致性|
如果沟通得当，那么持续交付对工程师而言不应该是一个难以接受的事情。CD可以使开发人员做他们最喜欢的事情-构建有用的软件并将其推向世界。
以下三个预期结果将帮助管理人员和工程师都投入到持续交付中:
让项目整体风险减低——如果测试基础架构是可靠的（下面有更多关于这一点的内容），并且开发人员也同意该基础结构的可靠性，那么即便在程序发布后有需要更改也变得更加轻松。
对单个开发人员的影响更大——当开发人员有权参与到产品生产中时，他们会感到对工作拥有更多的所有权。由于对速度的期望，持续交付使自上而下的计划周期变得更加精细，并使开发人员能够做出更多与功能实现相关的选择。
团队间抱怨与指责会减少—— 因为对某个功能的所有权不会单独集中在一个人身上，所以软件开发过程变得更加需要团队成员彼此之间的协作。当开发人员决定将他们的更改发布到产品中时，功能的“分布式”所有权会消除掉一部分由于功能更改上线带来的焦虑和潜在可能出现的“责备”。
| 为你的团队提供最佳实践的变革 |
到目前为止，我们的“缩短项目周期的战术指南”（ Tactical Guide to a Shorter Cycle Time five-part series ）共分五部分，其中包括数十种可以与团队共享的最佳实践。除了这些特定阶段的优化之外，你还需要以下这些通用原则的指导：
在小而离散的变化中工作——当开发人员确定“Pull请求”时，他们应该思考“我可以为实现此功能而采取的最轻巧且有价值的步骤是什么？”当他们确定范围并构建了“Pull请求”后，应将其部署到生产环境中。他们应该避免长时间运行功能分支。
始终优先考虑最接近完成的工作—— 让开发人员尽可能地减少进行中的工作。如果你在使用看板图，则意味着你要对最接近完成的项目进行优先排序。
如果这个过渡过程需要超过6个月的时间，请不要感到惊讶。你的团队需要很长时间才能建立起对这种新的工作方式习惯的信心。如果你想要快速地采取行动，请与一群已经有兴趣并且乐于做出积极改变的早期探索者来一起研究、使用CI/CD。相比于大环境，你反而可以在小而精的组织环境中更好地学习、打磨新的模式。
03
克服技术工具相关障碍
即便你的团队对于自己的CI/CD工具套件充满了信心，仍然需要面对工作习惯、流程及沟通上的困难。
| 优化你的工具 |
如果有出现以下情况中的任意一个，那么你就不能每天多次向客户发布功能:
1、你的软件版本很不稳定
2、你的软件版本速度非常缓慢
即使你的测试通过了，但团队也没有信心设置自动部署，如果:
1、你的监测不彻底
2、你的检测结果没有得到很好的调整
这里提供一种我们觉得比较安全的测试方法：使用灰度测试。团队在这种情况下既能够测试问题的捕捉速度和恢复速度，同时又不会损害客户体验。
当你努力改进测试版本和监控过程时，我们建议你慢慢地将手动部署过渡到更频繁的节奏。首先可以从每周部署开始，然后是每天，再然后是一天多次部署。最后，当你一旦按下部署按钮就感觉很浪费时间时，那就可以进入自动化部署过程了。
04
软件交付的“圣杯”
通过以上内容的介绍，如果你的团队成功实现了持续交付，那么开发人员将在几乎不会产生冲突的情况下通过持续交付的pipeline实现软件的细微增量更改、版本迭代及持续推送。
但是，除非你实际将这些更改/更新交付到客户手中，否则你就不算是真正实践了持续交付。CD（以及之前的敏捷）的重点是缩短客户与工程师之间的反馈循环。以增量的方式工作，但如果仍在发布大量版本，就没有办法实现这个目标。
持续交付需要以减少风险、快速响应，并尽可能快地将软件的最佳版本交付给客户。
原文链接：https://hackernoon.com/the-last-mile-to-true-continuous-delivery-6sk323j
以上信息来源于网络，由“京东智联云开发者”公众号编辑整理，
不代表京东智联云立场