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