21英里法则
这篇文章是我们“缩短周期时间”战术指南（共分为五个部分）的第五篇也是最后一篇文章。 在 此处 阅读上一篇文章 。
如果开发人员的变更集在合并时不一定总是可以部署，那么您的团队就没有在实践持续交付。
完全优化产品上市时间（或周期时间）的最后一步是灌输无缝部署，让每个工程师负责将主要生产部门保持在可发布状态。
真正的持续交付的障碍可分为三类：
- 流程 ：您的流程涉及许多手动阻止程序，包括质量检查和手动部署。
- 行为 ：您的经理或工程师缺乏信心。 他们不确定合并之前是否会发现缺陷，或者不确定团队是否可以响应部署后发现的问题。
- 技术性 ：您当前的工具要么缺少，太慢，要么经常中断。
这篇文章将引导您减轻各种障碍，以便您可以在工程团队中实现部署就绪的文化。
克服过程障碍
过渡到CD流程要求开发团队中的每个人都尽可能地在策略上花费时间。 这种无情的时间管理方法要求在部署过程中将您能做到的一切自动化，特别是完全阻止部署的任何手动阶段。
在许多团队中，最艰巨的过渡正在远离人工关门运送的过程，例如人工质量检查和安全检查。 这些认可标志的存在使您的团队充满信心，他们不会运送不符合要求的物品。 为了消除这些障碍，您需要解决整个软件开发过程中的质量问题，而不仅仅是在最后。
删除质量检查人员作为部署的阻止者
测试的目的是手动还是自动，目的是确保软件质量符合标准。 CD中的许多实践，例如小批量工作和进行《代码审查》，本质上是作为质量控制措施。 您的团队在开发过程中没有发现的任何重大缺陷都应该通过自动化测试来发现。
为降低与移除质量检查程序作为阻止程序相关的风险：
- 在整个软件开发过程中自动化测试（而不仅仅是在最后）。 测试的位置和内容将取决于多种因素，但是请尽早考虑进行测试，以确保开发人员可以在进行过多工作之前进行更改。
- 不要过度测试。 过度测试可能会导致构建时间延长，并且只会用自动瓶颈代替手动瓶颈。 我们建议尝试确保测试范围足够。 如果没有发现问题并在深夜中解决了问题，则无需唤醒工程师。
- 使用功能标志和黑暗发射。 如果存在尚未缓解的部署风险，请使用功能标志在内部或对少量客户群进行更改。 要进行进一步的研究，请查看Launch Darkly的有效功能管理完整电子书。
将这些组件安装好之后，您将需要确保拥有一个有效的监视系统，在该系统中，工具会尽快出现问题。 将平均发现时间（MTTD）与平均恢复时间（MTTR ）一起测量将帮助您持续跟踪并提高监视和部署前测试套件的效率。
左移安全性和合规性检查
安全是部署之前最重要的检查之一，这就是为什么您不应该将其暴露于人为错误的原因。 使您的安全专家可以策略性地考虑应该进行哪种测试，同时将大部分战术安全工作留给计算机。
要在整个软件交付过程中集成安全性，请考虑：
- 让安全专家参与软件规划和设计过程。 每当处理特别敏感数据的功能在持续交付流程中消失时，请在计划和设计过程中让您的安全团队参与进来。 这样，在构建功能时，安全注意事项就融入了流程，成为了团队的首要考虑因素。
- 自动源代码扫描（SAST）： 由于80％的攻击针对应用程序层 ，SAST仍然是确保应用程序安全的最佳方法之一。 自动化的SAST工具可检测所有最具威胁性的应用程序风险 ，例如，身份验证失败，敏感数据暴露和配置错误。
- 自动化动态测试（DAST）：通常称为黑盒测试，这些测试试图以一种攻击者的方式从外部渗透应用程序。 任何DAST工具都会发现两个最常见的风险-SQL注入（SQLi）和跨站点脚本（XSS） 。
- 自动测试是否依赖于众所周知的漏洞（CVE）： CVE是由 络安全和基础结构安全局维护的词典，您可以用作参考，以确保自动测试涵盖了足够的基础。
- 为团队构建安全且可重用的基础架构。 通过上面的介绍，您的安全团队可以运用他们的专业知识，以模块或原语的形式为团队的其他成员创建工具。 这样，他们将使未经安全培训的开发人员能够编写默认情况下安全的系统。
自然，您的安全团队总会有人工工作，例如渗透测试。 但是，如果将安全性纳入开发过程中，则它不会在过程的最后阶段成为瓶颈，从而阻止功能向客户推广。
克服行为障碍
DevOps Group进行的一项调查发现，组织文化是CD实施的最大障碍。
养成持续交付文化所需的行为改变是适应真正的CD做法的最困难但讨论最少的方面。 您的团队需要有信心，他们的测试基础架构和响应变更的能力应足以支持持续部署。
为了灌输这种确定性，您需要围绕CD的好处进行调整，并在整个软件交付过程中鼓励最佳实践。
建立持续交付的组织一致性
如果进行了正确的沟通，那么持续交付管道对工程师来说就不算是一个硬道理。 CD可以阻止开发人员做他们最喜欢的事情-构建有用的软件并将其推向世界。
预期的三个结果将帮助您使经理和工程师都对持续交付投入：
- 风险较小。 如果测试基础结构是可靠的（请参见下文），并且开发人员同意该基础结构是可靠的，则他们将在合并后更轻松地交付更改。
- 对单个开发人员的影响更大 。 当开发人员有权合并到生产中时，他们会感到对工作拥有更多的所有权。 由于对速度的绝对期望，持续交付管道使自上而下的计划最小化，并使开发人员能够做出更多与实施相关的选择。
- 少怪。 因为对某个功能的所有权不会孤立在一个人中，所以软件开发过程变得更加协作。 当开发人员决定将其变更交付生产时，对功能的分布式所有权消除了一些焦虑（和潜在的责备）。
为您的团队提供最佳实践的变革
到目前为止，我们的《缩短周期的战术指南》共分五部分 ，其中包括数十种可以与团队共享的最佳实践。 除了这些特定于阶段的优化之外，您还需要指导这些通用原则：
- 以小的，离散的更改工作。 当开发人员确定“拉取请求”时，他们应该在思考：我可以为该功能采取的最小的有价值的步骤是什么当他们确定范围并构建了“拉取请求”后，应将其部署到生产环境中。 他们应该避免长时间运行功能分支。
- 始终优先考虑最接近完成的工作。 让开发人员尽可能地减少进行中的工作。 如果您使用的是看板，则意味着要优先处理最接近完成的项目。
如果这个过渡过程要花六个月的时间，请不要感到惊讶。 您的团队对这种新工作方式的习惯将需要很长时间才能建立他们的信心。 如果您想Swift采取行动，请与一群已经有兴趣并积极做出积极改变的早期采用者采用CD。 您可以从小环境中的采用摩擦中学习，以更好地缓解大型组织的过渡。
克服技术障碍
您的团队无法克服行为或流程障碍，除非他们对自己的CI / CD工具套件充满信心。 执行自动测试和部署的内部版本应该快速可靠，同时您的监视设置可以使您清晰，即时地了解事物的运行方式。
锐化工具
您无法一天多次向客户发布功能，如果有以下两种情况之一：
- 您的版本是flakey，或者
- 您的构建速度很慢。
即使您的测试通过了，您的团队也没有信心建立自动部署，前提是：
- 您的监控不彻底，或者
- 您的监控没有很好地调整。
同样，测试水域的一种安全方法是使用黑暗发射或特征标记。 您的团队将能够测试问题的捕获速度和恢复速度，而不会影响客户体验。
在改善测试构建和监控的过程中，我们建议您将手动部署计划缓慢过渡到更频繁的节奏。 首先是每周部署，然后是每天，然后是一天多次部署。 最后，一旦按下部署按钮就感觉很浪费时间，就可以自动化部署过程。
软件交付的圣杯
我们系列中的每篇文章都指导您优化软件交付过程的每个阶段。 如果您已成功完成此操作，则开发人员将进行小的增量更改，频繁进行推送，并在连续交付管道中进行工作，而不会产生任何摩擦。
但是，除非您实际将这些更改交付生产，否则您就不会练习连续交付。 CD（以及之前的敏捷）的重点是缩短客户和工程师之间的反馈循环。 逐步工作，但仍在发布大量发行版并不能实现此目标。
持续交付以降低风险，快速响应并尽快将最佳版本的软件交付客户。
请查看我们的《缩短周期的战术指南》中的其他文章（共五部分）：
-第一部分： 软件交付的良性循环
-第二部分： 缩短周期时间的最大杠杆
-第三部分： 如何停止瓶颈审查的代码审查
-第四部分： 避免浪费每个人的时间来审查代码
-第五部分： 实现真正连续交付的最后一英里
翻译自: https://hackernoon.com/the-last-mile-to-true-continuous-delivery-6sk323j
21英里法则
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92407 人正在系统学习中 相关资源：迈创Matrox G200eV
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！