在編碼程序中，一個很容易發現的現象就是：
經常依賴手工操作的程序，一定容易出錯，而且是反復出錯
這就是持續交付出現的原因，
持續交付的目標就是從代碼編譯到可部署的二進包，甚至是部署這個很多都是依賴手工操作的程序自動化，流水線化，
微言碼道開始新的系列，從零到一，構建你的持續交付流程
這是第一篇，
一）
稍微觀察下，你所參與的專案，從編碼到部署服務，這個程序是如何推動的？
估計方式有挺多，但總體來說，可以分為兩種方式，一種是依賴人工手動操作，還有一種是自動，
手工的方式當然可能多種多樣，有些可能還會有非常規范的流程約束，但最終仍然避免不了由某個特定的開發或測驗或運營人員，以遠程登錄到服務器的方式，執行某些命令，來達到部署新版本的目標，
這個程序是不是非常熟悉？
當然，因為這就是大多數專案的日常而已，
而持續交付則主張：
把從原始碼編譯開始，直至部署，甚至部署后的必要驗證等全部由計算機來執行，將這個程序流水線化，自動化
二)
所以，我們需要開始思索一個問題，究竟哪些程序應該或者是可以放到持續交付中，
構思一：將二進制包的構建程序自動化
這種是最初級的，也是大多數持續交付應該最起碼要達到的目標，
觸發構建 --> 編譯原始碼 --> 生成二進制包
就是將編碼的最終的二進制包的生成程序自動化，不需要再由開發人員手工來做，
關于這一點，我本人有挺大的感觸，前幾年在我負責移動開發的時候，我們移動端團隊最煩的一件事就是給測驗，專案經理及各種客戶打包，因為不同的包的App名稱，Logo都不一樣，沒有一個統一的包，只能按需打包，
很長一段時間內，都是由這些人找到我們團隊的人來打包，
每次打包對我們團隊的開發人員其實是個很無聊但又挺折磨人的事，因為要修改名稱，LOGO，或者又有一些定制化的修改，改完發包，發給相應人員，如果有問題再來回折騰，
效率極低，而且極其浪費開發人員的時間，
大約在18年還是19年的時候，我就想著如何改善這個現象，于是在一個MacOS系統上，基于Jenkins，寫了些Shell腳本，把這個程序自動化了，
這就是最簡單的一種形式，將生成二進制包的程序自動化，
構思二：把單元測驗和質量分析納入進來
我是TDD測驗驅動開發的忠實的信徒，所以基本都會寫單元測驗，那在持續交付的這個程序中，當然也可以把單元測驗加進來，
想像下，每次觸發構建的程序中，自動運行所有單元測驗，通過才構建，不通過中止構建，
這是不是挺好的一件事?
還有質量分析，在后端我通常是用Sonar來協助做質量分析，而在前端也是用的主流的ESLint，那在這個持續交付程序中，是不是可以自動的把代碼放到這些工具上去執行，分析并具報告？
甚至更完美點，設定一個質量的標準，只有達到這個標準的才允許繼續執行這個流程，沒有達到的中止流程，比如為單元測驗覆寫率設計一個目標，達到這個目標以上才算通過，
這又讓我們的持續交付幫我們做了單元測驗與代碼審查這兩個事情了，
非常好，
構思三：將檔案更新與部署自動化
很有可能，我們在專案中，都會撰寫一些檔案，比如Api檔案或Java doc檔案，
那我們完全可以把Api檔案或Java doc檔案的生成與部署也自動化，
這樣每次流程完成，所有檔案都保持在最新的狀態，對開發人員來說，只需要撰寫檔案就好，不用關心如何生成HTML或PDF，以及怎么樣把它更新到服務器上部署等，
又往前推進了一步，
構思四：部署的自動化
也許僅僅生成二進制包并不足夠，至少在某些環境下并不足夠，
為什么不在開發環境自動重啟服務？或在測驗環境下提供一個按鈕或某種機制，讓測驗人員點擊一下就完成服務重啟？
相比讓人去拿二進制包再COPY到哪個服務器上，重啟這種手工的操作，讓流程來做到這一切，不是更好么？
所以把這個也加入持續交付中吧，
構思五：及時的通知與反饋
我們希望這個交付流程的運行程序，能及時有效的通知給我們，成功或失敗，或者上一次失敗這一次成功等各種我們設定的條件下，以郵件或短信或微信訊息等，不論什么形式都好，第一時間通知開發團隊，
構建失敗，構建失敗，構建失敗了
當構建失敗時，如果我們能收到類似的通知，我們就能立馬做出反饋，及時修正，
等恢復成功后，可以再通知我們
好了，構建成功了
這樣的通知也是不能少的吧？
更多，還有更多
事實上，能做的還有挺多的，
比如，我們期望服務重啟后，運行一些簡單的健康檢查，以證明這個服務重啟后的狀態是OK的，因為很有可能某個配置配置失敗或資料庫當機了等，
甚至，我們都可以加上其它很多程序，，，
我們并不需要一步到位，我們只需要記住一個真理：
復雜實作永遠是構建在簡單實作的基礎之上，所以我們可以從簡單的開始*
三）
是的，我的確就是這樣構思的，
雖然還沒有做到服務重啟后的必要的健康檢查，但至少從構建一到五，我都一一實作了，
最終的交付流程如下圖所示：
并且，這個交付流程不僅僅是針對某一端，比如只是后端，
我把它應用于整個專案，包括前端，后端都做到了持續交付，
只是前端沒有單元測驗和API檔案，少了一些不需要程序而已，
這意味著，整個專案的這些程序都是自動化的，這些程序都不需要人工參與，
四）
這就是從零到一，構建你的持續交付流程這個系列的目的所在，我想讓更多的人知道如何實作這個程序，
而好的工程實踐，是保證好的，可維護的代碼的基礎與前提，
下一篇：從零到一，構建你的持續交付流程（二）：好的工程實踐是必要的前提
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/352179.html
標籤：其他