引言：

在“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會失去什麼呢？我相信無論只使用部分服務，還是全部服務，它只會給你帶來更多的業務效益，以及高效的交付體驗。

點選關注，第一時間瞭解華為雲新鮮技