如今，大多数公司都在进行DevOps转型，以采用更快的发布，提供更好的质量，提高团队的灵活性，敏捷性并获得更快的反馈。VMware的移动产品也不例外。我们两年前就怀着同样的目标开始了转型。这篇文章将列出我们转型中遇到的障碍，以及使我们前进的解决方案。
从两年前就着眼于DevOps目标开始，我们就有了一些可用的初始要素。我们有敏捷的流程，运营团队，自动化工具和可用的技术，但是这些都不是一个引擎。因此，我们开始进行更改。
拒绝改变
改变的不确定性，恐惧和怀疑是人的天性，这创造了拒绝的环境。最困难的任务之一是说服团队实施新的变革，并推动文化转变。
为了解决这个问题，我们从不断的培训，并要求团队慢慢进行这些变更。此过程帮助团队了解了DevOps采用的价值。此外，我们很幸运获得管理团队的支持。没有他们的支持和配合，我们的DevOps变革将是不可能的。
功能交付
我们经历的另一项是功能交付。团队承受着不断的压力，要求他们用很少的时间交付新功能。他们专注于交付工作代码，但不对质量负责。质量是一个单独的质量工程（QE）团队的责任。开发人员日夜工作，提供超出团队能力的代码，但是QE仍然发现很多缺陷。
在进行团队流程调整以采用更改的同时，我们不想发生重大变化来破坏可为客户提供价值的新功能。
那么，我们有什么选择呢？第一步，我们将团队的工作速度降低到其正常工作能力的50％，以确保他们有足够的时间专注于更高质量的工作。其次，我们为团队提供了重新制定和更改“完成”定义的时间，我们开始专注于根本原因分析，并专注于自动化以避免类似的问题和减少将来的问题。
技术债务
技术债务是软件开发的组成部分。大多数拥有遗留代码的团队都有某种技术上的债务，我们也是如此。我们的大多数移动产品都有一定的技术债务。
由于我们将速度降低到以前的能力的50％，因此我们有一定的喘息空间来承担较小的技术债务，这是在团队给定速度下进行计划的一部分。对于所有团队来说，决定将开发速度降低一半是一个艰难的决定。我们与产品管理团队紧密合作，优先处理技术债务和工程改进以及新功能，以确保我们的产品长期成功。
团队结构
当我们开始DevOps转型之旅时，QE团队独立于开发人员运作。质量工程师负责测试产品。但是，这种安排在DevOps结构中不太适合。
管理层意识到了这个问题，改变了团队结构。质量团队与开发团队合并。每个人都专注于提供高质量的产品，而质量是团队中每个人的责任。QE与开发人员结对，向相同的经理汇报工作，并在设计和开发开始时就致力于质量。我们创建了DevOps风格的团队。DevOps团队是功能齐全的团队，能够构建，测试，具有基础架构和管理服务技能。如果您是像VMware这样的大型组织，则无需为每个团队创建最基本的技能，而可以继续拥有一个平台团队来满足关键项目和跨多个项目的共同需求。但是，请确保使每个团队都能自行管理应用程序和服务。
技能和知识
当管理层更改团队结构以使每个人对产品质量负责时，说起来容易做起来难。技能和产品知识方面存在差距。例如，开发人员不知道如何创建测试用例。QE团队不了解产品代码对代码开发的贡献。
为了解决这个问题，我们开始提高团队技能和交叉技能。在代码开发和开发人员方面进行QE培训，以考虑质量，测试计划，测试策略以及整体采用质量思维方式。这样做的目的不是让QE开始开发代码，也不是让开发人员开始全职测试，而是要获得所需的技能以更加熟悉产品和代码。此外，我们希望拥有编程方面的专业知识，以开始构建其团队所需的工具和系统。知识共享，结对编程，跨团队技能开发简化了转换的过程。
自动化
DevOps涉及整个SDLC生命周期中的早期反馈，而自动化在提供早期和一致的反馈中扮演着非常重要的角色。没有自动化，就无法实现DevOps的发展。当我们开始时，就已经有了自动化，但是，自动化没有得到有效利用。由于对自动化脚本缺乏信任，测试结果被忽略了，并且开发人员没有为自动化编写任何测试脚本（少数单元测试除外）。
我们做了什么？我们回顾了我们的自动化测试策略。为了向左移动，我们选择了与开发人员所使用的接近的工具和技术，以便他们可以使用自己喜欢的语言，IDE和工具编写测试脚本。这在很大程度上帮助了我们，开发人员逐渐能够开始编写测试脚本，质量工程师开始修复产品缺陷。它还为我们提供了测试自动化的稳定性。我们测试框架的更好的设计和架构使每个团队成员都能够为实现质量目标做出贡献。
环境
自动化的瓶颈之一是按需测试环境的可用性，因为Workspace ONE是一个非常复杂的产品，并且具有许多相互依存关系。对于每个团队来说，要在每次测试运行中按需创建这样的环境并不容易。
这是我们的基础架构团队介入的地方，并开始从事一个项目，以便为每个团队提供按需测试环境。整个解决方案基于自助服务门户和REST API。我们所有人很容易采用和使用API与自动化集成并创建测试环境。
跨团队协作
如上所述，Workspace ONE是一款非常复杂的产品，具有数百个相互依赖关系，并分为数百个模块。团队经常在孤岛上工作，专注于自己的交付物，而没有考虑共享最佳实践或创建可重用的代码。这不是一个容易解决的问题，需要文化上的转变。
解决方案是什么？我们组成了一个小团队，开始团队之间的协调，调整发布周期，在团队之间重用代码并改善代码文档。示例之一是重新创建基于微服务体系结构的测试框架，以便每个团队可以共享自己的代码脚本以避免重复。成立了一个跨平台团队来分离和编写可在产品线中使用的可重用代码。
结论
通过应用上述解决方案，我们能够做出许多积极的改变。去年，当我们回顾并评估了移动SDK的结果时，我们发现iOS的发布速度提高了50％，Android的发布速度提高了25％。计划外的补丁和次要版本在iOS上降低了58％，在Android上降低了29％。我们减少了上报次数，提高了生产率，增加了团队之间的协作和质量，以及许多其他无形的收益。
不要害怕变化。正如*马丁·福勒（Martin Fowler）*所说
如果您害怕更改某些内容，则显然设计不佳。
通过适当的规划开始您的DevOps转型，确保管理在您身边，并且所有利益相关者都知道这是一段旅程而不是目的地。实施时请注意上述障碍，但请继续学习并保持继续学习。
