趙輝

DBAplus社群（dbaplus)

讀完需要

20

分鐘

速讀僅需 5 分鐘

?

圖片來源：Pixabay,?CC0

作者介紹

趙輝，前HSBC商業(yè)銀行DevOps團(tuán)隊(duì)主管，DevOps專家，現(xiàn)任一線公有云企業(yè)DevOps平臺(tái)解決方案架構(gòu)師。

術(shù)語字典

• 數(shù)字化轉(zhuǎn)型：Digital Transformation (DT)；

• 開發(fā)運(yùn)維一體化：DevOps；

• 云計(jì)算：Cloud Computing，常見的公有云有Amazon Cloud Service(AWS)、Microsoft Azure Cloud、Google Cloud Platform(GCP)、阿里云(Alibaba Cloud)、騰訊云(Tencent Cloud)， 以及華為云(Huawei Cloud)；

• 測(cè)試驅(qū)動(dòng)開發(fā)：Test-driven Development, 是一種開發(fā)面向測(cè)試用例的軟件開發(fā)模式和流程。

概論

這樣的浪費(fèi)有很多原因，但不乏是由于傳統(tǒng)行業(yè)對(duì)于軟件開發(fā)、部署、發(fā)布、迭代以及運(yùn)維的了解有限，因而本文面向傳統(tǒng)企業(yè)轉(zhuǎn)型中的困難和疑問，通過推進(jìn)組織的DevOps轉(zhuǎn)型作為抓手來嘗試提供一份數(shù)字化轉(zhuǎn)型指南，以資參考。

1、數(shù)字化轉(zhuǎn)型

數(shù)字化轉(zhuǎn)型是使用云計(jì)算、大數(shù)據(jù)，以及其他信息技術(shù)對(duì)企業(yè)的運(yùn)營(yíng)、組織架構(gòu)和商業(yè)模式進(jìn)行改造的過程，以提高企業(yè)相應(yīng)客戶需求的速度，增強(qiáng)企業(yè)與客戶的聯(lián)系。數(shù)字化轉(zhuǎn)型不僅僅是技術(shù)轉(zhuǎn)型，更需要從商業(yè)戰(zhàn)略、組織架構(gòu)、文化、客戶關(guān)系等多維角度來確定企業(yè)的轉(zhuǎn)型策略和目標(biāo)。

這些維度和開發(fā)運(yùn)營(yíng)一體化(DevOps)變革和敏捷運(yùn)動(dòng)有眾多重疊的領(lǐng)域。因而，我們可以使用DevOps作為抓手，在確定商業(yè)目標(biāo)的同時(shí)，減少數(shù)字化轉(zhuǎn)型中的成本，通過DevOps的成熟度指標(biāo)，來關(guān)聯(lián)和量化數(shù)字化轉(zhuǎn)型的成果。缺乏量化性的指標(biāo)，就無法管理數(shù)字化轉(zhuǎn)型的過程，也是造成大量投資浪費(fèi)的原因之一。

2、開發(fā)運(yùn)營(yíng)一體化

開發(fā)運(yùn)營(yíng)一體化(DevOps)是對(duì)于企業(yè)內(nèi)部開發(fā)和運(yùn)營(yíng)的整合的方法論、工具和指標(biāo)。衡量一個(gè)組織的DevOps成熟度，需要從技術(shù)、流程、度量和文化四個(gè)維度來進(jìn)行評(píng)價(jià)。根據(jù)當(dāng)前主流業(yè)界的標(biāo)準(zhǔn)，DORA(DevOps Research and Assessment) DevOps成熟度模型、軟件交付表現(xiàn)SDP(Software Delivery Performance)包含了下面這些指標(biāo)，包括前置時(shí)間(Lead Time)、變更失敗(Change Fail)、可靠性(Availability)，以及部署頻率(Deployment Frequency)和恢復(fù)時(shí)間(Time to Restore)。

3、開發(fā)運(yùn)營(yíng)一體化和數(shù)字化轉(zhuǎn)型的實(shí)例

微軟公司，作為操作系統(tǒng)和辦公軟件的業(yè)界翹楚，也同樣面臨著數(shù)字化轉(zhuǎn)型的壓力。但是不同于其他企業(yè)，微軟有深厚的工程師文化，強(qiáng)大的IT技術(shù)儲(chǔ)備。他們面臨的問題是如何將基于授權(quán)(license)的商業(yè)模式轉(zhuǎn)型為以訂閱(subscribe)為基礎(chǔ)的訂閱服務(wù)上。例如傳統(tǒng)的單機(jī)密鑰授權(quán)轉(zhuǎn)換為云化的office 365訂閱服務(wù)。

在這期間，微軟著重推行了敏捷開發(fā)模式并且是office業(yè)務(wù)上云，同時(shí)將其傳統(tǒng)的基于私有數(shù)據(jù)中心的Team Foundation Server改造成為基于微軟云業(yè)務(wù)的Microsoft Azure DevOps。這成為了微軟內(nèi)部的運(yùn)營(yíng)開發(fā)一體化的轉(zhuǎn)型抓手和重要推動(dòng)引擎。

開發(fā)運(yùn)營(yíng)一體化能力建設(shè)

依據(jù)DORA(DevOps Research and Accessment)超過六年對(duì)業(yè)界技術(shù)能力(Technical)、流程(Process)、度量(Measurement)和文化(Cultrue)四個(gè)維度的連續(xù)研究和評(píng)估，我們同樣可以從這四方面進(jìn)行建設(shè)。

1、技術(shù)能力

版本控制跟自動(dòng)化緊密相關(guān)。事實(shí)上，建設(shè)持續(xù)集成和持續(xù)交付能力的建立在成熟的版本控制流程和工具的基礎(chǔ)之上。很多企業(yè)在建立版本控制的時(shí)候，更多關(guān)注的是代碼，而忽略了代碼之外的配套流程和制品，例如測(cè)試用例、自動(dòng)化測(cè)試腳本、測(cè)試數(shù)據(jù)、基礎(chǔ)設(shè)施和數(shù)據(jù)庫。我們?cè)诮姹究刂频臅r(shí)候，需要實(shí)現(xiàn)基礎(chǔ)設(shè)施即代碼、配置即代碼、數(shù)據(jù)即代碼，以及測(cè)試即代碼。版本控制可以幫助企業(yè)滿足以下兩個(gè)最關(guān)鍵的需求，即：

1）可復(fù)制性(Reproducibility)

可復(fù)制性是保障我們的開發(fā)、測(cè)試，以及生產(chǎn)環(huán)境的可復(fù)制性。能夠快速通過自動(dòng)化的手段實(shí)現(xiàn)環(huán)境的復(fù)制和重建，進(jìn)而保證環(huán)境的一致性。

2）可追蹤性(Traceability)

可追蹤性的目的是為了保證團(tuán)隊(duì)可以在任何時(shí)間都可以利用版本重建環(huán)境，并且可以比較兩套環(huán)境的區(qū)別。

2、主干開發(fā)模式

業(yè)界有兩種常見的軟件開發(fā)模式，即功能分支模式(Feature Branch Based Development)和主干開發(fā)模式(Trunk-based Developoment)。

1）功能分支模式

功能分支模式是指開發(fā)人員從主干分支(Master分支)拉取代碼來開始開發(fā)，直到開發(fā)人員認(rèn)為代碼開發(fā)結(jié)束，即從不可部署階段到可部署階段。如上圖所示，即從淺灰色變?yōu)樯罨疑?#xff0c;才將代碼重新合并到主分支。

這種模式有兩個(gè)主要問題。第一，每一次發(fā)布都伴隨著大量的代碼合并，并且會(huì)引起代碼沖突。原因是每次分支合并的代碼量過大；第二，需要手工維護(hù)代碼的合并，因?yàn)榇a不僅僅是合并到主干，還需要人工判斷是否需要合并到其他功能分支上。一般的邏輯是如果另一個(gè)功能分支的發(fā)布時(shí)間晚于當(dāng)前要合并的分支，并且后面的發(fā)布需要當(dāng)前分支的功能或問題修復(fù)，即需要合并，即所謂的向后合并。向后合并可以采用自動(dòng)化合并的模式來實(shí)現(xiàn)，例如可以依賴于Jenkins來實(shí)現(xiàn)自動(dòng)向后合并。由于每次合并代碼都需要完整的測(cè)試，所以需要代碼鎖定(Code Freeze)，以確保代碼的穩(wěn)定性。

2）主干開發(fā)模式

不同于功能分支模式，主干開發(fā)模式是實(shí)現(xiàn)持續(xù)集成的必要條件。開發(fā)人員只有在代碼準(zhǔn)備發(fā)布的時(shí)候，才會(huì)拉出發(fā)布分支，所以發(fā)布分支一直是可部署的狀態(tài)。而在功能分支模式下，功能分支不一定是可部署狀態(tài)。開發(fā)人員每天都會(huì)把當(dāng)下代碼簽入主干，但是要求開發(fā)人員如果自己簽入的新代碼引起了任何問題，必須立即修復(fù)，否則會(huì)阻塞其他開發(fā)人員簽入代碼。因?yàn)槊看魏炄氲拇a量比較少，所以出現(xiàn)代碼沖突的可能性就會(huì)大幅度降低。同時(shí)，主干代碼因?yàn)槔^承了回歸測(cè)試的自動(dòng)化，任何破壞回歸功能的代碼都會(huì)被立刻修復(fù)，也維護(hù)了代碼質(zhì)量。主干開發(fā)模式不需要鎖定代碼或者其他手段來保證代碼穩(wěn)定性。

實(shí)現(xiàn)主干開發(fā)模式的要點(diǎn)：

• 分支數(shù)目控制在3個(gè)或以下；

• 至少每天一次代碼合并；

• 不要采用代碼鎖定(Code Freeze)和集成階段；

• 確保在代碼合并之前進(jìn)行代碼復(fù)查(Code Review)和代碼掃描(Code Scanning), 推薦使用PR(Pull Request)代碼掃描。

3、測(cè)試驅(qū)動(dòng)開發(fā)

開發(fā)人員經(jīng)常誤認(rèn)為開發(fā)運(yùn)營(yíng)一體化(DevOps)就是討論開發(fā)和運(yùn)維，即Development和Operation，其實(shí)這是一個(gè)望文生義的一種誤解。在推進(jìn)DevOps轉(zhuǎn)型中，很多企業(yè)和團(tuán)隊(duì)經(jīng)常忽略了自動(dòng)化測(cè)試這一個(gè)關(guān)鍵的因素。沒有完善的測(cè)試驅(qū)動(dòng)開發(fā)流程，沒有完善的回歸測(cè)試自動(dòng)化，持續(xù)集成就是空談。

上圖是測(cè)試驅(qū)動(dòng)開發(fā)TDD的流程示意。新的功能在拿到需求之后，測(cè)試人員和開發(fā)人員都需要被通知。所有的開發(fā)都是基于對(duì)測(cè)試用例的實(shí)現(xiàn)。首先增加新的測(cè)試用例，并且運(yùn)行自動(dòng)化測(cè)試。此時(shí)，由于代碼還沒有開發(fā)，測(cè)試一定會(huì)失敗。這么做的原因是讓開發(fā)和測(cè)試人員明確在代碼開發(fā)之前新增加的測(cè)試用例是失敗的，從而避免測(cè)試用例的錯(cuò)誤而造成測(cè)試用例錯(cuò)誤通過的問題。開發(fā)人員根據(jù)測(cè)試來進(jìn)行功能開發(fā)，直到所有測(cè)試用例通過。當(dāng)測(cè)試用例通過之后，開發(fā)人員進(jìn)行代碼的重構(gòu)來進(jìn)行代碼優(yōu)化，以實(shí)現(xiàn)安全性和性能的要求。在簽入代碼到主干的時(shí)候，如果發(fā)現(xiàn)自動(dòng)化回歸測(cè)試失敗，測(cè)試人員需要更新自動(dòng)化回歸測(cè)試確保回歸測(cè)試是最新狀態(tài)。

實(shí)現(xiàn)TDD的要點(diǎn)：

• 代碼簽入都會(huì)觸發(fā)自動(dòng)化構(gòu)建；

• 代碼簽入會(huì)觸發(fā)一系列自動(dòng)化測(cè)試；

• 確保每天的構(gòu)建和自動(dòng)化測(cè)試必須是成功狀態(tài)；

• 如果出現(xiàn)構(gòu)建和測(cè)試失敗，開發(fā)人員必須立即修復(fù)。

4、自動(dòng)化測(cè)試

自動(dòng)化測(cè)試給開發(fā)人員提供了一種快速反饋的機(jī)制。自動(dòng)化測(cè)試是保證持續(xù)集成的基礎(chǔ)條件。自動(dòng)化測(cè)試包括下面兩種測(cè)試種類：

1）單元測(cè)試(Unit Test)

單元測(cè)試是TDD流程中經(jīng)常使用的針對(duì)單個(gè)函數(shù)、類或者方法，來保證開發(fā)人員的代碼按照預(yù)期的測(cè)試方法。單元測(cè)試的開發(fā)早于業(yè)務(wù)代碼，流程在上一節(jié)介紹TDD的內(nèi)容中已經(jīng)提及。?

2）驗(yàn)收測(cè)試(Acceptance Tests)

驗(yàn)收測(cè)試是針對(duì)程序或這API進(jìn)行功能上的測(cè)試，本身也是開發(fā)工作的一部分。開發(fā)人員在沒有通過驗(yàn)收測(cè)試之前是不能夠認(rèn)為開發(fā)工作已經(jīng)完成。

上圖從四個(gè)角度分析了自動(dòng)化測(cè)試的使用。

從業(yè)務(wù)角度來看，驗(yàn)收測(cè)試和手工探索性測(cè)試都是針對(duì)業(yè)務(wù)功能進(jìn)行的，來保證業(yè)務(wù)流的順利進(jìn)行。一般手工測(cè)試在代碼上生產(chǎn)環(huán)境之前進(jìn)行，有些團(tuán)隊(duì)稱之為PVT(Product Validation Testing)，即產(chǎn)品驗(yàn)證測(cè)試，對(duì)應(yīng)的測(cè)試人員一般都是業(yè)務(wù)專家。

從開發(fā)支持的角度來看，單元測(cè)試和自動(dòng)化驗(yàn)收測(cè)試是實(shí)現(xiàn)CICD和TDD的關(guān)鍵。

以上為一個(gè)完整的CICD從開發(fā)到發(fā)布的流程。在commit stage中，經(jīng)常會(huì)進(jìn)行代碼掃描和單元測(cè)試。如果單元測(cè)試或者代碼掃描未通過，開發(fā)人員可以獲得快速反饋，并根據(jù)需要重新修改代碼。這個(gè)地方可以實(shí)現(xiàn)問題的左移, 即代碼風(fēng)格問題左移和安全性左移。

在自動(dòng)化驗(yàn)收測(cè)試時(shí)，如果測(cè)試未通過，有兩種可能性。第一是業(yè)務(wù)代碼有問題，第二為驗(yàn)收測(cè)試代碼需要調(diào)整。這個(gè)反饋應(yīng)該發(fā)送給對(duì)應(yīng)的測(cè)試團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)。

3）自動(dòng)化測(cè)試金字塔(Automation Testing Pyramid)

根據(jù)自動(dòng)化測(cè)試金字塔模型，盡可能多的問題應(yīng)該被自動(dòng)化單元測(cè)試發(fā)現(xiàn)，這樣可以降低測(cè)試成本，開發(fā)人員可以盡早獲得反饋以修改代碼。驗(yàn)收測(cè)試的作者和維護(hù)者，應(yīng)該盡可能是開發(fā)人員，這一點(diǎn)經(jīng)常被很多企業(yè)和團(tuán)隊(duì)所忽略。

5、測(cè)試數(shù)據(jù)管理自動(dòng)化

測(cè)試數(shù)據(jù)管理是很多團(tuán)隊(duì)和企業(yè)在做DevOps轉(zhuǎn)型中容易忽略的領(lǐng)域。測(cè)試數(shù)據(jù)是保證測(cè)試能夠正常進(jìn)行的基礎(chǔ)。沒有良好的測(cè)試數(shù)據(jù)管理，會(huì)提告測(cè)試缺陷的誤報(bào)率，降低團(tuán)隊(duì)的信息，忽略真正的嚴(yán)重產(chǎn)品缺陷。

測(cè)試數(shù)據(jù)管理必須要保證自動(dòng)化測(cè)試能夠順利進(jìn)行。針對(duì)不同的環(huán)境，例如測(cè)試環(huán)境、預(yù)生產(chǎn)環(huán)境、測(cè)試數(shù)據(jù)必須能夠區(qū)別管理，因?yàn)椴煌h(huán)境的測(cè)試數(shù)據(jù)有可能會(huì)有不同。

測(cè)試數(shù)據(jù)管理應(yīng)該能夠自動(dòng)的在環(huán)境設(shè)置完成之后，配置測(cè)試環(huán)境，以便開展自動(dòng)化測(cè)試。在測(cè)試完成之后，能夠自動(dòng)清理數(shù)據(jù)，并且恢復(fù)環(huán)境至測(cè)試開始之前。

測(cè)試數(shù)據(jù)管理必須要能夠根據(jù)代碼開發(fā)更新，確保數(shù)據(jù)的實(shí)時(shí)性。

本文主要從技術(shù)的角度探討DevOps如何助力企業(yè)數(shù)字化轉(zhuǎn)型，后續(xù)將陸續(xù)推出包括DevOps流程、指標(biāo)、文化和組織角度的解讀，敬請(qǐng)持續(xù)關(guān)注。

>>>>

參考文檔

• 《哈佛商業(yè)評(píng)論 - 數(shù)字化轉(zhuǎn)型并不僅僅是技術(shù)》

  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

• 《測(cè)試驅(qū)動(dòng)開發(fā)(TDD)》

  https://en.wikipedia.org/wiki/Test-driven_development

---

推薦閱讀

?

CTO 技術(shù)管理的“三板斧”

?

架構(gòu)師這5條禁忌，你犯了么？

?

“宇宙第一大行”之 MySQL 數(shù)據(jù)庫架構(gòu)解密

?

阿里高工流生 | 云原生時(shí)代的 DevOps 之道

? ?END ? ?? #接力技術(shù)，鏈接價(jià)值#

總結(jié)

以上是生活随笔為你收集整理的浪费超9000亿美金，数字化转型失败罪魁祸首在DevOps？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。