作者介紹
趙輝，前HSBC商業銀行DevOps團隊主管，DevOps專家，現任一線公有云企業DevOps平臺解決方案架構師。
術語字典
數字化轉型：Digital Transformation (DT)；
開發運維一體化：DevOps；
雲計算：Cloud Computing，常見的公有云有Amazon Cloud Service(AWS)、Microsoft Azure Cloud、Google Cloud Platform(GCP)、阿里雲(Alibaba Cloud)、騰訊雲(Tencent Cloud)， 以及華為雲(Huawei Cloud)；
測試驅動開發：Test-driven Development, 是一種開發面向測試用例的軟件開發模式和流程。
概論
數字化轉型(digital transformation)乃至雲化已經從互聯網行業，滲透到了各個傳統行業，乃至於藉助雲計算，大數據隱隱然已經成為了企業面向未來十年的必然選擇。
在哈佛商業評論所作的一項針對企業業務高管的調查中顯示，企業普遍認為在2019年中數字化轉型是企業的第一要務，但是超過70%的轉型並沒有達到企業的預期，並且超過9000億美金的投資被浪費掉了。
這樣的浪費有很多原因，但不乏是由於傳統行業對於軟件開發、部署、發佈、迭代以及運維的瞭解有限，因而本文面向傳統企業轉型中的困難和疑問，通過推進組織的DevOps轉型作為抓手來嘗試提供一份數字化轉型指南，以資參考。
1、數字化轉型
數字化轉型是使用雲計算、大數據，以及其他信息技術對企業的運營、組織架構和商業模式進行改造的過程，以提高企業相應客戶需求的速度，增強企業與客戶的聯繫。數字化轉型不僅僅是技術轉型，更需要從商業戰略、組織架構、文化、客戶關係等多維角度來確定企業的轉型策略和目標。
這些維度和開發運營一體化(DevOps)變革和敏捷運動有眾多重疊的領域。因而，我們可以使用DevOps作為抓手，在確定商業目標的同時，減少數字化轉型中的成本，通過DevOps的成熟度指標，來關聯和量化數字化轉型的成果。
缺乏量化性的指標，就無法管理數字化轉型的過程，也是造成大量投資浪費的原因之一。2、開發運營一體化
開發運營一體化(DevOps)是對於企業內部開發和運營的整合的方法論、工具和指標。衡量一個組織的DevOps成熟度，需要從技術、流程、度量和文化四個維度來進行評價。根據當前主流業界的標準，DORA(DevOps Research and Assessment) DevOps成熟度模型、軟件交付表現SDP(Software Delivery Performance)包含了下面這些指標，包括前置時間(Lead Time)、變更失敗(Change Fail)、可靠性(Availability)，以及部署頻率(Deployment Frequency)和恢復時間(Time to Restore)。
3、開發運營一體化和數字化轉型的實例
微軟公司，作為操作系統和辦公軟件的業界翹楚，也同樣面臨著數字化轉型的壓力。但是不同於其他企業，微軟有深厚的工程師文化，強大的IT技術儲備。他們面臨的問題是如何將基於授權(license)的商業模式轉型為以訂閱(subscribe)為基礎的訂閱服務上。例如傳統的單機密鑰授權轉換為雲化的office 365訂閱服務。
在這期間，微軟著重推行了敏捷開發模式並且是office業務上雲，同時將其傳統的基於私有數據中心的Team Foundation Server改造成為基於微軟雲業務的Microsoft Azure DevOps。這成為了微軟內部的運營開發一體化的轉型抓手和重要推動引擎。
開發運營一體化能力建設
依據DORA(DevOps Research and Accessment)超過六年對業界技術能力(Technical)、流程(Process)、度量(Measurement)和文化(Cultrue)四個維度的連續研究和評估，我們同樣可以從這四方面進行建設。
1、技術能力
版本控制跟自動化緊密相關。事實上，建設持續集成和持續交付能力的建立在成熟的版本控制流程和工具的基礎之上。很多企業在建立版本控制的時候，更多關注的是代碼，而忽略了代碼之外的配套流程和製品，例如測試用例、自動化測試腳本、測試數據、基礎設施和數據庫。我們在建立版本控制的時候，需要實現
基礎設施即代碼、配置即代碼、數據即代碼，以及測試即代碼。版本控制可以幫助企業滿足以下兩個最關鍵的需求，即：1）可複製性(Reproducibility)
可複製性是保障我們的開發、測試，以及生產環境的可複製性。能夠快速通過自動化的手段實現環境的複製和重建，進而保證環境的一致性。
2）可追蹤性(Traceability)
可追蹤性的目的是為了保證團隊可以在任何時間都可以利用版本重建環境，並且可以比較兩套環境的區別。
2、主幹開發模式
業界有兩種常見的軟件開發模式，即功能分支模式(Feature Branch Based Development)和主幹開發模式(Trunk-based Developoment)。
1）功能分支模式
功能分支模式是指開發人員從主幹分支(Master分支)拉取代碼來開始開發，直到開發人員認為代碼開發結束，即從不可部署階段到可部署階段。如上圖所示，即從淺灰色變為深灰色，才將代碼重新合併到主分支。
這種模式有兩個主要問題。第一，每一次發佈都伴隨著大量的代碼合併，並且會引起代碼衝突。原因是每次分支合併的代碼量過大；第二，需要手工維護代碼的合併，因為代碼不僅僅是合併到主幹，還需要人工判斷是否需要合併到其他功能分支上。一般的邏輯是如果另一個功能分支的發佈時間晚於當前要合併的分支，並且後面的發佈需要當前分支的功能或問題修復，即需要合併，即所謂的向後合併。向後合併可以採用自動化合並的模式來實現，例如可以依賴於Jenkins來實現自動向後合併。由於每次合併代碼都需要完整的測試，所以需要代碼鎖定(Code Freeze)，以確保代碼的穩定性。
2）主幹開發模式
不同於功能分支模式，主幹開發模式是實現持續集成的必要條件。開發人員只有在代碼準備發佈的時候，才會拉出發佈分支，所以發佈分支一直是可部署的狀態 。而在功能分支模式下，功能分支不一定是可部署狀態。開發人員每天都會把當下代碼簽入主幹，但是要求開發人員如果自己簽入的新代碼引起了任何問題，必須立即修復，否則會阻塞其他開發人員簽入代碼。因為每次簽入的代碼量比較少，所以出現代碼衝突的可能性就會大幅度降低。同時，主幹代碼因為繼承了迴歸測試的自動化，任何破壞迴歸功能的代碼都會被立刻修復，也維護了代碼質量。主幹開發模式不需要鎖定代碼或者其他手段來保證代碼穩定性。
實現主幹開發模式的要點：
分支數目控制在3個或以下；
至少每天一次代碼合併；
不要採用代碼鎖定(Code Freeze)和集成階段；
確保在代碼合併之前進行代碼複查(Code Review)和代碼掃描(Code Scanning), 推薦使用PR(Pull Request)代碼掃描。
3、測試驅動開發
開發人員經常誤認為開發運營一體化(DevOps)就是討論開發和運維，即Development和Operation，其實這是一個望文生義的一種誤解。在推進DevOps轉型中，很多企業和團隊經常忽略了自動化測試這一個關鍵的因素。沒有完善的測試驅動開發流程，沒有完善的迴歸測試自動化，持續集成就是空談。
上圖是測試驅動開發TDD的流程示意。新的功能在拿到需求之後，測試人員和開發人員都需要被通知。所有的開發都是基於對測試用例的實現。首先增加新的測試用例，並且運行自動化測試。此時，由於代碼還沒有開發，測試一定會失敗。這麼做的原因是讓開發和測試人員明確在代碼開發之前新增加的測試用例是失敗的，從而避免測試用例的錯誤而造成測試用例錯誤通過的問題。開發人員根據測試來進行功能開發，直到所有測試用例通過。當測試用例通過之後，開發人員進行代碼的重構來進行代碼優化，以實現安全性和性能的要求。在簽入代碼到主幹的時候，如果發現自動化迴歸測試失敗，測試人員需要更新自動化迴歸測試確保迴歸測試是最新狀態。
實現TDD的要點：
代碼簽入都會觸發自動化構建；
代碼簽入會觸發一系列自動化測試；
確保每天的構建和自動化測試必須是成功狀態；
如果出現構建和測試失敗，開發人員必須立即修復。
4、自動化測試
自動化測試給開發人員提供了一種快速反饋的機制。自動化測試是保證持續集成的基礎條件。自動化測試包括下面兩種測試種類：
1）單元測試(Unit Test)
單元測試是TDD流程中經常使用的針對單個函數、類或者方法，來保證開發人員的代碼按照預期的測試方法。單元測試的開發早於業務代碼，流程在上一節介紹TDD的內容中已經提及。
2）驗收測試(Acceptance Tests)
驗收測試是針對程序或這API進行功能上的測試，本身也是開發工作的一部分。開發人員在沒有通過驗收測試之前是不能夠認為開發工作已經完成。
上圖從四個角度分析了自動化測試的使用。
從業務角度來看，驗收測試和手工探索性測試都是針對業務功能進行的，來保證業務流的順利進行。一般手工測試在代碼上生產環境之前進行，有些團隊稱之為PVT(Product Validation Testing)，即產品驗證測試，對應的測試人員一般都是業務專家。
從開發支持的角度來看，單元測試和自動化驗收測試是實現CICD和TDD的關鍵。
以上為一個完整的CICD從開發到發佈的流程。在commit stage中，經常會進行代碼掃描和單元測試。如果單元測試或者代碼掃描未通過，開發人員可以獲得快速反饋，並根據需要重新修改代碼。這個地方可以實現問題的左移, 即代碼風格問題左移和安全性左移。
在自動化驗收測試時，如果測試未通過，有兩種可能性。第一是業務代碼有問題，第二為驗收測試代碼需要調整。這個反饋應該發送給對應的測試團隊和開發團隊。
3）自動化測試金字塔(Automation Testing Pyramid)
根據自動化測試金字塔模型，儘可能多的問題應該被自動化單元測試發現，這樣可以降低測試成本，開發人員可以儘早獲得反饋以修改代碼。驗收測試的作者和維護者，應該儘可能是開發人員，這一點經常被很多企業和團隊所忽略。
5、測試數據管理自動化
測試數據管理是很多團隊和企業在做DevOps轉型中容易忽略的領域。測試數據是保證測試能夠正常進行的基礎。沒有良好的測試數據管理，會提告測試缺陷的誤報率，降低團隊的信息，忽略真正的嚴重產品缺陷。
測試數據管理必須要保證自動化測試能夠順利進行。針對不同的環境，例如測試環境、預生產環境、測試數據必須能夠區別管理，因為不同環境的測試數據有可能會有不同。
測試數據管理應該能夠自動的在環境設置完成之後，配置測試環境，以便開展自動化測試。在測試完成之後，能夠自動清理數據，並且恢復環境至測試開始之前。
測試數據管理必須要能夠根據代碼開發更新，確保數據的實時性。
本文主要從技術的角度探討DevOps如何助力企業數字化轉型，後續將陸續推出包括DevOps流程、指標、文化和組織角度的解讀，敬請持續關注。
>>>>
參考文檔
《哈佛商業評論 - 數字化轉型並不僅僅是技術》
https://hbr.org/2019/03/digital-transformation-is-not-about-technology
《State of DevOps Report by puppet》
https://www.thinkahead.com/wp-content/uploads/2018/10/State-of-DevOps-Report.pdf
《Five Foundational DevOps Practices by Splunk》
https://www.splunk.com/pdfs/ebooks/5-foundational-devops-practices.pdf
《Google DevOps Research》
https://cloud.google.com/devops
《DORA State 2018》
https://cloudplatformonline.com/rs/248-TPC-286/images/DORA-State%20of%20DevOps.pdf
《測試驅動開發(TDD)》
https://en.wikipedia.org/wiki/Test-driven_development
隨著數字化轉型與雲化從互聯網行業滲透到了各個傳統行業，運維迎來了新的契機，想破解運維轉型困局，讓Gdevops全球敏捷運維峰會北京站給你新思路：
《建設敏捷型消費金融中臺及雲原生下的DevOps實踐》中郵消費金融總經理助理 李遠鑫
《銀行日誌監控系統優化手記》中國銀行DevOps負責人 付大亮和中國銀行 高級軟件工程師 李曉寧
《民生銀行智能運維平臺實踐之路》民生銀行智能運維平臺負責人/應用運維專家 張舒偉
《浙江移動AIOps實踐》浙江移動雲計算中心NOC及AIOps負責人 潘宇虹
《數據智能時代：構建能力開放的運營商大數據DataOps體系》中國聯通大數據基礎平臺負責人/資深架構師 尹正軍
讓我們在新技術的衝擊下站穩腳跟，攀登運維高峰！那麼2020年9月11日，我們在北京不見不散。
