[[322272]]

作者介紹

趙輝，前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

本文轉載自微信公眾號「DBAplus社群」，可以通過以下二維碼關注。轉載本文請聯系DBAplus社群公眾號。