在今天的数字时代，许多商业创新都是由软件驱动的。为了赢得、服务和留住客户，企业的任务是以越来越快的速度发布应用程序更新。一个好主意、杀手级的功能和强大的技术都和以往一样重要——但如果你不能以一种快速、可预测的方式高质量地将代码提供给最终用户，那就没什么意义了。你的"生产之路"就是你的代码从开发人员签入到成功发布的路径。它跨越了整个组织-包括所有不同的涉众、团队、过程、工具和环境，涉及到您的软件交付。基本上，这就是你的组织如何向市场提供价值。我们越来越多地看到，那些在简化和加速生产途径方面变得更好的组织更有能力在当今的经济中竞争和获胜。软件发布过程的成熟度、速度和质量已成为当今企业的一个关键区别点和竞争优势。DevOps和ARA：为生产铺平更好的道路DevOps和Application Release Automation（ARA）已经出现，帮助组织更好地交付软件，从而在降低软件发布风险的同时实现更高的速度和灵活性。DevOps有巨大的商业利益：统计数据显示，实施DevOps的组织在3年内的表现超过SMP500，返利机器人哪个好用，高绩效的IT组织的市值增长率高出50倍，企业软件正版化，等等。为了保持竞争力和满足消费者的需求，各大企业都在采用DevOps来优化生产路径。正如您将投资于为您的产品设计正确的功能，或定义一个成功的进入市场计划，组织现在投资于优化和（重新）设计他们的生产路径，以实现创新。在大型组织中实现DevOps带来了一系列独特的挑战。企业通常需要支持大量的分布式团队和多个应用程序/产品版本。此外，监管和治理要求、支持遗留系统、工具种类、基础设施管理和复杂的内部流程进一步加剧了这些挑战。我想讨论DevOps在企业中采用的演变，以及我认为DevOps革命的下一个阶段。企业中的DevOps：从小处做起，云主机服务器，Dev领先。敏捷方法被许多软件组织所采用，主要集中在开发、QA和产品管理功能上，而很少关注一旦软件被开发出来就进入生产的途径。作为敏捷的延续，数据统计，DevOps也是从一个非常受开发人员驱动的运动开始的（尽管名字中有"Ops"）。开发团队更快地采用了这些实践，因为他们渴望找到一种方法让他们的代码更快地投入生产。传统上，Ops在采用DevOps时比较犹豫，认为速度和速度的提高可能会带来风险。目前大多数的DevOps实现仍然是在小团队中作为基层计划开始的。这没关系，这是展示早期成功并扩大规模的好方法。随着这些自下而上的努力，我们越来越多地看到DevOps的转变，这是一项全公司范围的计划，在执行层面和团队层面都得到了支持。下一阶段：扩展DevOps，Ops占据中心位置。大型企业面临的最大挑战之一是人员、流程和工具集的"筒仓"。通常，其中一个或多个筒仓可能非常擅长理解和自动化他们的部分难题，但没有端到端的可视性或整个路径的自动化。这会导致流程分散、手动切换、延迟、错误、缺乏治理等。由于生产路径跨越整个组织，企业意识到优化it不是一组完全不同的问题，而是需要系统级的方法。DevOps的发展趋势是在整个企业范围内进行大规模采用，以涵盖生产的端到端途径。这通过自动化交付管道的所有方面来消除摩擦，以创建可预测、可重复的流程，这些流程可以在越来越少的人为干预下频繁运行。通过在整个生命周期中实现流程和部署的一致性（包括QA、Staging、Prod），您实际上一直在"练习"游戏日，并在优化DevOps实践时强化它们。作为这一过程的一部分，随着DevOps的成熟和成为企业的主流（而且它对企业的运营越来越重要），DevOps实践被"强化"以考虑对发布的更多"运营"要求：主要围绕可管理性、治理、安全性和合规性。谈论"企业控制"不再是坏事，也不再是阻碍DevOps采用的东西。DevOps致力于在保证稳定性的同时实现速度。我们现在应该学会走路更快，更成熟。与您的组织正在开发的软件一样，是时候"强化"您的DevOps实践，以在整个组织的端到端流程中扩展采用。"强化"并不意味着牺牲速度或实验；它意味着你的DevOps正在为黄金时间做好准备！"强化"您的DevOps实现：您希望设计您的底层工具和过程沿着您的生产路径，以一种可以扩展到整个企业的方式。这需要平衡团队所有权和协作，并支持组织对制衡、标准化和系统级可见性和控制的需求。虽然您可能仍然会开始"本地"，并在优化过程中逐步在不同的组中展开，但请务必始终考虑"全局"。当你分析和（重新）设计你的生产路径时，你需要采取一种全系统的方法，点云，并始终考虑：我该如何扩展？-跨所有团队、应用程序、版本、环境等。首先，花点时间来绘制生产的端到端路径。根据我的经验，组织通常甚至不知道他们的代码从签入到构建、测试、跨环境部署等整个过程，直到您获得一份详细的跨职能管道文档，包括所有涉及的工具、技术、基础设施和流程。然后，看看瓶颈——你的管道在哪里堵塞？例如：等待vm、等待构建、环境之间的配置漂移、失败或不稳定的测试、使其投入生产的bug、失败的发布、由于团队或工具之间的手动切换而导致的错误或延迟等等。当您重新设计管道以消除摩擦点时，在您"强化"DevOps实践以支持整个组织的稳定性和扩展性的过程中，需要考虑以下几点：如何确保管道沿线关键点的安全访问控制和审批门？我如何保证可视性和可审计性—这样我们就可以实时报告整个流程中每个任务的状态，并记录到底谁做了什么/在哪里/何时做了什么？所有流程都必须遵守哪些安全和合规性测试（或其他测试），才能通过管道进入生产？如何在工具链、技术和流程上尽可能标准化我的管道，以允许跨团队/应用程序的可重用性并节省成本？我如何仍然启用可扩展性和灵活性来支持来自不同团队或应用程序变体的不同需求？我选择的DevOps解决方案能否协调和自动化整个端到端管道？我的实现能否支持双模IT——支持传统的发布实践和对遗留应用的支持，以及更现代的容器/微服务架构和CD管道？我是否可以同时支持更简单、线性的发布管道，以及需要在许多环境中协调许多相互依赖的应用程序和组件的复杂版本？我的解决方案是否"面向未来"，是否足够灵活，能够在需要时插入任何新的技术堆栈、工具或流程？随着我规模的扩大，我的实现能否支持我所期望的整个组织的速度和整个过程—包括数千名开发人员、数千个发布版、数百万个构建和测试用例。？为一个团队/版本设置一个管道是很容易的，但是我如何装载数千个应用程序呢？虽然优化您的工具和技术以扩展DevOps的采用是很重要的，但这只是成功的一半。最重要的是，DevOps是一种心态，文化转变需要时间。记住，改变不是一天发生的，而且你是长期的。作为一个社区，我们开始问为什么要费心做DevOps。在建立了势头并证明了DevOps的投资回报率之后，讨论逐渐演变为我们如何在大型企业中实现DevOps的正确性：成功的一些模式是什么，以及我们如何有效地扩展以使整个组织都能获得利益。本文最初发表在InfoWorld上