我最近被邀请参加在曼彻斯特IPExpo举办的DevOps项目，并分享我在采用持续交付方面的一些经验。这使我们从专注于Jenkins的特性和技术上有了一个令人耳目一新的变化。在准备这次演讲时，它让我想起了我多年来参与的项目，哪些项目成功了，哪些项目成功了不。什么我的结论是没有单一的"神奇答案"。这不是工具的选择、应用程序的类型、遵循的方法或单个开发人员的技能。然而，忽略这些方面的任何一个方面都有可能导致错过持续交付的真正好处少数：提供价值为早期的用户/客户提供更高质量的系统和部署，在项目的早期以可持续的（和可预测的）发展节奏和更少的团队无精打采的浪费我的工作陷入了连续交付，却没有意识到这是什么叫。开发团队已经采用了敏捷/Scrum，并且正在用一个健壮的持续集成实现来逐步构建软件。我的团队专注于环境和部署方面。作为一个开发思维，我们基本上是懒惰的，在正确的意义上-为什么要做无聊的重复的东西，而你可以自动化它-所以我们做到了。回过头来看，我们已经实现了所有环境的完全自动化，包括完整的操作系统安装和配置、到应用程序部署、数据库更改应用程序和负载平衡器配置。每次生产部署都导致了全面的基础设施拆除和重新供应。顺便说一句，这是大约七年前的事了，而且是傀儡之前的事，所以最新和最好的工具并不总是需要成功的。魔鬼在于对细节的严格和持续的关注——根本没有所谓的局部自动化！就像我在会议上说的，如果你买的"自动汽车"只在1-4档之间自动换档，而你必须在5-7档之间自动换档，你会相当不安的！但当我想得更多的时候，我也参与了最近的一些项目，尽管我们希望采用持续交付，但我们并没有完全成功。为什么？随着我思考的深入，我们越来越清楚地认识到，我们需要以同样的关注点覆盖人员、流程和技术领域。可能最难的领域是人。持续交付不仅需要团队内部思维方式的改变，还需要更广泛的利益相关者的支持，如高层管理者、业务用户/利益相关者以及管理供应商关系和目标的关键方式。在我的演讲中，我提出了一些模型，用于评估您在各种能力中的当前状态，并设定要改进的增量目标。它还讨论了如何为最初采用连续交付选择一个探路者项目，以及从团队级采用扩展到更广泛的企业范围时需要考虑的领域出去。如果你想让我在你的活动中进一步讨论这个问题，请联系。