如何缩短开发发布周期

在敏捷，混乱和发展的日子到来之前，软件开发通常是在数月的发行周期内完成的。 这主要是因为功能需求，集成，应用程序体系结构，开发工具和基础架构的复杂性使得难以加快开发周期。 即使当敏捷开发成为主流开发过程并改进了开发工具时，组织也将重点放在大约数周到数月的发布周期上。

如今，已经实施了持续集成和交付（CI / CD）管道的开发团队正在采取步骤来缩短其应用程序发布周期。 持续集成使构建自动化并启动测试自动化，而持续交付使代码推送和交付过程自动化到目标开发或测试环境。 当使用Jenkins ，TravisCI，CircleCI， Azure Pipelines或AWS CodePipeline之类的工具进行管理时，这两个流程可以使协作和管道自动化，以更快，更频繁地交付应用程序。

[ 同样在InfoWorld上：什么是CI / CD？ 持续集成和持续交付的解释 ]

但是仅仅拥有CI / CD是不够的。 它还需要更改业务流程，文化和其他技术实践。 让我们看一些细节。

确定为什么需要更短的开发周期

走得更快有一些业务和技术优势。 它可以缩短上市时间，尤其是在应用程序具有竞争力的价值，可以显着提高生产力，驱动更快乐的劳动力或提供其他可用性改进的地方。 当部署的更改较少且发生意外问题或依赖性的可能性较小时，它还可以降低风险。 具有非常成熟的开发实践并且在竞争激烈的地区运营的组织可以实施连续部署，这是每天多次部署到生产中的额外实践。

但是，提高速度需要付出一定的代价，因为技术和业务流程会日趋成熟，从而能够以更快的速度安全行驶。 此外， 连续部署对于您的业务或应用程序可能不是正确的解决方案 ，尤其是当它们影响关键任务工作流，在受控环境中运行或影响生命的技术时，尤其如此。

因此，在进一步踩油门之前，重要的是要问一些问题，并让业务和技术团队根据动机进行调整：

• 为什么走得更快？
• 如何更快地改善用户体验？
• 多快才足够快？
• 是否可以衡量提供更频繁发布的影响？
• 频繁部署有哪些风险和担忧？
• 为了支持更高的速度，还需要并行哪些其他业务和技术实践？
• 企业如何知道部署是否过于频繁？

回答完这些问题后，您将可以更好地了解要关注的实践以及所需的成熟度。

自动化测试和安全实践以提高可靠性

仅仅因为您的汽车可以以每小时90英里的速度行驶，并不意味着道路可以安全地如此快速地行驶。 软件开发也是如此，因此， 自动化测试和集成安全性都应该是CI / CD管道的一部分，以确保发行版对生产部署有效。

要评估测试，请考虑对应该自动执行的测试用例的完整列表进行分类。 该列表应该是广泛的，并涵盖应用程序的功能，API，集成和后台进程。 在统计上也应该有大量统计数据，并且可以使用各种测试数据来循环这些测试用例。

对这些测试用例进行分类后，就可以将它们用作基准。 有多少百分比的产品具有自动测试功能？ 通过这些测试需要多长时间？

如果大量测试是自动化的，并且运行成本很低，则表明它们可以集成到CI / CD管道中，并可以用于验证更频繁的发布周期。

为了安全起见，团队应在设计安全应用程序时使用OWASP项目原则 。 如果将应用程序部署到Azure，请查看并实施Microsoft的CI / CD安全验证做法 。 Jenkins用户可以集成插件以执行渗透测试，进行静态代码分析，扫描开源库以及进行其他漏洞测试。 如果应用程序使用容器，请实施Docker安全实践 ，查看Kubernetes安全最佳实践 ，并考虑这七个容器安全工具 。

[ 通过InfoWorld的App Dev Report新闻通讯了解软件开发中的热门话题 ]

准备好进行更频繁的部署

即使将应用程序设计为可进行更快，更频繁的部署，但仍可以在操作端进行工作以支持此频率和速度。

技术人员应该做的最后一件事是更频繁地发布应用程序，而又没有强大的应用程序监视功能来检测和帮助解决生产问题。 如果用户创建不稳定或降低性能，他们将不会支持频繁的部署。 与自动化测试类似，应用程序监视器也需要足够的覆盖范围，以确保在应用程序的全部或部分未运行时主动向网络运营中心（NOC）发出警报。

有了警报，IT组织应查看处理事件响应的过程。 如果大部分事件都上报给开发人员，那么增加发布频率可能会使他们不知所措，并导致总体开发速度下降。

回顾一下哪些Web或移动分析已启用并由业务和技术团队使用也是个好主意。 更加频繁地发布软件而不衡量结果并获得关于使用情况的见解，就像盲目驾驶一样。 团队应了解其更改是否为用户带来了积极影响。

[ 同样在InfoWorld上：如何停止讨厌吉拉 ]

定义最小可行的功能集

团队可以为更频繁的部署准备好所有技术实践，但是，如果敏捷产品所有者要求复杂的功能，这些功能需要更大的开发工作，则很难更快，更频繁地发布。

在这种情况下，向产品负责人提出有关其要求的问题是一个好的开始。 提供敏捷的估算值来说明所请求功能的复杂性和时间表可以打开一个对话框，以寻找简化需求或解决方案路线图的方法。 请记住，大多数产品所有者宁愿更快地在用户手中获得新功能和增强功能，因此提供选项和新想法可能会为用户提供更好的解决方案，从而更易于实现。

一些开发团队还希望实现功能标记，canary测试和A / B测试，以控制有多少新功能可用，有多少用户获得初始访问权限以及新功能是否在改善用户体验。 将这些功能嵌入开发流程和应用程序体系结构中是一种高度战略性的工具，可用于验证功能设计并实现更频繁的发布周期。

[ 通过InfoWorld Daily新闻通讯了解软件开发，云计算，数据分析和机器学习方面的最新发展 ]

培养沟通应用程序版本和变更的核心能力

开发团队可能并不了解与软件发行版相关的所有业务流程。 面向客户或影响客户的发行版通常需要与用户就新功能，文档更改进行沟通，有时还需要执行完整的营销计划。

企业应用程序用户具有相似的期望，并希望在发布之前和之后发出通知。 另外，如果应用程序产生数据提要或公开API，则应通知使用这些服务的内部和第三方开发人员。

经常部署应用程序的组织应考虑将主动通信作为业务和技术流程的一部分。 这是确保用户了解并适应更频繁的发布过程的最佳方法。

From: https://www.infoworld.com/article/3331919/how-to-drive-shorter-development-release-cycles.html