我们一次又一次地听到公司通过 DevOps 实现快速加速的消息。公司都在吹捧他们在每天部署次数这一指标上取得的成功，分享每天 10 次、50 次甚至 100 次部署的新基线。在更成熟的组织（如 LinkedIn、Netflix、Etsy、Facebook 等）中，这个数字惊人地超过 1,000 次。但是，这到底意味着什么呢？
剖析这个数字通常是 IT 领导者会遇到的难题，也是在谈论快速加速时阻力最大的来源。交付的软件有多稳定？这些部署中有多少是成功的？部署的构成是什么？
这些问题以及更多问题通常最终导致分析瘫痪，结果一事无成。事实上，最常见的回答是以“我的公司不可能实现这样的事情，因为……”开头。我们知道这是不真实的。传统上以瀑布式方式交付，每月或每季度进行一次臃肿部署的公司，正在成功转型为快速部署，发布与其他团队类似的基线数字。
那么，如何才能在开始软件交付方面取得成功呢？没有万能的灵丹妙药或魔法棒，但是有一套相当规范的方法来实现我们快速交付的目标。让我们深入了解一下如何开始。
基本规则
让我们先确定一些关键原则，这些原则将照亮前进的道路。它们是
- 拥抱失败
- 无责分析失败
- 在理解失败后快速修复失败
- 始终迭代
简而言之，目标应该是快速部署、快速失败、快速学习和快速改进。 这是一个永无止境的任务，重要的是要将其视为一个持续的过程。很多时候，会启动一个项目来开始处理这些任务，但不可避免地，该项目会结束。除非持续改进成为交付的核心原则，否则任何努力都可能随着时间的推移而崩溃。
牢记这些规则，让我们继续。
软件是如何开发的？
第一步恰好不在交付组织内部，而是在开发组织内部。这就是经常与 DevOps 一起讨论的同理心的用武之地；我们首先需要确保交付功能的开发人员能够成功。
软件是如何开发的？进入生产流程到底意味着什么？问问自己这样的问题：代码是如何引入源代码树的？代码验收是什么样的？（例如：是否有代码格式指南，是否需要测试等）
一旦理解了这一点，关键在于将代码推进到下一个交付阶段的关卡。这通常是瓶颈存在的地方，而且通常有合理的历史原因来解释其存在。通常，这是为了通过引入检查点来提高质量，但这些检查点通常是人为驱动的，并且不可避免地会包含自身的缺陷。
区分代码交付或功能交付与软件本身的交付非常重要。两者都很重要，如下一节所示，但这是同一枚硬币的两面，通常是分开的职责。在整个系统的上下文中，需求是相同的：识别通过从流程中删除步骤（非增值、不必要、旧时代的遗迹）或引入自动化来推动事情进展来减少摩擦的机会。
这些对话总是令人大开眼界，因为在进行一些初步对话后，减速发生在哪里将变得非常明显。保持大脑运转，让我们继续。
以下是一些需要牢记的问题
- 谁可以编写软件？所有人？
- 学习如何编写软件相关的障碍是什么？
- 向同事演示可运行的代码有多困难？
- 同事运行您的演示代码有多困难？
- 谁可以部署软件？
- 学习如何交付软件相关的障碍是什么？
- 工作分配在哪里？
- 功能讨论在哪里进行？
加速
到目前为止，您可能已经列出了一长串您已确定为需要改进的领域。但是，您应该关注哪里呢？默认的趋势是先清理内部，然后再与外部团队合作，尝试更好地集成。然而，这实际上是最不理想的做法，因为它最终会造成孤立的孤岛。可能违背您的更好判断，计划首先进行集成。
您的第一步应侧重于两个目标。首要目标是将自己嵌入到开发工作流程中……通过开发人员现有的流程从他们那里获取工作项，并为自己找到一位拥护者。这位拥护者将成为您的“第一位追随者”，他将帮助您了解哪些更改有效，哪些更改无效，并将提供来自其他成员的宝贵和诚实的反馈，这可能不会来自其他成员，不是因为他们不在乎，而是因为他们的精力集中在其他事情上。从小处着手几乎是必要的。
在大多数时候提到 DevOps 时出现的同理心观点将在这里发挥重要作用。无论您做出什么努力来尝试改进事物，任何引入开发人员生活中的摩擦都会极大地影响您在任何真正改变中取得成功。例如：您可能需要更改底层票务平台，以便更好地沟通，但如果您扰乱了现有的交付管道，结交新朋友的可能性可能会降低。
与您的拥护者合作，确定开发人员如何向您的团队报告问题以及反之亦然，并让它经受考验。不要忘记应用基本规则……快速部署、快速失败、快速学习和快速改进。 快速修复简单的流程漏洞。请注意在任何给定时间引入的更改量，不要害怕进行更改，但也要保持一致并衡量这种更改。这将为持续和长期的流程改进奠定适当的基调。
同样，通过第一个流程完成一个真实的项目。早期的一项胜利可以是确保开发人员能够以最小的努力运行任何版本的代码（git checkout、主要版本，都无关紧要）。
这使我可以运行其他同事的代码来测试修复、确认错误或诸如此类的事情。通过能够运行任意代码，协作在最接近代码的地方加速，并且冒泡到部署后期阶段的问题数量会更早地得到清理。这可能意味着暂存环境；这可能意味着本地开发环境。但是，解决开发人员如何运行代码这个较小的任务将成为生产交付管道可能如何运行的试验台。
当您发现流程和工具方面的故障时，在分析和解决故障时，无责非常重要。早期会有很多故障，尽早定下基调至关重要。John Allspaw 在他的文章中讨论激励措施时谈到了这一点
因为认为自己会受到谴责的工程师会不愿意提供必要的细节来了解故障的机制、病理学和操作。这种对事故如何发生的缺乏理解几乎保证了它会重复发生。如果不是原来的工程师，也会是未来的另一位工程师。
另一个经常被忽视的问题是如何实施这些解决方案。这些流程的修复不能由一个人驱动或以自上而下的方式进行。相反，团队的所有成员都必须参与拥有解决方案。时间和鼓励将大有裨益。
最后，部署。这个项目的全部意义在于部署代码。到目前为止所做的工作主要集中在开发和运营之间的交互上，但可以肯定的是，双方都有工作要做。在您能够每天部署而不会出现任何中断之前，这应该是您的目标。每天，尝试进行代码部署，无论您是否已经知道结果。每天选择一两件事来修复：流程中的故障或手动步骤。重复此操作，直到您可以每天以最少数量的命令（最佳情况：单个命令）进行部署。
前方的道路是危险的，带上这些！
当您沿着这条道路前进时，会出现两个反复出现的主题。第一个与沟通有关。随着时间的推移，部署流程可能会变得更快或更精简，但总是有一些沟通障碍会导致最佳团队面临挑战。
第二个总是与工具差异有关。一旦工程师意识到需要实施工具，所有人员和流程问题都会退居其次。这通常会变成一个泥潭，因为这些工具实际上需要参与组织内的沟通流，以促进软件交付。
为此，在您沿着这条道路前进时，有两种工具非常有用，需要牢记：ChatOps 和 工作流。这两个主题都值得专门用整节来介绍，但简而言之，以下是应该引起您兴趣的两件事。
ChatOps 将您已经在做的工作的上下文带入您已经在进行的对话中。– James Fryman
用于声明 工作流 的人类可读、机器可脚本语言不仅仅是便利。对于动态创建、上传和更新实时系统上的工作流以及将“基础设施即代码”视为必需品而言，这是必需的。– Dmitri Zimine
请记住：这不仅仅关乎一种工具。这些工具只是一种手段。人员和流程必须成为对话的一部分。ChatOps 实现了创建和驱动开发的沟通和协作。工作流实现了围绕基础设施流程的协作。这两者都将变得至关重要。
要点
为了取得成功，我们作为技术专家需要了解我们组织中正在发生的事情，技术努力如何帮助交付，以及正在部署的技术如何被消费以及被谁消费。如果不了解这些，我们只是在问题上抛掷工具，并且常常会使事情复杂化。这些工具可能会使事情陷入僵局或成为货架ware，因为没有人准备好实施它们。在当今快速发展、精益化的业务中，没有时间发生故障。
您是否了解您的团队如何交付软件以及围绕软件进行协作？您是否在您的团队和您提供服务的团队之间建立了紧密的反馈循环？您是否在快速行动，并且修复速度更快？
如今团队交付软件的方式正迅速被认为是市场差异化因素。这个旅程既不容易也不快，但将使您的组织为行业下一阶段的快速增长做好准备。
评论已关闭。