華為周宇：基於Pipeline的DevOps核心實踐

時間即效率，如今軟體及網際網路產品的開發迭代流程及開發時間在不斷地優化，企業掌握研發環節上的時間效率主動權，就佔據了市場的先機。中小企業常常面臨產品釋出、交付等生產節奏難以把控的問題，如何解決？除了反省和梳理自身工作流程，也需藉助外部開發工具來優化。

以下來自企業開發者常遇到的開發經歷：

做為一名程式員，我們會時常聽到“別的公司”每週釋出，甚至一天多次釋出。交付速度快、上線頻率高，質量還特好。

可是輪到自己，現實卻是殘酷的。實施敏捷前，半年升次級一次還好點，現在敏捷了，每週五晚上１２點開始升級，２點全員開測，４點前修復問題，修復不了必須於５點前回滾，週末補覺或者繼續改問題。要是中間再來個緊急ｂｕｇ修復，上線一次補丁包就更慘了。每週如此，整個團隊累慘了，兄弟們女朋友都要跑光，坑爹的破敏捷、ＤｅｖＯｐｓ。

自己搭一條流水線，ｊｉｒａ、Ｔｒｅｌｌｏ、ｗｉｋｉ、ｇｉｔｌａｂ、ｓｏｎａｒ、ｆｉｎｄｂｕｇｓ、ｍａｖｅｎ、Ｊｅｎｋｉｎｓ、ｎｅｘｕｓ、ｊｆｒｏｇ、ａｎｓｉｂｌｅ、ｐｕｐｐｅｔ…，各種開源工具扒拉對比選型，花費大量時間人力好不容易搭起來，剛開始還可以滿足，但隨著團隊規模和產品規模的增長，經常出問題導致工作阻塞，整個開發團隊炸鍋，搭好的流水線不敢輕易升級或變更。內部需求響應越來越不及時、各方指責接踵而來，真是鴨梨山大。關鍵自己還不在業務主航道上，年底考評發現個人績效傷不起啊傷不起……

更恐怖的是，這些故事每天都在發生。

畢竟，我們手工拷包部署，幾次下來總會出現拷錯包、部錯機器的情況。手工測試，總有遺漏一些核心基線用例的時候。更不要說效能、可靠性測試每次手工執行的枯燥和易錯。而且所有活動，無論流程設計如何完美，工具如何完備，如果不能夠將人工操作（除了必要的Ｒｅｖｉｅｗ和釋出稽核）降到最低，各個工具編排、觸發、排程運轉，無論是效率還是質量均會受到較大影響。

一個團隊的自動化程度越低，如果採用ＤｅｖＯｐｓ開發模式，交付速度越快，則團隊出錯的機率越大、疲憊度越高、出錯機率也越大。

以上，便是企業開發過程常常面臨的窘境。

面對這些撲面而來的問題，光有好的ＤｅｖＯｐｓ理念、方法論、技術、流程是絕對不行的，還得要有好的工具——即持續交付流水線，來承載、固化、視覺化這些方法和理念。就像福特、豐田的偉大離不開創建出當時世界上最好的生產流水線一樣，軟體開發當然也離不開良好的持續交付流水線。

作為ＤｅｖＯｐｓ的核心工程實踐，持續交付驅動著研發、測試與運維的正常流轉，其中Ｐｉｐｅｌｉｎｅ流水線又是核心中的核心：

＆ｂｕｌｌ；理念：ＤｅｖＯｐｓ實現持續交付的理念和方法論

＆ｂｕｌｌ；流程：價值快速流動的持續交付流程

＆ｂｕｌｌ；技術：快速持續交付所需的基本技術準備，如微服務化架構解耦、特性分支、提交程式碼自動觸發、安全掃描、分鐘級構建、自動部署、自動化測試、質量門禁、灰度釋出等

＆ｂｕｌｌ；實踐：處於不同行業、成熟度階段的企業，選擇的不同方法和技術實踐的組合

＆ｂｕｌｌ；工具：Ｐｉｐｅｌｉｎｅ流水線拉通排程的持續交付工具鏈

＆ｂｕｌｌ；組織與文化：實施ＤｅｖＯｐｓ需要的團隊文化理念轉變，以及組織變革

如上圖所示，所有的理念、方法論、流程、技術、實踐、文化，最終都需要通過工具平臺進行固化、視覺化下來，使得價值流可見、交付可複製（重複執行），確保交付結果可預測，這樣才能夠確保在ＤｅｖＯｐｓ實踐下，更快速迭代的同時，保持更高質量。

程式設計師朋友們，你的日常交付中，是否也正在面臨這些困擾：通宵熬夜加班升級賺的熊貓眼、交付速度越快越手忙腳亂越出錯、自己搭建的交付流水線久久不敢升級？

如果有，請來參加２０１８華為全聯接大會，聽 一堂精彩的《基於Ｐｉｐｅｌｉｎｅ的ＤｅｖＯｐｓ核心實踐》演講，與華為雲ＤｅｖＣｌｏｕｄ專案創始人及首席體驗官交流如何通過Ｐｉｐｅｌｉｎｅ實踐，更好的去解決這些問題。