想象一下一个奇妙的情况-该公司的主管决定实施DevOps。 自己，没有技术专家的压力。 没有令人信服的竞争对手的榜样。 管理层本身认识到，如果没有DevOps工具，则在软件开发和实施中无法提高产品质量，业务流程的可预测性，透明度和可重复性。
赠送？ 奏效了吗？ 您已经成功通过了最丰富的想象力测试！
实际上，事实并非如此。 大多数情况下，管理不取决于我们的IT人员。 因此，您必须说服。 但是如何？
当提出一种论点以增强程序员与系统管理员之间的交流文化时，很容易遇到反驳：您现在不文明吗？ 或者，他们甚至可能使您想起您一起搬到Agile时公司在一两年前已经发生的费用。 每年IT中是否有一项功能可以革命性地推进流程？
至于提高产品质量，也可以结巴。 但是要小心。 由于没有错误的编程任务尚未取消。 是的，没有任何错误，但这就是该公司拥有“整个测试人员部门”的原因，对吗？
过程的可预测性通常是这样的主观因素，很难证明其合理性并避免开玩笑地谈论王和诺查丹玛斯。
而且，如果我们谈论的是典型的企业，那么在这样的公司中，很可能已经有一个成熟的IT团队。 而且这支有着旧习惯（敏捷除外）习惯的团队已经合作了很多年，几乎没有（再次）渴望改变某些东西。 一切都适合所有人，当然，除了领导层。 从中可以看出，他们的软件中不断出现错误，新版本的发布条件也发生了变化。
当然，当一个人在DevOps方面具有丰富的经验来到公司时，可以采用另一种选择，清楚地表明问题是什么以及应该如何解决。 谁能够将自己的意见传达给领导层。 但是，我们不要希望有一个奇迹叔叔。
许多打破这一点。 他们开始说没有人支持他们，在这个沼泽中不可能实现任何东西，然后简单地去另一家公司，在那里循环不断。
原来是恶性循环？ 不，只是渐渐地，我们得出的结论是，开展一项业务，您只需要用他能理解的语言（即金钱）来讲话。 为此，我们从宽袖腿获得了主要的王牌-缩短了上市时间。 我们需要证明，由于有了DevOps，该产品的新版本将像蛋糕一样发行。 最后，让我们将上述所有其余收益留给最终演示文稿使用DevOps来实现，当一切顺利时，我们将为导演创建这些演示文稿。 许多人会说这太明显了。 不行
我们需要的东西将占用我们最少的时间和资源（毕竟，没有人会为执行某些DevOps核销工作月，并且不会为我们紧急购买新服务器），但同时会带来非常明显的结果（实际上会减少时间-市场）。
首先，您需要找到一个瓶颈，但这始终是瓶颈（Goldratt约束理论的第一步）。 成功实施敏捷之后（只有在实施敏捷之后才有意义），就软件开发而言，他们仍然必须手动进行测试。 即使有空余资金，回归测试也可能需要两到三周的时间。 从测试人员“喜欢”进行回归测试的方式来看，我什么都知道。
因此，我们确定测试是瓶颈。 然后，您需要从自动化开始。 许多人会注意到：说起来容易做起来难。 已经编写了数百万行代码，如果程序员至少使用单元测试来涵盖某些内容，那将是一个很好的选择。 实际上，一切并不像看起来那样可怕。 经验表明，通过20％的努力，以缩短上市时间的形式成功取得成功的80％。 在我们的案例中，这就是测试自动化的成本。
完全按照帕累托定律。
最重要的是，您可以在管理层同意分配资源以实施DevOps其余部分的实施之前开始进行自动化测试。 一个小型的试点项目，可以在一到两个星期内自行完成。
但是与此同时，这种情况使我们有机会赢得一场壮观的，最重要的是快速的胜利。 之后，有了积极的态度和领导的祝福，您已经可以索取金钱和资源。
首先，可以肯定的是，您的程序员已经在使用某种服务器软件进行日常构建。 它可以是TeamCity，Bamboo或Jenkins，这无关紧要。 最主要的是，已经有一部分自动化技术需要使用，如果没有，那么一天之内就可以轻松部署它。
首先，您需要自动化烟雾测试。 但是，如何理解要自动化的东西呢？ 是的，只是看看过去六个月中发布更改时您经常遇到的问题。
接下来，您需要创建多个测试以验证主要业务流程的操作。 如何识别它们？ 询问您的分析师/主管/业务代表生气的主管冲向程序员办公室的那类故障，并以提高的声音来安排任务。
一周最多可以创建两个这样的测试。 结果是对于全局错误的非常快速的反馈。
尽管该项目处于概念验证模式，但您无需为测试和其他准备工作准备相同的自动服务器部署，而只需手动完成所有操作。 然后可以与管理员一起愉快地完成这种美丽。
这将导致不难猜测。 开发人员将立即发现（并纠正）他们的错误。 测试人员无需再进行冗长而繁琐的回归测试。 他们将有几天的时间只测试那些需要编辑的代码部分。 是的，完全正确。 如果不是，那么请回到起点，并与分析师/董事/业务代表就业务关键流程再次进行讨论。
消除了由于主制动器而引起的瓶颈。 现在剩下的就是在生产环境中发布一些新版本，删除“过去/以前”的统计数据，并将这些数字提供给管理层。 赢利！
在取得如此令人信服的胜利之后，您已经可以谈论展台部署的自动化（至少用于测试）。 接下来，要求资金用于监控和其他DevOps的乐趣。 应当记住，系统的其余组件将不再对企业产生惊人的影响。
工作室示例
在文章的结尾，我想举一个成功完成DevOps实施项目的示例，该示例已由我们公司实施。
一家大型零售商在网上商店中拥有约20％的业务。 同时，必须对市场情况做出快速反应并对软件进行必要的更改。 而且经常。 和高质量。 网站上的任何门框都可能影响转化，风险以真实货币表示。
为了减少更新和提高质量的时间，创建了一个专门的自动测试平台，该平台上用于自动化测试更改和网站回归的日常任务。 此外，还建立了自动化测试小组与开发团队的交互过程。 这使开发人员可以立即识别和纠正更新系统中的缺陷，而无需等待最终的验收测试。
零售商的代表认为这种体验很成功，因此决定将其应用于其他软件产品。
还有一个小例子，但是是从一家大型保险公司的实践中得出的。 在引入测试自动化之前，每六个月发布一次发行版。 不是因为业务如此需求-它只是没有经常工作。 而客户只是想要。 因此，在开始引入自动测试工具两个月后，IT团队便开始了两周的发行版本迭代。
足够重要地开始执行此操作，不是吗？
Sergey Stramnov，Jet信息系统软件解决方案中心的售前架构师