持续交付 devops_使用DevOps开始加速软件交付

持续交付 devops

一次又一次，我们听说公司借助DevOps实现了快速加速。 公司正在以每天的部署量来吹捧成功，共享每天10、50甚至100个部署的新基准。 在更成熟的组织中，例如LinkedIn，Netflix，Etsy，Facebook和其他组织，这个数字是惊人的1,000多个数字。 但是，这甚至意味着什么？

拆开这个数字通常是IT领导者偶然发现的，并且是谈论快速加速时最大的推销来源。 软件交付的稳定性如何？ 这些部署中有多少成功？ 什么是部署？

这些问题以及更多的情况最终导致分析瘫痪，并且没有任何变化。 实际上，最常见的回应始于：“我们不可能在我的公司实施类似的事情，因为……”我们知道这是错误的。 传统上以瀑布式方式交付的公司每月或每季度仅进行一次，肿的部署，这些公司已成功过渡到发布了与其他团队类似的基准数量的快速部署。

那么如何才能成功开始交付软件？ 没有单一的子弹或魔杖，但是有一种相当规范的方法可以实现我们的快速交付目标。 让我们深入研究一下入门方法。

基本规则

让我们通过一些关键原则为舞台打下基础，这些原则将阐明前进的道路。 他们是：

• 拥抱失败
• 无懈可击地分析故障
• 了解后快速修复故障
• 一直在迭代

简而言之，目标应该是快速部署，快速失败，快速学习和快速改进。 这是一项永无止境的任务，因此应如此考虑。 太多次，一个项目被启动以开始执行这些任务，并且不可避免地该项目结束。 除非持续改进成为交付的核心租户，否则任何努力都有可能随着时间的流逝而瓦解。

牢记这些规则，让我们继续。

如何开发软件？

顺便说一句，不是在交付组织内部，而是开发组织。 这就是经常与DevOps讨论的移情的地方。 我们首先需要确保提供功能的开发人员具备成功的条件。

如何开发软件？ 进入生产流程真正意味着什么？ 问自己一些问题，例如：代码如何引入源代码树？ 接受该代码是什么样的？ （例如：是否有代码格式化准则，是否需要测试等）

一旦理解了这一点，关键就是为将代码推进到下一个交付阶段而存在的大门。 这是瓶颈经常存在的地方，并且经常存在有效的历史案例。 通常，这是为了尝试通过引入检查点来提高质量，但是这些检查点通常是人为驱动的，并且总是会包含其自身的缺陷。

重要的是要区分代码的交付或功能的交付与软件本身的交付。 两者都很重要，如下一节所述，但同一枚硬币的两侧通常是分开的。 在整个系统的上下文中，需求是相同的：通过从流程中删除步骤（无需不必要的增值，过时的痕迹）或引入自动化流程来寻找减少摩擦的机会。

这些对话总是很有启发性的，因为在进行一些初始对话后，放慢速度的地方会变得很明显。 保持这些脑汁畅通，让我们继续。

以下是一些要记住的问题：

• 谁可以编写软件？ 大家？
• 学习如何编写软件的入门障碍是什么？
• 向同事展示工作代码有多困难？
• 同事运行您的演示代码有多困难？
• 谁可以部署软件？
• 与学习如何发布软件相关的进入障碍是什么？
• 工作分配到哪里？
• 功能讨论在哪里进行？

将事情推向高潮

至此，您可能已经有了一份清单，其中列出了您已确定需要改进的地方。 但是，您将重点放在哪里？ 默认的趋势是先清理商店，然后与外部团队合作以尝试更好地整合。 但是，实际上这是最不理想的事情，因为它最终会导致隔离孤岛。 可能违反您的更好判断，请先计划进行集成。

您的第一步应该集中在两个目标上。 首先是使自己融入开发工作流中……通过现有过程从开发中获取工作项，并找到自己的拥护者。 该倡导者将是您的“第一跟从者”，并将帮助您了解哪些更改在起作用，哪些无效，并且将提供有价值和诚实的反馈，这些反馈可能不是来自其他成员，不是因为他们不在乎，而是因为他们的精力专注于其他事情。 从小处开始几乎是必要的。

在大多数情况下，提到DevOps时都会出现同理心。 无论您为改善问题做出何种努力，开发人员生活中遇到的任何摩擦都会极大地影响您在任何实际变更中的成功。 例如：更改基础的票务平台以使所有人都能更好地进行交流可能会很有利，但是如果您破坏了现有的交付渠道，结交新朋友的几率可能会下降。

与倡导工作，坚定发展报告如何发放到你的团队，反之亦然，并通过笞刑运行它 。 不要忘记应用基本规则…… 快速部署，快速失败，快速学习和快速改进。 快速修复容易的Craft.ioKong。 请注意在任何给定时间要引入的更改量，不要害怕进行更改，还要与更改保持一致并进行衡量。 这将为持续和长期的流程改进设定适当的基调。

同样，通过第一个过程进行实际项目。 早期的胜利可以是确保开发人员能够以最小的努力运行任何版本的代码（git checkout，主要版本，都没有关系）。

这使我可以运行其他同事的代码来测试修复程序，确认错误或其他。 通过具有运行任意代码的能力，协作速度可以最接近代码，并且可以更早地解决直至后期部署阶段的问题数量。 这可能意味着暂存环境。 这可能意味着本地开发环境。 但是，解决开发人员如何运行代码的较小任务成为生产交付管道如何运行的测试床。

当您在过程和工具中都发现故障时，在分析和处理故障时保持无懈可击至关重要。 尽早有很多，因此尽早定调至关重要。 John Allspaw在讨论奖励措施时在其文章中谈到了这一点：

因为认为自己将受到谴责的工程师没有受到激励，无法提供必要的详细信息，以了解故障的机理，病理和操作。 对事故如何发生的了解不足，只能保证事故会再次发生。 如果不是与原始工程师一起，将来还会有另一个。

另一个经常被忽视的问题是如何实现这些解决方案。 不能由一个人或以自上而下的方式来修理这些过程。 而是，团队的所有成员必须是拥有解决方案的一部分。 时间和鼓励将花很长时间。

最后，部署。 该项目的重点是部署代码。 到目前为止，已完成的工作将主要集中在开发与运营之间的交互上，但是可以肯定的是，双方都需要完成工作。 在您可以每天进行部署而不会造成任何损坏之前，这应该是您的目标。 无论您是否已经知道结果，每天都要尝试部署代码。 每天选择以下两项要解决的问题之一：该过程失败或手动操作。 重复此过程，直到每天可以用最少数量的命令进行部署（最佳情况：单个命令）。

前进的道路很危险，请选择这些！

当您沿着这条道路前进时，似乎会一次又一次出现两个主题。 首先与沟通有关。 随着时间的流逝，部署过程可能会变得更快或更简化，但是始终存在沟通障碍导致最佳团队挑战的方式。

第二个总是与工具差异有关。 一旦工程师大为鼓舞，需要实施工具，所有人员和流程问题将成为次要问题。 由于这些工具实际上需要参与组织内部的通信流以促进软件交付，因此这通常变得很麻烦。

为此，有两种非常有用的工具值得您记住： ChatOps和Workflow 。 这两个主题均应专门用于其自身的整个部分，但简而言之，这是应该磨合您的调色板的两件事。

ChatOps将您正在做的工作的上下文带入您已经进行的对话中。 –詹姆斯·弗里曼

用于声明工作流的人类可读的，可通过机器编写脚本的语言不只是方便。 这是在实时系统上动态创建，上传和更新工作流以及处理“基础架构即代码”的必要条件。 –德米特里·齐明（Dmitri Zimine）

请记住：这不是一种工具。 这些工具是达到目的的一种手段。 人员和过程必须成为此对话的一部分。 ChatOps支持创建和驱动开发的通信和协作。 工作流支持围绕基础架构流程的协作。 这两个都将变得至关重要。

外卖

为了取得成功，我们作为技术专家需要了解组织中正在发生的事情，技术工作如何帮助交付，所部署的技术如何被消费以及由谁使用。 没有这种了解，我们只会将工具丢在一个问题上，并且常常使事情变得复杂。 这些工具可能会卡住东西或成为架子商品，因为没有人准备实施它们。 在当今快速发展，精益的业务中，没有时间崩溃。

您知道您的团队如何围绕软件进行交付和协作吗？ 您的团队与提供服务的团队之间是否建立了紧密的反馈循环？ 您的移动速度很快，并且修复速度更快吗？

如今，团队如何交付软件已Swift被公认为是市场差异化因素。 此过程既不容易也不容易，但将使您的组织为行业的快速发展的下一阶段做好准备。

翻译自: https://opensource.com/business/15/6/beginning-software-delivery-acceleration

持续交付 devops