如何從開發流程層面實作更高效的持續傳遞
本文從開發流程角度分析了持續傳遞的實作，開發人員的溝通問題會拖延釋出日期，必須客觀地觀察，才能了解成員之間的問題和流程缺陷，可視化的系統有助于找到問題所在，并在最短時間内解決，使用工具或系統管理工作資料是有效提高效率的方式之一。
如今，許多企業組織都在實施持續傳遞的做法。但想要提高持續傳遞的效率，很多時候會覺得是在建構自動化測試和環境部署的時候出了問題，不過我們認為還有其他因素導緻我們釋出軟體版本時有些壓力和阻礙，隻是不确定問題是什麼。
我們開始觀察每一個軟體版本釋出過程并記錄下看到的内容。例如，完成流程的每個步驟所花費的時間，是人為手動還是自動化釋出，參與項目協作的人數有多少，以及發現導緻新版本延遲釋出的問題。一旦我們有足夠的資料，我們就可以開始分析它并尋找解決方式，這些會成為我們要解決的最重要的問題。
在觀察時保持客觀是很重要的，不要讓自己的偏見掩蓋實際發生的事實，特别是在嘗試改進項目流程和系統時非常有價值。
為什麼要專注于改善我們的釋出流程
原因是顯而易見的，在軟體版本釋出時常常不像我們預計的那樣順暢，既不能無阻礙又無法實作頻繁釋出，進而影響了我們的傳遞能力。
在改進的過程中，能與技術專家共同合作能更快優化釋出流程。與專家合作的好處在于他們尊重資料和事實，并且也非常熱衷于讓事情變得更好。同時上文提到的收集了大量資料，就可以顯示出我們的問題，這意味着我們專注于解決實際問題而不是假設。例如，資料顯示我們在測試分段環境中部署的插件比我們想象的要少得多，是以我們就可以輕而易舉地處理這個阻止我們輕松部署的問題。
穩定釋出不代表所有東西都必須在現在釋出
如果某些改進真的非常重要，那在最快的時間内釋出是不可置疑的。問題在于，當我們想要選擇本周的候選版本時，由于各種原因，團隊認為需要包含最後一分鐘的“緊急”更改。這意味着推遲選擇釋出候選版本以及對釋出周期的連鎖效應，或者工作必須加班加點，即便趕在最後釋出了，有時也會影響版本品質。
我們開始有這樣的疑問，“為什麼它必須在這個版本中出去？”，“如果我們本周不釋出更改會怎麼樣？”或“它能等到下一個版本嗎？”。要擷取答案其實非常困難，因為對于團隊來說開發已經是一個壓力很大的情況，這些疑問的提出會被視作阻止他們進行更改。但事實上，當我們試圖頻繁地釋出更改，更新疊代時，但其實是可以等待下一周時，它确實是違反了原則。因為我們會忘記了一點，軟體版本釋出的關鍵是穩定。
通過讨論并提出這些問題，我們意識到有些變化根本不緊急，是以不需要趕工。這樣做的好處是我們的版本更加順暢，需要修複錯誤的程式更少了，顯然釋出的壓力也減少了，然後我們可以更專注于如何進行周期性規律地釋出。
使用資料來識别問題和改變習慣
改變習慣是很難，因為習慣是長期這樣做的結果，但你必須努力停止舊習慣并用新習慣取而代之。選擇合适的時機釋出可以突出發現我們的釋出周期中的問題，并有助于解決修複問題。
我們可以嘗試一些方法來幫助我們養成良好的習慣。例如，如果參與釋出過程的人員将發送電子郵件作為主要通信方法的話，那一般會有數小時的延遲。必須了解到，在收件人閱讀并了解電子郵件之前，發件人其實還沒有傳達任何資訊。如果收件人正在開會，或者每天隻會定期檢查電子郵件，那麼可能會延遲更久才能看到它。
為了改變這種電子郵件習慣，我們引入了一段時間的“實體提示”。在公衆區域設立一個項目展示闆，在上面寫了候選版本号，每個人都可以補充和檢視，資訊會像漣漪一樣擴散到所有人。那你就會知道整個釋出周期裡你的任務，以及目前的各任務進度。這也會激勵你趕緊去做任何你應該做的事情，這也有助于推動版本釋出流程。
展示闆有另一個好處，讓人們面對面交談，互相了解并開始感覺像一個團隊。它幫助我們降低了因溝通不暢導緻的流程拖延的風險，使我們團隊合作，并幫助我們形成了更好的溝通習慣。
總而言之，通過更有用的習慣來取代無效的習慣，展示闆隻是其中一個例子，你可以找到更多适合的“好習慣”。同時，一旦找到好習慣，那麼就會形成行為雪球，在滾動中不斷地變大，你甚至可以在這個好習慣的基礎上再進行優化。如果你想了解更多，我強烈推薦可以在網上搜尋 Helen Lisowski 的“Good of Good（Agile）Habits”研讨會。
應用科學思維方式來了解問題
當我第一次開始觀察釋出時，為了改進它們，我們可能不知道如何了解問題。這時候與經驗豐富的靈活專家，精益和系統思想家合作的好處就顯現出來了。事實證明，我的整個觀察，收集資料和分析的方法，都應用科學思維方式來了解問題的話會事半功倍。
如何應用科學的思維方式來了解問題，包括你認為接下來會發生什麼，并根據實際發生的事情調整你的後續步驟。它有四個主要步驟：
第1步：
設定你的此次釋出的目的和内容，有哪些是挑戰，有哪些是日常。對我們來說，大部分會是按需釋出，但這并不意味着我們每分鐘都會釋出，我們可以需要找到一種順暢無bug的方式釋出我們想要的改進。
第2步：
了解項目目前的開發進度和釋出狀況。這就是收集和分析的資料的來源，我們基本上有一個電子表格形式的價值流程圖。
第3步：
建立階段性的小目标，即您的第一個裡程碑。從你目前的狀态到你的最終目标往往是一個太大的跳躍，為了取得進展，确定一個更容易實作的中間目标是有幫助的。比如對我們來說，可以将釋出周期從15天減少到10天，而不是直接把目标定在3天。
第4步：
确定并執行以達到目的。這是同樣需要資料分析，資料向我們展示了我們最大的問題是等待釋出的隊列時間過長。隊列是“死”時間，在此期間沒有任何事情發生，我們隻是在等待下一個過程發生。是以我們就可以将第一個改進重點放在減少或消除隊列時間上。
通過上面描述知道我們要通過科學思維方式來實作改變，這裡有一個例子，我們嘗試将一個環境插件自動化安裝到我們的測試闆塊。這聽起來像是一個自動化過程，但是經過判斷後，我們認為它是破壞的建構，主要原因是隻支援手動進行部署，那麼手動部署讓工作的效率降低，結合資料分析，手動部署會讓開發人員分心，導緻釋出進度被延遲。是以為了自動化流程 ，那必須延遲或者放棄這個環境插件的安裝。
目前運用工具來實作自動化程序是最快提升測試效率的一種辦法，市面上也有很多能實作自動化測試功能的工具或者平台，國内有 EOLINKER，國外有POSTMAN 等等。是以對于在國内的環境，運用好的自動化工具，能幫你更好地實作項目運轉，提高開發測試效率。有興趣的點選了解 EOLINKER。
改善版本的非技術方面的好處
顯而易見的好處是縮短了周期時間。周期為10天，我們兩周内不能釋出超過一次。在進行了幾次執行之後，當然我們不會滿足，繼續優化自動化傳遞，往後再減少一半，直到可以在一天内釋出。
其他一些重要的好處包括：
- 更好的溝通和工作關系
- 自動部署到測試暫存環境意味着團隊可以更快地完成測試，進而減少周期時間和回報循環
- 改善我們糟糕的自動化測試
- 将釋出的成本從15天減少到1天，減少到1人等
- 釋出後需要修複缺陷的更新檔較少
總結
- 可視化的系統和資料有助于找到問題所在，并在最短時間内解決
- 當試圖說服管理層将時間和資源投入項目時，客觀資料和分析圖表非常有用
- 放式辦公室并不意味着他們溝通良好，設立展示闆之類的辦法可以促進團隊合作
當對持續傳遞複盤時，很容易隻關注持續傳遞的技術部分，畢竟，這是大多數人和開發資源所關注的地方。但是，也請檢視整個釋出周期，根據在項目自動化的流程和所需時間，找到在此期間其他非技術因素阻礙了釋出。了解釋出周期流程中的所有步驟，找到問題并改進，再確定團隊的溝通方法有效并合作，才能有助于實作持續傳遞。
參考資料：Sylvia MacDonald,Continuous Delivery - It’s Not All about Tech!
位址：https://www.infoq.com/articles/continuous-delivery-not-about-tech/
posted on 2019-07-26 16:05 隔壁王書 閱讀(...) 評論(...) 編輯 收藏