【摘要】 在“DevOps能力之屋（Capabilities House of DevOps）”中，華為雲DevCloud提出（工程方法 最佳實踐 生态）×工具平台=DevOps能力。本文闡述了企業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方面做得更多，例如需求工作項與代碼提交的關聯，需求工作項與測試用例和缺陷的關聯等。

在使用華為雲DevCloud前，我們使用的是某主流工具C。它實際上是一個非常好的持續集成産品，它提供On Premises與SaaS版本。

使用DevCloud編譯構建服務的一個好處是構建啟動的速度變得飛快。對于工具C，每當我們需要一個新的構建時，就會提供一個VM，這可能需要5到10分鐘。這個前置時間太久，變得很煩人。而華為雲DevCloud擁有了一個熱的、随時可以在雲中構建的機器池，所以隻要有人提交一個新的提交，構建就會立即發生。

以前，我們的部署過程是手動的，我們需要運行一堆批處理腳本。而使用DevCloud流水線是一種樂趣，它不僅僅可以支持一鍵全自動部署，将變更投入生産，而且提供了完美的可視化編排，可以将構建、部署、自動化測試等納管起來，并根據實際需要定制多級流水線，加入質量門禁、人工審核等控制。

在此之前，我們使用Excel對Bug進行跟蹤，随着團隊人數的增加，分清Excel版本已經足夠讓我們頭疼了。使用了DevCloud之後，簡直給我們的工作帶來了不可思議的改變。

首先，Bug跟蹤在早例會的直觀展示。當我們開早會時，将Scrum缺陷跟蹤闆投屏，可以通過過濾篩選每個成員手中的Bug狀态和等級，便于識别風險。

其次，Bug跟蹤與需求、測試的關聯。DevCloud中基于需求創建測試用例，測試用例失敗生産Bug，實現了需求-測試用例-缺陷雙向關聯。

最後，多維度的Bug統計。在DevCloud統計報表中，預置了多種Bug統計報表，用戶也可以根據自己的需要自定義統計報表。

圖2 在DevCloud預置的缺陷統計模闆

不要陷入DevCloud希望你工作的方式中。如果有衆多不同的狀态，比如批準、已提交、已解決、已驗證，請不要盲目屈從于産品對敏捷或Scrum的定義或者那些對你不起作用的東西。先問問自己什麼是可能起作用的最簡單的事情，然後在DevCloud上開展工作。最為重要的是，不要因為DevCloud産品經理想的太多而強迫自己過度思考，無所适從。

自定義相對比較簡單，因為DevCloud提供了工作項字段、模闆、狀态流轉等的可定制性。你可以用它來增加東西，但你也可以用它來減輕東西。所以，把對你沒有意義的東西拿走，隻保持最低限度。你隻需把它作為一個工具來了解你的團隊在做什麼，并傳達優先事項，保持它的簡潔與實用。

采用華為雲DevCloud最重要的是，它作為一個全面的解決方案所帶來的聚集效應。你可以選擇隻使用其中的部分服務，然而如果你選擇使用盡可能多的服務，你将發現令人震驚的積極變化。當然，這并非沒有困難，一蹴而就。DevOps轉型面臨不同層面的變革，從改變企業文化，到整個組織的新的工具平台的投資，到團隊成員的知識與技能水平。但請相信，這确實是一個短期痛苦、長期收益的改變！

全面的解決方案無疑會是一個赢家。一旦我們采用了一體化工具平台，向我們的客戶交付軟件就變得更容易、更自動化，甚至是一個很好的體驗。無論如何，采用華為雲DevCloud會失去什麼呢？我相信無論隻使用部分服務，還是全部服務，它隻會給你帶來更多的業務效益，以及高效的交付體驗。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!