如何構(gòu)建高效可信的持續(xù)交付能力

如今，許多企業(yè)組織都在實施持續(xù)交付的做法。但想要提高持續(xù)交付的效率，很多時候會覺得是在構(gòu)建自動化測試和環(huán)境部署的時候出了問題，不過我們認為還有其他因素導(dǎo)致我們發(fā)布軟件版本時有些壓力和阻礙，只是不確定問題是什么。

我們開始觀察每一個軟件版本發(fā)布過程并記錄下看到的內(nèi)容。例如，完成流程的每個步驟所花費的時間，是人為手動還是自動化發(fā)布，參與項目協(xié)作的人數(shù)有多少，以及發(fā)現(xiàn)導(dǎo)致新版本延遲發(fā)布的問題。一旦我們有足夠的數(shù)據(jù)，我們就可以開始分析它并尋找解決方式，這些會成為我們要解決的最重要的問題。

在觀察時保持客觀是很重要的，不要讓自己的偏見掩蓋實際發(fā)生的事實，特別是在嘗試改進項目流程和系統(tǒng)時非常有價值。

為什么要專注于改善我們的發(fā)布流程

原因是顯而易見的，在軟件版本發(fā)布常常并不像我們預(yù)計的那樣順暢，既不能無阻礙又無法實現(xiàn)頻繁發(fā)布，從而影響了我們的交付能力。

在改進的過程中，能與技術(shù)專家共同合作能更快優(yōu)化發(fā)布流程。與專家合作的好處在于他們尊重數(shù)據(jù)和事實，并且也非常熱衷于讓事情變得更好。同時上文提到的收集了大量數(shù)據(jù)，就可以顯示出我們的問題，這意味著我們專注于解決實際問題而不是假設(shè)。例如，數(shù)據(jù)顯示我們在測試分段環(huán)境中部署的插件比我們想象的要少得多，因此我們就可以輕而易舉地處理這個阻止我們輕松部署的問題。

穩(wěn)定發(fā)布不代表所有東西都必須在現(xiàn)在發(fā)布

如果某些改進真的非常重要，那在最快的時間內(nèi)發(fā)布是不可置疑的。問題在于，當(dāng)我們想要選擇本周的候選版本時，由于各種原因，團隊認為需要包含最后一分鐘的“緊急”更改。這意味著推遲選擇發(fā)布候選版本以及對發(fā)布周期的連鎖效應(yīng)，或者工作必須加班加點，即便趕在最后發(fā)布了，有時也會影響版本質(zhì)量。

我們開始有這樣的疑問，“為什么它必須在這個版本中出去？”，“如果我們本周不發(fā)布更改會怎么樣？”或“它能等到下一個版本嗎？”。要獲取答案其實非常困難，因為對于團隊來說開發(fā)已經(jīng)是一個壓力很大的情況，這些疑問的提出會被視作阻止他們進行更改。但事實上，當(dāng)我們試圖頻繁地發(fā)布更改，更新迭代時，但其實是可以等待下一周時，它確實是違反了原則。因為我們會忘記了一點，軟件版本發(fā)布的關(guān)鍵是穩(wěn)定。

通過討論并提出這些問題，我們意識到有些變化根本不緊急，因此不需要趕工。這樣做的好處是我們的版本更加順暢，需要修復(fù)錯誤的程序更少了，顯然發(fā)布的壓力也減少了，然后我們可以更專注于如何進行周期性規(guī)律地發(fā)布。

使用數(shù)據(jù)來識別問題和改變習(xí)慣

改變習(xí)慣是很難，因為習(xí)慣是長期這樣做的結(jié)果，但你必須努力停止舊習(xí)慣并用新習(xí)慣取而代之。選擇合適的時機發(fā)布可以突出發(fā)現(xiàn)我們的發(fā)布周期中的問題，并有助于解決修復(fù)問題。

我們可以嘗試一些方法來幫助我們養(yǎng)成良好的習(xí)慣。例如，如果參與發(fā)布過程的人員將發(fā)送電子郵件作為主要通信方法的話，那一般會有數(shù)小時的延遲。必須了解到，在收件人閱讀并理解電子郵件之前，發(fā)件人其實還沒有傳達任何信息。如果收件人正在開會，或者每天只會定期檢查電子郵件，那么可能會延遲更久才能看到它。

為了改變這種電子郵件習(xí)慣，我們引入了一段時間的“物理提示”。在公眾區(qū)域設(shè)立一個項目展示板，在上面寫了候選版本號，每個人都可以補充和查看，信息會像漣漪一樣擴散到所有人。那你就會知道整個發(fā)布周期里你的任務(wù)，以及目前的各任務(wù)進度。這也會激勵你趕緊去做任何你應(yīng)該做的事情，這也有助于推動版本發(fā)布流程。

展示板有另一個好處，讓人們面對面交談，相互了解并開始感覺像一個團隊。它幫助我們降低了因溝通不暢導(dǎo)致的流程拖延的風(fēng)險，使我們團隊合作，并幫助我們形成了更好的溝通習(xí)慣。

總而言之，通過更有用的習(xí)慣來取代無效的習(xí)慣，展示板只是其中一個例子，你可以找到更多適合的“好習(xí)慣”。同時，一旦找到好習(xí)慣，那么就會形成行為雪球，在滾動中不斷地變大，你甚至可以在這個好習(xí)慣的基礎(chǔ)上再進行優(yōu)化。

應(yīng)用科學(xué)思維方式來理解問題

當(dāng)我第一次開始觀察發(fā)布時，為了改進它們，我們可能不知道如何理解問題。這時候與經(jīng)驗豐富的敏捷專家，精益和系統(tǒng)思想家合作的好處就顯現(xiàn)出來了。事實證明，我的整個觀察，收集數(shù)據(jù)和分析的方法，都應(yīng)用科學(xué)思維方式來理解問題的話會事半功倍。

如何應(yīng)用科學(xué)的思維方式來理解問題，包括你認為接下來會發(fā)生什么，并根據(jù)實際發(fā)生的事情調(diào)整你的后續(xù)步驟。它有四個主要步驟：

第1步：

設(shè)定你的此次發(fā)布的目的和內(nèi)容，有哪些是挑戰(zhàn)，有哪些是日常。對我們來說，大部分會是按需發(fā)布，但這并不意味著我們每分鐘都會發(fā)布，我們可以需要找到一種順暢無bug的方式發(fā)布我們想要的改進。

第2步：

了解項目當(dāng)前的開發(fā)進度和發(fā)布狀況。這就是收集和分析的數(shù)據(jù)的來源，我們基本上有一個電子表格形式的價值流程圖。

第3步：

建立階段性的小目標(biāo)，即您的第一個里程碑。從你當(dāng)前的狀態(tài)到你的最終目標(biāo)往往是一個太大的跳躍，為了取得進展，確定一個更容易實現(xiàn)的中間目標(biāo)是有幫助的。比如對我們來說，可以將發(fā)布周期從15天減少到10天，而不是直接把目標(biāo)定在3天。

第4步：

確定并執(zhí)行以達到目的。這是同樣需要數(shù)據(jù)分析，數(shù)據(jù)向我們展示了我們最大的問題是等待發(fā)布的隊列時間過長。隊列是“死”時間，在此期間沒有任何事情發(fā)生，我們只是在等待下一個過程發(fā)生。所以我們就可以將第一個改進重點放在減少或消除隊列時間上。

通過上面描述知道我們要通過科學(xué)思維方式來實現(xiàn)改變，這里有一個例子，我們嘗試將一個環(huán)境插件自動化安裝到我們的測試板塊。這聽起來像是一個自動化過程，但是經(jīng)過判斷后，我們認為它是破壞的構(gòu)建，主要原因是只支持手動進行部署，那么手動部署讓工作的效率降低，結(jié)合數(shù)據(jù)分析，手動部署會讓開發(fā)人員分心，導(dǎo)致發(fā)布進度被延遲。所以為了自動化流程 ，那必須延遲或者放棄這個環(huán)境插件的安裝。

目前運用工具來實現(xiàn)自動化進程是最快提升測試效率的一種辦法，市面上也有很多能實現(xiàn)自動化測試功能的工具或者平臺，國內(nèi)有 華為云提供的Dev Ops，國外有POSTMAN 等等。所以對于在國內(nèi)的環(huán)境，運用好的自動化工具，能幫你更好地實現(xiàn)項目運轉(zhuǎn)，提高開發(fā)測試效率。有興趣的了解Dev Ops。

改善版本的非技術(shù)方面的好處

顯而易見的好處是縮短了周期時間。周期為10天，我們兩周內(nèi)不能發(fā)布超過一次。在進行了幾次執(zhí)行之后，當(dāng)然我們不會滿足，繼續(xù)優(yōu)化自動化交付，往后再減少一半，直到可以在一天內(nèi)發(fā)布。

其他一些重要的好處包括：

1.更好的溝通和工作關(guān)系

2.自動部署到測試暫存環(huán)境意味著團隊可以更快地完成測試，從而減少周期時間和反饋循環(huán)

3.改善我們糟糕的自動化測試

4.將發(fā)布的成本從15天減少到1天，減少到1人等

5.發(fā)布后需要修復(fù)缺陷的補丁較少。

總結(jié)

1.可視化的系統(tǒng)和數(shù)據(jù)有助于找到問題所在，并在最短時間內(nèi)解決。

2.當(dāng)試圖說服管理層將時間和資源投入項目時，客觀數(shù)據(jù)和分析圖表非常有用。

3.開放式辦公室并不意味著他們溝通良好，設(shè)立展示板之類的辦法可以促進團隊合作。

當(dāng)對持續(xù)交付復(fù)盤時，很容易只關(guān)注持續(xù)交付的技術(shù)部分，畢竟，這是大多數(shù)人和開發(fā)資源所關(guān)注的地方。但是，也請查看整個發(fā)布周期，根據(jù)在項目自動化的流程和所需時間，找到在此期間其他非技術(shù)因素阻礙了發(fā)布。了解發(fā)布周期流程中的所有步驟，找到問題并改進，再確保團隊的溝通方法有效并合作，才能有助于實現(xiàn)持續(xù)交付。

DevOps

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。