導讀
時至今日，屬於純網際網路行業的時代已經步入尾聲，伴隨移動網際網路誕生的增長紅利和國內人口紅利也已基本結束。曾經各行各業都沉浸在因市場快速增長帶來的移動網際網路使用者的激增中，那時企業即使發展方式粗糙一些、成本高一些都可以忽略不計。但現在情況正在改變，大眾創業、萬眾創新的風口已經過去，同時在中美貿易戰和國家去槓桿的大趨勢下，傳統行業更是處於內憂外患中，這時企業的研發管理效率和成本問題開始逐步凸現，必須修煉內功進入精耕細作的時代。
CODING CEO 張海龍認為在這樣的背景下，所有的企業都需要轉型。現在已經有如 DevOps 這樣高效的研發管理方式，以及更好的版本控制流程；同時很多新興網際網路公司在這方面的轉型動作很快，如果企業還墨守成規，使用之前瀑布流的管理方式，未來差距會變得越來越大。
作為一種已經被接納和理解的一組文化價值和實踐的集合，DevOps 已經被證明能夠幫助各種規模的企業改善研發管理流程，加快版本的迭代和釋出以及保障研發質量和安全，同時能為產品的開發提供快速、有效的反饋。從 Puppet 過去六年收到的總計 27000 份 DevOps 調查反饋中，有足夠的證據證明 DevOps 實踐推動了研發管理的升級，帶來了更高的效能，從而改善了生產性、利潤和市場份額(1)。
今天帶來的案例是 Gary Gruver, HP LaserJet 印表機韌體研發總監在他的 A Practical Approach To Large-Scale Agile Development 一書中講述的整個韌體研發團隊的 DevOps 轉型過程。分享這個案例不僅僅是因為整個研發團隊在成功轉型之後獲得了 2~3 倍的效率提升，同時還因為該研發團隊的定位是為 HP LaserJet 全產品線提供韌體研發，而不是常見的 App 或者網站的研發團隊。
這個案例向我們展示了 DevOps 不是專屬於像 Google、Amazon、Netflix 等網際網路巨頭的工具，它可以為所有需要研發、測試、運維緊密相連的企業提高效率，更好地實現企業目標。再者像 HP LaserJet 印表機的韌體研發團隊這樣的大象都可以轉身，相信你也可以為自己的企業進行轉型。
Enjoy！
發現問題 (韌體研發變成了業務的瓶頸）
Gary 的研發團隊主要負責編寫在 HP LaserJet 全系列產品(印表機、影印機、掃描器等等）上執行的韌體程式碼。在當時，消費級印表機市場已經完全是紅海市場，巨頭林立，幾乎每月都有新功能或者新產品上市。
儘管 Gary 的韌體研發團隊在全球已經有超過 600 名工程師的規模，維護著超過 10,000,000 行程式碼，但是整個團隊在嘗試實現這些新功能時還是面臨著巨大的挑戰。
憑藉當時的條件，整個韌體研發團隊每年只能完成 2 次版本迭代，大量的時間都用在將開發出來的程式碼移植到新的印表機產品上。 Gary 估計最多隻有 5% 的研發時間是用在開發或者維護新的具有創意性的功能上。
這就導致 Gary 的韌體研發團隊成為了整個 LaserJet 事業部的瓶頸，按照他們當時的研發管理模式，幾乎不可能為 LaserJet 的韌體新增新功能去適應市場競爭。
"市場部的同事每隔一段時間就會帶著很多有創意的想法來找我們，並跟我們強調對於客戶來說這些功能有多重要。但是我們只能告訴他們，在你們的列表裡挑兩個功能吧，大概 6~12 個月後就能實現了。"
久而久之，市場部基本放棄向韌體團隊提新的功能需求，這對於處於競爭日益白熱化的印表機市場的 HP 來說無疑是嚴重的打擊。更有甚者，當年的研發成本增長了將近 2.5 倍，而 80%~90% 的資源其實是投入在新產品的韌體移植和修繕中。
交付週期變成了大問題
Gary 在書中提到了一些關於交付週期的資料，這些情況在我們熟悉的軟體研發專案中應該也很常見：
- 只有 5% 的研發時間花在新功能的研發上
- 15 ~ 20% 的研發時間主要花在將程式碼合併到主幹
- 當時共有八個組，每個組都配有組長負責每天提交程式碼
- 當一個組長提交程式碼之後需要 1 周的時間才能確定是否成功合併到主幹中
- 之後需要等一天才能到 "整合階段"，之後還需要再花一天時間去跑相容性測試
- 最後需要進行 6 周的手動整合測試
也就是說，每個工程師都需要等待 8 周以上的時間才能知道程式碼執行結果！
落後的反饋機制
"如果我們的反饋機制能夠更高效及時一些，研發效率就能提高很多。當時的研發流程經常被 8 周之前提交的程式碼問題困住，而且要花很久的時間去定位問題究竟出在哪兒。"
在這樣的反饋機制下，也不利於工程師自我學習和總結如何預防未來相同的問題不再發生。唯一會發生的情況就是工程師會因為一個 8 周前犯的錯誤而受到管理層的指責，再花大量的時間去定位問題和修復 Bug。
這是一個很重要的問題，如果工程師們不能獲得及時高效的反饋，就會導致他們需要花大量時間去修改很久以前提交的程式碼，這將非常影響研發效率。
引入持續整合和架構變革
架構變革
在之前的研發管理模式中，每一款不同的 LaserJet 產品都需要創立一個獨立的程式碼分支，用 C 語言中的 #ifdef's 預編譯指令來開啟或者禁用不同產品型別上的特定功能（如紙張大小等）。
這種模式會引發很多問題，比如隨著產品線的不斷增加，越來越多的獨立程式碼分支需要被實時維護，同時每次維護又會產生相對獨立的韌體版本，這些韌體版本又雙叒叕需要獨立的測試，大量的資源會浪費在這些重複勞動中。
所以第一個目標就是用 Trunk 搭建了一個能讓所有工程師在統一的程式碼倉庫中進行工作的平臺，通過 Trunk 的架構來消除各個獨立程式碼分支，將印表機功能判斷從之前通過編譯時的 C 語言中#ifdef's 預編譯指令改成在執行時用 XML 配置檔案進行判斷。
現在，HP LaserJet 的 Trunk 架構已經支援超過 24 款印表機產品。
"建立 Trunk ，對程式碼進行統一，不再對各個產品的程式碼分散管理，這將為企業帶來極大的效率提升。" --- Gary 評價架構變革的效果，"下一步，我們需要自動化測試，如果沒有自動測試的環節，那持續整合只會快速產生大量無效結果。"
自動測試
為了開發自動測試，整個研發團隊搭建了一系列自動化元件，包括程式碼審查和程式碼整合測試，這些自動化流程會在後臺不間斷地對主幹程式碼進行測試。
印表機的韌體測試是一件很具有挑戰性的工作，最可靠的測試方法肯定是在實體印表機上進行實際的列印操作，但問題是整個韌體研發團隊在新的架構下每天需要超過 150000 小時的測試量。
"整個地球上沒有足夠多的樹來支援我們進行這樣量級的實機測試。"
因為測試環境越接近實機測試環境，測試成本就會相應提高，所以當時研發的主要目標是希望通過儘可能多的線上測試，以模擬器的形式來降低成本。為了保證測試同事儘快獲得結果反饋，Gary 的團隊花了整整 6 周時間搭建測試環境的基礎架構以支援測試：4 組伺服器，在印度還有 2 組伺服器，每組伺服器包括 500 臺伺服器，每臺伺服器上執行著 4 個虛擬機器。總共 240000 個虛擬印表機不間斷地執行新的韌體並反饋執行結果。
通過自動化測試環境的搭建，整個韌體研發團隊實現了高效反饋機制，現在工程師提交程式碼後可以很快地獲得提交結果，整個迴歸測試的時間只需要 24 小時。
程式碼稽核
在成功引入持續整合和自動化測試後，另外一個問題浮現了出來——整個研發團隊需要適應新的習慣。當不時有工程師提交的程式碼導致整個 Trunk 或者測試環境崩潰，大家必須全部停下手上的工作，開始檢視哪裡有問題，修復 Bug。甚至有一次崩潰時間整整持續了 5 天，導致所有成員都無法提交新的程式碼，為整個團隊造成巨大了的困擾。後來發現原來是在給測試環境升級的時候不小心提高了某項測試的門檻，導致所有的測試結果都得到負反饋。
Gary 的對策是引入程式碼稽核環節，保證只有正確、高質量的程式碼能夠通過稽核併合併到主幹中，確保受到程式碼質量影響的人數降到最低，並最大幅地提升研發效率。
DevOps 轉型結果
Gary 的團隊轉型成果如下：
- 每天 75000 ~ 100000 行程式碼修改
- 每天 100 - 150 次程式碼提交
"在過去的研發管理模式下，我們不可能每天修改 100000 行程式碼，帶有持續整合和持續交付的 DevOps 敏捷開發模式讓研發管理變得更加靈活。"
更重要的是，Gary 的韌體研發團隊取得了下面這項進步:
- 在新功能的研發時間上從之前的 5% 提高到了 40%! (8 倍的增長）
在現在這個時代，軟體對每個公司都變得越發地重要；通過 DevOps 實踐，更好地協調工具，自動化以及持續學習也變得越來越重要。即使像 HP LaserJet 事業部中的韌體研發團隊這樣大型的、分散式的、相對保守的團隊都可進行 DevOps 的轉型，有理由認為所有的組織，不管他們的使命是什麼，通過實踐 DevOps 都能更高效的完成目標。
Reference
- Puppet Labs 2017 State of DevOps Report
- A Practical Approach To Large-Scale Agile Development
- http://www.slideshare.net/gbgruver/spark-2013-presentation-of-making-the-enterprise-agile