DevOps蛋糕!

常言道，重要的不是目的地，而是过程。DevOps及其在组织中的实现也是如此。是的，结果是神奇的，因为它旨在交付日常业务价值，但过程更有趣。这段旅程充满了组织上的、技术上的，尤其是人的发现。

在过去的几年里，我陪伴过一些已经开始或已经开始向敏捷过渡的公司，这些客户中的大多数都希望在他们的组织中建立DevOps文化，尽管他们没有明确地说出来。而其他人则直接问我这个问题:如何实现DevOps文化?

在所有的项目和公司中，我看到了一种“模式”，多年来，它已经成为实现DevOps实践的一个命令。这当然不是唯一的方法，但这是我见过的与许多客户合作的方法。

这就是我所说的DevOps蛋糕……

在过去的几周里，通过解释这个“模式”，我画出了一个看起来像婚礼蛋糕的东西，所以这是它名字背后的原因……作为一个蛋糕，每一步都依赖于前面的步骤是坚实的，并给出最好的结果。

步骤1 -持续集成

这第一步是接下来所有事情的基础，甚至是基石。这是第一个原因，因为通常敏捷性的实现总是从一个或多个开发团队开始，持续集成通常是Scrum团队要做的第一件事。持续的集成只会使开发团队变得混乱，并且会使组织的其他部分不受影响，从而使这一步成为一个战略选择。
在这个阶段，团队将被迫以这样一种方式进行设计和开发，他们可以在日常的基础上进行集成，否则将极大地复杂化他们的工作，甚至成为阻碍。不幸的是，正是在这个阶段，一些组织将被阻止，因为下一步，通过测试进行设计，是将带来团队外部变化的第一步。

步骤2 -自动测试和根据测试进行设计

第二步是我最喜欢的步骤之一，原因有几个。首先，这个阶段验证设计和开发是否遵循良好的敏捷实践。其次，它验证了组织是否理解并相信敏捷性，因为前一个阶段只是推动开发团队，这一步将在几个层面上扩大干扰:

• 这一步将扰乱管理，习惯于过去的速度不包括自动化测试的开发，团队的新速度将扰乱他们的计划。

• 自动化的验收测试会让业务人员(例如产品负责人)感到不安。这种实践的引入，如果要取得成功，将迫使他们以不同的方式来切割他们的故事，并在用例中思考。然后，为了允许开发团队正确地设计上游测试，应该为sprint计划很好地定义验收标准。

通常在这个阶段，Scrum会受到冲击，妥协将不再扰乱做事的方式，也不再让人们感到不适，而是让人们学习。正是由于这个原因，一些组织仍然停留在这个阶段，甚至完全停止了自动化测试的实践。通过这样做，他们对实践的看法和理解仍然受到提高技能的成本的影响，而没有从积极的结果中受益。

这个步骤是我最喜欢的步骤之一，因为开发团队经常在这个阶段进行点击。正是在这个阶段，团队意识到持续集成的真正价值，以及拥有大量自动化测试(包括统一测试和验收测试)的好处。

步骤3 -将数据库集成到迭代开发中

当Scrum团队在前两个步骤中达到一个成熟的水平时，在回顾时可以观察到这一点，团队开始将数据库识别为更快地交付业务价值的阻碍因素。在数据库建模和更改只能由dba(数据库管理员)完成的组织中尤其如此。这个问题没有更早出现的原因之一是，开发团队在前面两个阶段都学到了很多东西，这使得DBA可以在保持自己的方式的同时跟上Scrum团队的步伐。

除了NoSQL数据库的出现，与软件开发的其他领域相比，数据库世界的运作方式并没有太大的变化，这就是为什么这一步将给DBA带来不同的挑战:

• 随着冲刺的节奏，开发团队并不总是能够提前几周或几天预测他们在模型中需要的修改。这将导致dba在sprint开始时超载请求，而这种超载将成为开发团队的阻碍。因此，开发团队必须能够自主地对数据库模式进行更改，因为提前几个sprint提供修改并不是解决方案。一个潜在的解决方案是向定义中添加一个项目，以便DBA查看模式更改，例如代码审查。
• 由于数据库更改可以由开发团队的任何成员进行，因此这些更改必须遵循与其余代码相同的规则:每天进行自动化、版本控制和合并。

因此，一夜之间就要求他们改变工作方式和工具，以跟上Scrum团队的步伐，这是不安全的。我相信他们可以从做出改变中获得一切，让组织受益于他们的知识，而不是负责设计和运行SQL脚本。如果您希望能够自动化整个部署过程以包含数据库，那么这一步对于下一步至关重要。

步骤4 -持续交付

Scrum团队和旨在实现DevOps的组织的下一步是自动化部署。通常，当团队达到前面步骤的成熟水平，并希望将部署包含在他们的价值交付过程或完成的定义中时，就会出现此步骤。

在前面的步骤中介绍了dba之后，这次我们将介绍广义上的基础设施团队。像DBA团队一样，基础设施团队必须改变他们的工作方式，这意味着给开发团队更多的灵活性。我的意思是，基础设施团队(Ops)必须定义配方或容器，但让开发团队(dev)自由地放置他们想要的东西。因此，要有一个满足他们需求的基础设施，而不是在组织中通常看到的“一刀切”的基础设施。

除了自动化部署工具的学习曲线之外，这一步通常不是技术上的挑战，而是组织上的挑战，因为在大多数组织中，Dev和Ops之间通常有一段历史。正是由于这个原因，我们在这个阶段看到了功能障碍，这将是未来在组织中植入DevOps的挑战。

基础设施团队(包括经理)不应该再将基础设施视为他们的财产，而应该将其视为开发团队更快地交付业务价值的工具。为了对容器负责，而不是对内容负责，Ops团队必须改变他们看待事物的方式，从而尊重他们的目标以及开发团队的目标。在这个阶段，通常每个阶段(开发、阶段和生产)的基础设施都是手动创建的，但是部署将是自动化的。在某些情况下，这将导致阶段之间的不一致，但最重要的是对运维团队造成巨大的压力，通过手动方法，他们将难以遵循Scrum或看板团队的节奏。不幸的是，要进入下一个阶段，就像DBA一样，是学习和改进的压力或愿望将使运维人员走向整个基础设施创建的自动化。

步骤5 -“作为代码的基础设施”

这是最后一步，在这个阶段，技术将成为减少团队压力的解决方案，Ops的压力，同时加速开发人员的交付周期。正如我前面所说的，在我们进入这个阶段之前，组织和运维人员都必须看到做事情的旧方法，这些方法本身并不坏，但不能适应敏捷的步伐。通常，在这个阶段，开发人员和组织的运维人员一起建立工具和技术，以尊重每个人的任务，正如我在另一篇文章，两者正好相反。只有在此之后，DevOps实践才能在整个组织中实现。这些工具和方法将使Ops能够生成自动化的技术配方，并将其提供给开发团队。因此，基础设施将是不可改变的，并由Ops定义为一个整体，同时允许开发人员使用它们，并根据业务价值优先部署软件增量。

组织在向DevOps发展的过程中，或者只是为了提高敏捷性的实现，通常会遵循这个循环，正如你所看到的，有几个步骤可以达到这个目的。每一次，当人们对当前阶段所涉及的一切都变得成熟时，他们就会被推向下一个阶段。正是由于这个原因，我经常说我们不能敏捷，这是我们必须趋向的一种理想，因为总是有可以改进的地方，无论是我们自己还是我们做事的方式。

我没有明确地说过，但它是一个敏捷框架，像Scrum或看板，它刺激了DevOps文化中必不可少的持续改进。当我们仔细观察步骤的顺序时，我们可以发现3个紧密联系在一起的元素，敏捷过程、工具和人员。而在基础上，正是这个连续的循环，使我们能够通过这5个阶段，同时为整个组织获得收益。

当你到达最后一个阶段时，它还远远没有结束!

现在的挑战是减少整个组织的周期时间。我的意思是，减少一个想法的出现或新需求的识别到其在生产中部署之间的时间。在敏捷框架(如Scrum或看板)的帮助下，不断检查和调整我们的过程，这就成为可能。

正如我在文章开头所说，DevOps的植入是一个发现之旅，在整个组织中发现功能障碍。这听起来可能是消极的，但事实远非如此，因为这些功能障碍只是组织和相关人员学习和改进的机会。然后是组织检查和适应的能力，它允许不被困在一个阶段，从而不能充分发挥DevOps甚至敏捷性的潜力。

在我的下一篇文章中，我将更多地讨论每个阶段的技术和技术方面，旅途愉快!