上次跟大家分享了縮短 Release 的價值，用實際的數字來讓大家感受一下，透過縮短 Release 週期所帶來的好處，希望大家也可以實際的試試看縮短 Release 週期，不過在談到要縮短 Release 週期的時候，聽到最多的困擾是，那實際上要怎麼做，才能夠讓 Release 這件事情可以快速並且頻繁的發生呢？
1. 適當的 Task 大小
通常在做任務拆分時，我會希望把 Task 大小控制在 1~3 天能完成的範圍（這就看個人，我個人喜歡至少這個粒度，不過越小越好），就算是一個大功能的局部功能也好，並且這個 Task 在做完之後就可以直接上線，是能跟完全相容現在的系統，在透過系統架構設計，例如 Config 或 Feature Flag 來控制功能是否開放給使用者。
(打完這一部分之後就發現有另外兩件事情可以和大家聊聊，關於任務拆分的處理和如何透過系統架構設計來持續上線程式碼 XD)
2. Code review
Code review 其實是團隊協作中很重要的一件事情，當然如果你們經常直接 Pair Programming 的話就可以省去這一段，我很喜歡 Code review 的一個原因，是因為這是一個討論程式碼實現的很好機會，通常你會有一些具體的例子可以來討論，並且也可以同步團隊成員對於整個系統架構的期望，所以除了確認程式碼是否正確之外，不要浪費這個機會和團隊成員們交流討論，這也是一個偷偷學習別人思路的好時機！另外透過 Code review ，還能確保大家對於整個系統的認知是有跟上進度的，像我們目前團隊就會確保至少有接近 50% 的成員 Approve 之後才能 Merge PR，讓大家在不能 Mob 時也能跟上大家所做的變更。
3. 持續整合、部署
除了人為的 Code review 之外，我通常還會相當依賴 CI Server 來幫我們做各種面向的檢查，從最基本的測試我們就有至少單元測試、整合測試、視覺 (Visual) 測試等等，還有團隊開發一定需要的 Linter 來確定程式碼風格一致，如果更進階一點就是可以做安全性掃描或是程式碼分析，如果做的是 Web 或 App 的開發還可以考慮做一些 Benchmark 來確保系統的執行速度符合預期，既然了解了持續快速部署才是產生價值的最大方式，我們就應該讓所有能自動的就自動化，才能讓人力專注在最需要的地方，剩下的就交給自動化工作來處理就好了
4. 監控
在聊持續部署、快速部署的時候，一個很常見的誤區是很多人以為上線後就結束了，我只要盡量的在 Merge 之前確保做好各種事情，然後想辦法讓 Pull Request 變綠燈，拿到足夠的 Approve，然後 Merge 進去我就馬上趕快開始新的工作。
但其實對於使用者來說， Merge 程式碼之後才算是真正的開始，因為他們才能夠開始使用你所部署的新功能，所以持續部署中最重要的事情是 ”上線之後”，有沒有足夠的監控機制可以知道你系統運作的情形，不只是有一些 CloudWatch 的 Monitor 或是 Centralised 的 Log 管理系統來幫助除錯，甚至你應該要建立一些 Client events 的 Tracking 或是 Funnel 來監控你的系統是不是可以被正常使用，如果有任何異常的時候能在客戶回報前就能發現，現在其實有很多的現成工具可以使用，有些還能夠直接設定自動警示，讓你在系統有流程中斷的時候被通知。
5. 異常排除
在有了足夠的監控系統之後，你有沒有足夠的手段來減輕這些異常對於客戶的影響，舉例來說，假如今天你結帳流程中本來有信用卡結帳跟超商付款，如果今天信用卡公司剛好故障，你能不能透過 Feature Toggle 或是 Config 來暫時關閉信用卡功能，讓使用者還是可以使用其他的方式結帳，這件事情你可以多快完成，它是否需要重新部署才能做到，都會是異常排除一個很重要的指標，當然今天這個例子是客戶端的異常排除，如果今天是 Cloud Service 發生問題時的異常排除也是一個很經點的例子，至少也要有跨 Region 的 BCP。
6. 成效追蹤
功能上線之後，你是否能夠知道這個功能對於客戶帶來多大的改善，對於系統有多少的優化，其實都是需要被 ”量化” 追蹤的，很多人都會誤以為用感覺來測量就足夠了，沒有實際的量化其實很難評估回顧一個新功能的規劃是否產生了正確的價值，還是其實一切都是感覺良好，例如你更新的購物流程的畫面，是否實際對整個流程的轉換率有所提升，還是只是單純的變好看但對業績沒有幫助，這些其實都是需要很赤裸的被量測，才能真正的作為疊代的依據，找出團隊目前的方向和規劃方式有沒有問題。
我覺得在敏捷開發中很容易被誤解的是，很多人以為只要用了對了方式（或是大家都在用的方式），就可以讓產品快速開發、上線並疊代，跟上那些新創獨角獸的腳步，卻忽略了這些其實都是軟體的技術基礎硬實力，通常大家只會跟你說他們使用某種方法帶來很多成效，但不會透露背後做了多少的基礎改善，所以要小心就算所有團隊成員心態正確，老闆觀念正確，沒有相對應的硬實力，敏捷也只是空談，當然，如果你想要改善軟體開發硬實力也不是不可能，我推薦最簡單直接的方式就是找 91 敏捷開發之路
你在做持續 Release 的時候也有遇到什麼樣心得或痛點嗎？歡迎你也分享一下你對這件事情的看法喔！粉絲團默默的快 1000 人了，我也開始打算來個每週固定更新，如果你覺得我的分享不錯的話，歡迎你也對我的粉絲團按讚喔！
ci tracking 在 rustc-pr-tracking/ci.sh at master - GitHub 的推薦與評價
Statistics about PRs on the rustc repository. Contribute to rust-lang/rustc-pr-tracking development by creating an account on GitHub. ... <看更多>