共计 3194 个字符，预计需要花费 8 分钟才能阅读完成。
引言：
在“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 会失去什么呢？我相信无论只使用部分服务，还是全部服务，它只会给你带来更多的业务效益，以及高效的交付体验。
点击关注，第一时间了解华为云新鲜技术~
