企業(yè)Devops數(shù)字化轉(zhuǎn)型建設(shè)

1、 Page * MERGEFORMAT 18企業(yè)Devops數(shù)字化轉(zhuǎn)型建設(shè)目 錄 TOC o 1-3 h z u HYPERLINK l _Toc44531096 一、概論 PAGEREF _Toc44531096 h 3 HYPERLINK l _Toc44531097 1、數(shù)字化轉(zhuǎn)型 PAGEREF _Toc44531097 h 3 HYPERLINK l _Toc44531098 2、開發(fā)運營一體化 PAGEREF _Toc44531098 h 4 HYPERLINK l _Toc44531099 3、開發(fā)運營一體化和數(shù)字化轉(zhuǎn)型的實例 PAGEREF _Toc44531099 h 5 H

2、YPERLINK l _Toc44531100 二、開發(fā)運營一體化能力建設(shè) PAGEREF _Toc44531100 h 5 HYPERLINK l _Toc44531101 1、技術(shù)能力 PAGEREF _Toc44531101 h 6 HYPERLINK l _Toc44531102 2、主干開發(fā)模式 PAGEREF _Toc44531102 h 7 HYPERLINK l _Toc44531103 3、測試驅(qū)動開發(fā) PAGEREF _Toc44531103 h 9 HYPERLINK l _Toc44531104 4、自動化測試 PAGEREF _Toc44531104 h 11 HYP

3、ERLINK l _Toc44531105 5、測試數(shù)據(jù)管理自動化 PAGEREF _Toc44531105 h 15 HYPERLINK l _Toc44531106 三、術(shù)語字典 PAGEREF _Toc44531106 h 16 HYPERLINK l _Toc44531107 四、參考文檔 PAGEREF _Toc44531107 h 17概論數(shù)字化轉(zhuǎn)型(digital transformation)乃至云化已經(jīng)從互聯(lián)網(wǎng)行業(yè)，滲透到了各個傳統(tǒng)行業(yè)，乃至于借助云計算，大數(shù)據(jù)隱隱然已經(jīng)成為了企業(yè)面向未來十年的必然選擇。在哈佛商業(yè)評論所作的一項針對企業(yè)業(yè)務高管的調(diào)查中顯示，企業(yè)普遍認為在20

4、19年中數(shù)字化轉(zhuǎn)型是企業(yè)的第一要務，但是超過70%的轉(zhuǎn)型并沒有達到企業(yè)的預期，并且超過9000億美金的投資被浪費掉了。這樣的浪費有很多原因，但不乏是由于傳統(tǒng)行業(yè)對于軟件開發(fā)、部署、發(fā)布、迭代以及運維的了解有限，因而本文面向傳統(tǒng)企業(yè)轉(zhuǎn)型中的困難和疑問，通過推進組織的DevOps轉(zhuǎn)型作為抓手來嘗試提供一份數(shù)字化轉(zhuǎn)型指南，以資參考。1、數(shù)字化轉(zhuǎn)型數(shù)字化轉(zhuǎn)型是使用云計算、大數(shù)據(jù)，以及其他信息技術(shù)對企業(yè)的運營、組織架構(gòu)和商業(yè)模式進行改造的過程，以提高企業(yè)相應客戶需求的速度，增強企業(yè)與客戶的聯(lián)系。數(shù)字化轉(zhuǎn)型不僅僅是技術(shù)轉(zhuǎn)型，更需要從商業(yè)戰(zhàn)略、組織架構(gòu)、文化、客戶關(guān)系等多維角度來確定企業(yè)的轉(zhuǎn)型策略和目標。這

5、些維度和開發(fā)運營一體化(DevOps)變革和敏捷運動有眾多重疊的領(lǐng)域。因而，我們可以使用DevOps作為抓手，在確定商業(yè)目標的同時，減少數(shù)字化轉(zhuǎn)型中的成本，通過DevOps的成熟度指標，來關(guān)聯(lián)和量化數(shù)字化轉(zhuǎn)型的成果。缺乏量化性的指標，就無法管理數(shù)字化轉(zhuǎn)型的過程，也是造成大量投資浪費的原因之一。2、開發(fā)運營一體化開發(fā)運營一體化(DevOps)是對于企業(yè)內(nèi)部開發(fā)和運營的整合的方法論、工具和指標。衡量一個組織的DevOps成熟度，需要從技術(shù)、流程、度量和文化四個維度來進行評價。根據(jù)當前主流業(yè)界的標準，DORA(DevOps Research and Assessment) DevOps成熟度模型、軟

6、件交付表現(xiàn)SDP(Software Delivery Performance)包含了下面這些指標，包括前置時間(Lead Time)、變更失敗(Change Fail)、可靠性(Availability)，以及部署頻率(Deployment Frequency)和恢復時間(Time to Restore)。3、開發(fā)運營一體化和數(shù)字化轉(zhuǎn)型的實例微軟公司，作為操作系統(tǒng)和辦公軟件的業(yè)界翹楚，也同樣面臨著數(shù)字化轉(zhuǎn)型的壓力。但是不同于其他企業(yè)，微軟有深厚的工程師文化，強大的IT技術(shù)儲備。他們面臨的問題是如何將基于授權(quán)(license)的商業(yè)模式轉(zhuǎn)型為以訂閱(subscribe)為基礎(chǔ)的訂閱服務上。例如傳

7、統(tǒng)的單機密鑰授權(quán)轉(zhuǎn)換為云化的office 365訂閱服務。在這期間，微軟著重推行了敏捷開發(fā)模式并且是office業(yè)務上云，同時將其傳統(tǒng)的基于私有數(shù)據(jù)中心的Team Foundation Server改造成為基于微軟云業(yè)務的Microsoft Azure DevOps。這成為了微軟內(nèi)部的運營開發(fā)一體化的轉(zhuǎn)型抓手和重要推動引擎。開發(fā)運營一體化能力建設(shè)依據(jù)DORA(DevOps Research and Accessment)超過六年對業(yè)界技術(shù)能力(Technical)、流程(Process)、度量(Measurement)和文化(Cultrue)四個維度的連續(xù)研究和評估，我們同樣可以從這四方面進行

8、建設(shè)。1、技術(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）可復制性(Reproducibility)可復制性是保障我們的開發(fā)、測試，以及生產(chǎn)環(huán)境的可復制性。能夠快速通過自動化的手段實現(xiàn)環(huán)境的復制和重建，進而保證環(huán)境的一致性。2）可追蹤性(Traceab

9、ility)可追蹤性的目的是為了保證團隊可以在任何時間都可以利用版本重建環(huán)境，并且可以比較兩套環(huán)境的區(qū)別。2、主干開發(fā)模式業(yè)界有兩種常見的軟件開發(fā)模式，即功能分支模式(Feature Branch Based Development)和主干開發(fā)模式(Trunk-based Developoment)。1）功能分支模式功能分支模式是指開發(fā)人員從主干分支(Master分支)拉取代碼來開始開發(fā)，直到開發(fā)人員認為代碼開發(fā)結(jié)束，即從不可部署階段到可部署階段。如上圖所示，即從淺灰色變?yōu)樯罨疑艑⒋a重新合并到主分支。這種模式有兩個主要問題。第一，每一次發(fā)布都伴隨著大量的代碼合并，并且會引起代碼沖突。原因

10、是每次分支合并的代碼量過大；第二，需要手工維護代碼的合并，因為代碼不僅僅是合并到主干，還需要人工判斷是否需要合并到其他功能分支上。一般的邏輯是如果另一個功能分支的發(fā)布時間晚于當前要合并的分支，并且后面的發(fā)布需要當前分支的功能或問題修復，即需要合并，即所謂的向后合并。向后合并可以采用自動化合并的模式來實現(xiàn)，例如可以依賴于Jenkins來實現(xiàn)自動向后合并。由于每次合并代碼都需要完整的測試，所以需要代碼鎖定(Code Freeze)，以確保代碼的穩(wěn)定性。2）主干開發(fā)模式不同于功能分支模式，主干開發(fā)模式是實現(xiàn)持續(xù)集成的必要條件。開發(fā)人員只有在代碼準備發(fā)布的時候，才會拉出發(fā)布分支，所以發(fā)布分支一直是可部

11、署的狀態(tài)。而在功能分支模式下，功能分支不一定是可部署狀態(tài)。開發(fā)人員每天都會把當下代碼簽入主干，但是要求開發(fā)人員如果自己簽入的新代碼引起了任何問題，必須立即修復，否則會阻塞其他開發(fā)人員簽入代碼。因為每次簽入的代碼量比較少，所以出現(xiàn)代碼沖突的可能性就會大幅度降低。同時，主干代碼因為繼承了回歸測試的自動化，任何破壞回歸功能的代碼都會被立刻修復，也維護了代碼質(zhì)量。主干開發(fā)模式不需要鎖定代碼或者其他手段來保證代碼穩(wěn)定性。實現(xiàn)主干開發(fā)模式的要點：分支數(shù)目控制在3個或以下；至少每天一次代碼合并；不要采用代碼鎖定(Code Freeze)和集成階段；確保在代碼合并之前進行代碼復查(Code Review)和代

12、碼掃描(Code Scanning), 推薦使用PR(Pull Request)代碼掃描。3、測試驅(qū)動開發(fā)開發(fā)人員經(jīng)常誤認為開發(fā)運營一體化(DevOps)就是討論開發(fā)和運維，即Development和Operation，其實這是一個望文生義的一種誤解。在推進DevOps轉(zhuǎn)型中，很多企業(yè)和團隊經(jīng)常忽略了自動化測試這一個關(guān)鍵的因素。沒有完善的測試驅(qū)動開發(fā)流程，沒有完善的回歸測試自動化，持續(xù)集成就是空談。上圖是測試驅(qū)動開發(fā)TDD的流程示意。新的功能在拿到需求之后，測試人員和開發(fā)人員都需要被通知。所有的開發(fā)都是基于對測試用例的實現(xiàn)。首先增加新的測試用例，并且運行自動化測試。此時，由于代碼還沒有開發(fā)，測

13、試一定會失敗。這么做的原因是讓開發(fā)和測試人員明確在代碼開發(fā)之前新增加的測試用例是失敗的，從而避免測試用例的錯誤而造成測試用例錯誤通過的問題。開發(fā)人員根據(jù)測試來進行功能開發(fā)，直到所有測試用例通過。當測試用例通過之后，開發(fā)人員進行代碼的重構(gòu)來進行代碼優(yōu)化，以實現(xiàn)安全性和性能的要求。在簽入代碼到主干的時候，如果發(fā)現(xiàn)自動化回歸測試失敗，測試人員需要更新自動化回歸測試確?；貧w測試是最新狀態(tài)。實現(xiàn)TDD的要點：代碼簽入都會觸發(fā)自動化構(gòu)建；代碼簽入會觸發(fā)一系列自動化測試；確保每天的構(gòu)建和自動化測試必須是成功狀態(tài)；如果出現(xiàn)構(gòu)建和測試失敗，開發(fā)人員必須立即修復。4、自動化測試自動化測試給開發(fā)人員提供了一種快速反

14、饋的機制。自動化測試是保證持續(xù)集成的基礎(chǔ)條件。自動化測試包括下面兩種測試種類：1）單元測試(Unit Test)單元測試是TDD流程中經(jīng)常使用的針對單個函數(shù)、類或者方法，來保證開發(fā)人員的代碼按照預期的測試方法。單元測試的開發(fā)早于業(yè)務代碼，流程在上一節(jié)介紹TDD的內(nèi)容中已經(jīng)提及。2）驗收測試(Acceptance Tests)驗收測試是針對程序或這API進行功能上的測試，本身也是開發(fā)工作的一部分。開發(fā)人員在沒有通過驗收測試之前是不能夠認為開發(fā)工作已經(jīng)完成。上圖從四個角度分析了自動化測試的使用。從業(yè)務角度來看，驗收測試和手工探索性測試都是針對業(yè)務功能進行的，來保證業(yè)務流的順利進行。一般手工測試在代

15、碼上生產(chǎn)環(huán)境之前進行，有些團隊稱之為PVT(Product Validation Testing)，即產(chǎn)品驗證測試，對應的測試人員一般都是業(yè)務專家。從開發(fā)支持的角度來看，單元測試和自動化驗收測試是實現(xiàn)CICD和TDD的關(guān)鍵。以上為一個完整的CICD從開發(fā)到發(fā)布的流程。在commit stage中，經(jīng)常會進行代碼掃描和單元測試。如果單元測試或者代碼掃描未通過，開發(fā)人員可以獲得快速反饋，并根據(jù)需要重新修改代碼。這個地方可以實現(xiàn)問題的左移, 即代碼風格問題左移和安全性左移。在自動化驗收測試時，如果測試未通過，有兩種可能性。第一是業(yè)務代碼有問題，第二為驗收測試代碼需要調(diào)整。這個反饋應該發(fā)送給對應的測試

16、團隊和開發(fā)團隊。3）自動化測試金字塔(Automation Testing Pyramid)根據(jù)自動化測試金字塔模型，盡可能多的問題應該被自動化單元測試發(fā)現(xiàn)，這樣可以降低測試成本，開發(fā)人員可以盡早獲得反饋以修改代碼。驗收測試的作者和維護者，應該盡可能是開發(fā)人員，這一點經(jīng)常被很多企業(yè)和團隊所忽略。5、測試數(shù)據(jù)管理自動化測試數(shù)據(jù)管理是很多團隊和企業(yè)在做DevOps轉(zhuǎn)型中容易忽略的領(lǐng)域。測試數(shù)據(jù)是保證測試能夠正常進行的基礎(chǔ)。沒有良好的測試數(shù)據(jù)管理，會提告測試缺陷的誤報率，降低團隊的信息，忽略真正的嚴重產(chǎn)品缺陷。測試數(shù)據(jù)管理必須要保證自動化測試能夠順利進行。針對不同的環(huán)境，例如測試環(huán)境、預生產(chǎn)環(huán)境、測

17、試數(shù)據(jù)必須能夠區(qū)別管理，因為不同環(huán)境的測試數(shù)據(jù)有可能會有不同。測試數(shù)據(jù)管理應該能夠自動的在環(huán)境設(shè)置完成之后，配置測試環(huán)境，以便開展自動化測試。在測試完成之后，能夠自動清理數(shù)據(jù)，并且恢復環(huán)境至測試開始之前。測試數(shù)據(jù)管理必須要能夠根據(jù)代碼開發(fā)更新，確保數(shù)據(jù)的實時性。本文主要從技術(shù)的角度探討DevOps如何助力企業(yè)數(shù)字化轉(zhuǎn)型，后續(xù)將陸續(xù)推出包括DevOps流程、指標、文化和組織角度的解讀，敬請持續(xù)關(guān)注。術(shù)語字典數(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ā)模式和流程。參考文檔哈佛商業(yè)評論 - 數(shù)字化轉(zhuǎn)型并不僅僅是技術(shù)/2019/03/digital-transformation-is-not-about-technologyState of DevOps Report by pupp