通过DevOps踏上软件交付的加速之路我们一次又一次地听到许多企业客户利用DevOps机制来实现快速交付。每天各大厂商都在不断宣传使用这种部署方式取得成功的实际案例，声称可以实现每天十个、五十个甚至上百个业务线的部署。在LinkedIn、Netflix、Etsy、Facebook等成熟的公司，这个数字甚至可以突破千人。但是，这一切到底意味着什么？IT领导喜欢谈论看起来令人兴奋的数字，并且经常将快速交付作为谈话的主要焦点。然而，这些软件交付方式是否稳定可靠？这些部署方案中的哪些实际上可以成功？综上所述。事实上，企业最常见的反应通常是“我们无法在公司取得成就，因为……”我们知道这种说法是站不住脚的。那些采用单一部署流程、瀑布机制、按月或按季度交付产品的传统企业，可以成功过渡到快速部署，从而像其他团队一样拥有理想的交付能力。那么，我们如何才能以软件交付为起点享受如此成功呢？世界上没有万能药，没有一步到位的解决方案，但每个人都可以通过方法论来引导自己达到快速交付的目标。让我们看一下入门的必要任务。让我们遵循这些关键原则，照亮通向光明面的道路。它们是：接受失败分析失败原因，但不要责怪任何相关人员了解原因后迅速修复失败因素永远迭代简而言之，我们的目标应该是快速部署、快速失败、快速学习和快速改进。这是一项永无止境的任务，我们需要继续从这个角度审视这个过程。我敢肯定你们都经历过项目开始时牢记这些原则，但随着项目结束，所有这些最佳实践都消失了。除非将持续改进作为核心要求传递给可交付成果，否则任何努力都可能随着时间的推移而失败。记住以上原则，我们继续下一步。软件是如何开发的？我们的第一站有时不隶属于交付组织，而是体现在开发组织。这就是“同理心”思维的作用所在，即站在对方的角度看问题。DevOps概念也恰恰解决了这个重点；我们首先需要确保负责交付功能的开发人员具备成功所需的条件。软件实际上是如何开发的？这对生产过程意味着什么？问自己这些问题：代码是如何引入到源代码树中的？可接受的代码有哪些特点？（例如，是否有代码格式化指南或必要的测试等支持机制。）明确了上述问题后，接下来的关键是改进代码，以便将其推向下一阶段的交付。但这通常是瓶颈发生的地方：虽然过去的历史示例可以作为尝试通过引入检查点来提高产品质量的有用指南，但这些检查点通常是人为驱动的——很明显，人工方法总是有其自身的缺陷。最重要的一点是区分代码的交付或功能的交付与软件本身的交付。虽然两者都是下一阶段工作非常重要的前提条件，但双方的职责往往各有侧重。在整个系统中，我们的需求一直是相同的：寻求机会通过分离流程步骤（即那些由传统机制造成的无价值的不必要元素）来减少摩擦，或者使用自动化来推进整个周期。考虑到这一点，开发和运营团队之间的对话可能会产生持久的启发，因为在良好的对话之后，双方都会清醒地意识到是什么在减慢流程。请保持专注，让我们继续下一个话题。这里有几个问题需要牢记：哪些员工可以编写软件？每个员工都能写软件吗？学习编写软件是否存在重大的进入障碍？证明有多难？同事们运行我们的演示代码有多难？哪些员工能够部署该软件？学习部署软件是否存在重大的进入障碍？我们需要在哪里分配任务？哪里讨论新特性的引入？#p#用“高端”来加速这个过程到这个地步，你可能已经对一套软件解决方案中需要改进的项目有了一个清晰的清单。但是我们应该关注哪里呢？现在的默认思路是先搞清楚发布机制，然后再尝试和外部团队合作好。然而，这实际上是最不明智的做法，因为它最终会导致开发和运营团队之间出现无法逾越的鸿沟。所以对大家来说，最好的判断可能是把对接放在第一位。我们的第一步应该侧重于两个主要目标。首先是将自己嵌入到开发工作流程中……通过现有流程从开发任务中提取项目元素，并有针对性地提出要求。这些断言将成为我们的“第一条轨道”，帮助我们了解哪些更改实际有效，哪些无效。此外，他们可以带来有价值的相关反馈，而其他不关心项目进展或主要精力集中在其他工作的同事通常不会提供这些反馈。总而言之，从小做起几乎是必要和理想的。在这个阶段，DevOps会提出大量所谓的“同理心”观点。无论为改进产品付出了多少努力，一旦摩擦因素开始出现在开发人员的日常工作中，改变导致真正成功的可能性就会越来越小。例如：底层交互平台的改变可能会显着改善每个人的沟通，但如果它扰乱了现有的传递渠道，结交新朋友的机会反而可能会减少。将您的主张整理成一份开发报告，并将其呈现给您的团队——反之亦然——并将其纳入整个执行流程。另外，不要忘记始终遵循前面提到的基本原则……快速部署、快速失败、快速学习和快速改进。尽快修复容易处理的流程漏洞。同样，密切关注在任何给定时间段内引入的变量数量，不要害怕做出改变，但同时要保持变化的一致性和衡量性。只要我们能够长期坚持以上几点，我们的整个发货流程就会得到理想的调整和完善。同样的道理，真正的项目成果是通过这个过程建立起来的。早期的成功确保开发人员可以以最小的努力运行任意代码版本（无论是gitchecked还是其他主要版本）。这使我能够使用其他同事的代码来测试我自己的开发以进行修复、识别错误等。有了运行任意代码的能力，我们可以协作加速代码开发过程，减少在开发过程结束时可能遇到的问题数量，这意味着大部分困难在过程的早期就得到了解决。这种效果对于分阶段交付环境非常重要，很可能是本地开发环境。但除此之外，搭建一个平台，让开发者在独立的小任务中运行代码，也能有效支撑后续的生产交付流程。一旦在流程和开发工作中发现错误，请记住一件事：分析并修复错误，但不要因此而责怪任何人。首先，项目前期会出现大量这样的问题，相信这也是我们每个人的共识。JohnAllspaw在他的文章中谈到了这一点，并以激励为主要观点：“因为工程师的心态往往认为他给出了特定故障的机制、原理和操作。理解必要的细节信息的实践不会受到鼓励，甚至可能会因此受到责备。这种对问题原因不了解的情况经常反复出现。而且如果以后负责相关工作的工程技术人员发生变动，以后还会出现更多的问题。多个故障不断出现。”另一个经常被忽视的问题是这些解决方案的实施方式。这样的修复过程不应该由一个人或以自上而下的方式驱动。相反，团队的所有成员都必须能够成为解决方案的一部分时间和鼓励会对长期的工作起到非常积极的作用最后是部署项目最终的意义就是部署代码至此，工作基本结束，接下来要做的就是注重开发和运维团队之间的互动，但双方也需要在一些任务上进行协作。除非每个人都能完美无缺地进行日常部署，否则彼此之间的沟通将贯穿整个部署过程。在我们的日常工作中，我们应该尝试代码部署——是否可以预见它的实际效果。另外，每天发现一两个问题并修复它们：要么是过程中的故障，要么是手动阶段的问题。这些任务不断重复，直到我们可以用最少的命令（最好是一行）完成日常部署目标。前方的道路依然坎坷，请做好心理准备！随着我们不断前进，我们将反复面对两个关键主题。一是通过沟通解决问题。随着时间的推移，部署将继续加速或简化，但即使是最好的团队也需要找到方法来克服沟通障碍带来的挑战。二是解决相关工具的使用能力问题。一旦工程师开始引入实施流程所需的工具，所有的人为因素和流程因素都将退居二线，或者以核心工具进行调整。这通常是一个无法逾越的障碍，因此此类工具需要真正参与参与软件交付的组织中各个成员之间的沟通。考虑到这一点，我推荐两个真正可以帮助您突破障碍的工具：CahtOps和Workflow。两者都是出色的解决方案，值得单独写一章。但是，限于篇幅，我们将在这里总结一下：它们是软件交付的重要组成部分。“ChatOps能够为我们已经完成的工作的对话添加上下文。”–JamesFryman“Workflow的机器可读脚本语言绝不仅限于对话。以动态方式创建、上传和更新工作流是必不可少的，应被视为“基础设施即代码”。”——DmitriZimine请记住：问题不限于单一工具。这些工具只是达到目的的手段。人们和流程需要成为对话的核心组成部分。ChatOps通过沟通和协作创建和驱动开发流程。Workflow从基础设施流程的角度实现整体协作。两者都应该是软件交付工作的组成部分。内容描述要成功作为技术人员，我们需要了解我们组织中正在发生的事情，技术如何帮助交付预期的结果，以及技术元素是如何被哪些用户部署和使用的。如果没有清晰的了解，我们将陷入引入工具的恶性循环我们遇到问题，但是工具的出现只会增加问题的复杂性。在这种情况下，工具往往是过程中出现瓶颈或完全沦为花瓶——因为人们根本不打算使用它们。在飞速发展的今天，精益的业务流程不会让我们把时间浪费在失败上。您了解您的团队如何交付软件并在此过程中进行协作吗？您的团队与您提供服务的对象之间是否有紧密的反馈渠道？您是否有能力快速行动并更快地解决问题？今天，软件交付速度被广泛认为是市场竞争中差异化优势的典型代表。实现这一目标的道路不会一帆风顺，但一旦实现，我们的组织将同步进入下一阶段的快速增长。原标题：从DevOps开始软件交付加速
