六步教你玩转DevOps上华为云DevCloud实践

引言：在“DevOps能力之屋（Capabilities House of DevOps）”中，华为云DevCloud提出（工程方法+最佳实践+生态）×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列，针对DevOps领域场景，阐述该场景在华为云DevCloud上的实施方法与实践。本文阐述了企业A在实施DevOps过程中，如何一步步采用华为云DevOps平台。此客户成功故事，希望为采用DevOps平台的企业提供借鉴。为行文阅读，本文中企业A将以第一人称（“我”或者“我们”）来进行阐述。本文与莫妮卡协同完成。

目前，在产品团队的不断努力下，从第一次接触华为云DevCloud开始，现在我们终于拥有了优雅、全面的一站式DevOps解决方案，团队成员不必再费心劳力地使用和维护多种工具及版本。然而回首过去，我们的DevOps持续交付流水线，就像大多数公司和开源项目一样，有很多混杂的产品、服务和脚本，都松松散散勉强一起使用。同时来自不同公司的不同DevOps工具并不总是能够很好地兼容，情况越发复杂。简而言之，我们有很多工作要做，但最终，我们决定要统一工具的行为和目标。

采用华为云DevCloud，我们经历了6个关键阶段。我们希望这会给通往DevOps涅槃路上的企业提供帮助。

第一步：找到你的痛点

也许，对于大多数的企业，包括我们自己，DevOps转型的最大动力往往来自于“火烧屁股”，主动转型多数时候是奢谈。正如微软Donovan Brown在谈论到DevOps时经常说：“找到最伤人的东西，围绕它去做很多很多的事儿，使它越来越好，直到它不再伤人。”这也成为我们的座右铭。

如果你打算采用DevOps，并且正在考虑使用DevCloud，那么首先审视一下自己：在我们的DevOps流水线中，最痛苦的事情是什么？没有足够的单元测试？部署新版本太多手工操作导致容易出错？即使你已经到达了DevOps的顶峰，即使你的发布是可以一键部署，你仍然可能在生产中中断某件事情。然而，你会发现你没有合适的工具来告诉你错在哪里；也许是某些事情遇到了瓶颈，或者只是没有按预期的方式工作。因此，让我们找出这些痛点并从那里开始。   

第二步：源代码版本控制

 “代码”作为软件研发的核心产物，因而源代码版本控制是DevOps的基石。在DevOps异地协同上，集中式的SVN远不如分布式Git，因此，很多公司（包括我们自己）将代码从SVN迁移到Git上。这样，你可以使用华为云DevCloud的代码托管服务。华为云DevCloud也提供了迁移指南通过工具或者脚本来帮助企业进行迁移，大大简化了相关工作。

当然，如果你采用Git，应该充分意识：No Pains，No Gains。对于新手来讲，Git需要一个巨大的学习曲线，合并、推送、拉取，变基等很多操作有一点儿复杂。这儿有一个很好的建议，当你开始使用Git时，可以像对待以前的版本管理系统一样对待它，如果你把你所知道的相关知识转义一下应用到Git上，你就可以摆脱初始学习的困境了。对于其他复杂的操作，随着时间的推移，你将开始适应它，水到渠成地学会使用那些强大的功能。

现在整个行业最近都在迅速采用Git，但愿你不会迟到。Git有一个真正具有变革意义的杀手级功能——轻量级分支。Git创建分支的本质只是只是创建一个指针。当然选用哪种分支模型（GitFlow、Gitlab Flow、GitHub Flow或者自定义flow），产品团队需要考虑团队生产力和个人生产力之间的平衡。建议从成熟的flow模型开始。

第三步：任务管理

任务管理是产品团队除了源代码版本控制外必须做好另一个基础工作。我们一直在使用业界某主流敏捷项目管理工具T。我们非常喜欢它的简单，在看板的工作跟踪时，只有“未完成”、“进行中”、“已完成”等3个状态。但是随着研发需求的增加，简单的状态跟踪无法满足我的需求。此外，我在拿到客户需求的初期，希望对产品做一个需求规划，让团队可以按照发布或迭代进行需求拆解。

DevCloud的项目管理服务解决了这些痛点，例如思维导图可视化按层级进行需求规划、标准的Scrum方法、可以自定义工作项状态。当然这意味着你失去了简单明了的方式。

图1 在Scrum板视图中查看工作项状态

    归根结底，你可以选择你钟爱的工具，例如至为简洁的敏捷项目管理工具T，它可以工作得很好，但是你将丢失可追溯性。而华为云DevCloud可以帮你在DevOps方面做得更多，例如需求工作项与代码提交的关联，需求工作项与测试用例和缺陷的关联等。

第四步：拥抱CI/CD

在使用华为云DevCloud前，我们使用的是某主流工具C。它实际上是一个非常好的持续集成产品，它提供On Premises与SaaS版本。

使用DevCloud编译构建服务的一个好处是构建启动的速度变得飞快。对于工具C，每当我们需要一个新的构建时，就会提供一个VM，这可能需要5到10分钟。这个前置时间太久，变得很烦人。而华为云DevCloud拥有了一个热的、随时可以在云中构建的机器池，所以只要有人提交一个新的提交，构建就会立即发生。

    以前，我们的部署过程是手动的，我们需要运行一堆批处理脚本。而使用DevCloud流水线是一种乐趣，它不仅仅可以支持一键全自动部署，将变更投入生产，而且提供了完美的可视化编排，可以将构建、部署、自动化测试等纳管起来，并根据实际需要定制多级流水线，加入质量门禁、人工审核等控制。

第五步：Bug跟踪

在此之前，我们使用Excel对Bug进行跟踪，随着团队人数的增加，分清Excel版本已经足够让我们头疼了。使用了DevCloud之后，简直给我们的工作带来了不可思议的改变。

首先，Bug跟踪在早例会的直观展示。当我们开早会时，将Scrum缺陷跟踪板投屏，可以通过过滤筛选每个成员手中的Bug状态和等级，便于识别风险。

其次，Bug跟踪与需求、测试的关联。DevCloud中基于需求创建测试用例，测试用例失败生产Bug，实现了需求-测试用例-缺陷双向关联。

最后，多维度的Bug统计。在DevCloud统计报表中，预置了多种Bug统计报表，用户也可以根据自己的需要自定义统计报表。

                 图2 在DevCloud预置的缺陷统计模板

第六步：定制DevCloud适应项目需求

不要陷入DevCloud希望你工作的方式中。如果有众多不同的状态，比如批准、已提交、已解决、已验证，请不要盲目屈从于产品对敏捷或Scrum的定义或者那些对你不起作用的东西。先问问自己什么是可能起作用的最简单的事情，然后在DevCloud上开展工作。最为重要的是，不要因为DevCloud产品经理想的太多而强迫自己过度思考，无所适从。

自定义相对比较简单，因为DevCloud提供了工作项字段、模板、状态流转等的可定制性。你可以用它来增加东西，但你也可以用它来减轻东西。所以，把对你没有意义的东西拿走，只保持最低限度。你只需把它作为一个工具来了解你的团队在做什么，并传达优先事项，保持它的简洁与实用。

采用华为云DevCloud最重要的是，它作为一个全面的解决方案所带来的聚集效应。你可以选择只使用其中的部分服务，然而如果你选择使用尽可能多的服务，你将发现令人震惊的积极变化。当然，这并非没有困难，一蹴而就。DevOps转型面临不同层面的变革，从改变企业文化，到整个组织的新的工具平台的投资，到团队成员的知识与技能水平。但请相信，这确实是一个短期痛苦、长期收益的改变！

全面的解决方案无疑会是一个赢家。一旦我们采用了一体化工具平台，向我们的客户交付软件就变得更容易、更自动化，甚至是一个很好的体验。无论如何，采用华为云DevCloud会失去什么呢？我相信无论只使用部分服务，还是全部服务，它只会给你带来更多的业务效益，以及高效的交付体验。