pselx2="568" data-cropsely1="0" data-cropsely2="62" data-ratio="0.6" data-w="800" style="width: 568px;height: 341px;" src="/images/21ic_nopic.gif" data-src="e854ATVXwgzQS8Dgq55MtUA6QW8py3i5OV+QTOX0chOavdts607l57yVtJEfahFhUyWpFQVFWB5tki8tdaHyBHJ4RPm5H01jFHKX" class="delay_img" alt="9000億投資浪費在數(shù)字化轉(zhuǎn)型，罪魁禍?zhǔn)自贒evOps？" >

來自：DBAplus社群

作者介紹

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

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

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

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

數(shù)字化轉(zhuǎn)型(digital transformation)乃至云化已經(jīng)從互聯(lián)網(wǎng)行業(yè)，滲透到了各個傳統(tǒng)行業(yè)，乃至于借助云計算，大數(shù)據(jù)隱隱然已經(jīng)成為了企業(yè)面向未來十年的必然選擇。 

在哈佛商業(yè)評論所作的一項針對企業(yè)業(yè)務(wù)高管的調(diào)查中顯示，企業(yè)普遍認(rèn)為在2019年中數(shù)字化轉(zhuǎn)型是企業(yè)的第一要務(wù)，但是超過70%的轉(zhuǎn)型并沒有達(dá)到企業(yè)的預(yù)期，并且超過9000億美金的投資被浪費掉了。

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

數(shù)字化轉(zhuǎn)型是使用云計算、大數(shù)據(jù)，以及其他信息技術(shù)對企業(yè)的運營、組織架構(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ā)運營一體化(DevOps)變革和敏捷運動有眾多重疊的領(lǐng)域。因而，我們可以使用DevOps作為抓手，在確定商業(yè)目標(biāo)的同時，減少數(shù)字化轉(zhuǎn)型中的成本，通過DevOps的成熟度指標(biāo)，來關(guān)聯(lián)和量化數(shù)字化轉(zhuǎn)型的成果。缺乏量化性的指標(biāo)，就無法管理數(shù)字化轉(zhuǎn)型的過程，也是造成大量投資浪費的原因之一。

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

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

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

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

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

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

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

2）可追蹤性(Traceability)

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

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

1）功能分支模式

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

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

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

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

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

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

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

實現(xiàn)TDD的要點：

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

1）單元測試(Unit Test)

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

2）驗收測試(Acceptance Tests)

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

上圖從四個角度分析了自動化測試的使用。

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

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

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

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

3）自動化測試金字塔(Automation Testing Pyramid)

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

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

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

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

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

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

• 《哈佛商業(yè)評論 - 數(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

• 《測試驅(qū)動開發(fā)(TDD)》

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