前言
今天又是一篇要來逼迫自己整理筆記的分享了~這次要整理的筆記是David Tung分享的DevOps的高階工程技術實踐。
故事開始前...
可以先思考看看
- DevOps 是 CI/CD? 還是自動化？是工具？還是文化？
- 頻繁交付、持續交付，哪個比較頻繁？
1.持續交付 v.s. 頻繁交付
- 頻繁交付 : 數天一次
- 持續交付 : 時時刻刻
- 舉例來說:在一般人的情況下，有可能會頻繁進食，但不會持續進食
沒有持續的整合，就沒有頻繁的交付，頻繁交付的前提是持續整合
要如何做到頻繁交付?
首先，要先做到的是縮短cycle time，但在縮短cycle time的前提下，還是要確保品質&安全。
- 分支策略 : 分支數量越少越好、分支生命週期越短越好
- pair programming : 兩個人一起開發、一起思考
- CI pipeline : Merge 到主幹後被觸發、自動化整合與建置、自動化單元測試、程式碼品質掃描(e.g. sonar cube)、套件掃描(e.g.whitesource)
小結
- 不要在任何地方影藏程式碼
- 可以考慮pair programming
- 在pipeline中加入自動化掃描:單元測試(成本低、快)、套件掃描、程式碼品質掃描、自動化UI測試(成本高、慢)..
2.開發到一半尚未完成，但有其他功能要上線...
利用Feature toggle
- 動態決定開啟或關閉某些功能
- 在程式碼當中透過 if…else判斷敘述來配合
- 本人警語:功能上線後如果穩定，一定要把feature toggle移掉，移除或開關時也務必處理乾淨，否則就會影響線上使用者.....(
本人親身經歷QQ
小結
- 維持同一份source code，以同一分artifact佈署到不同環境。
- 可以透過Feature Toggle來解決環境差異問題。
3.部屬還要人工簽核?????
圖片來自David的簡報，去年聽這part就沒有很懂今年先速速拍照xD
人工簽核
- 人工介入，收到信或有空時才會去按approve
### Release Gate - 保持自動化
- 持續檢查外在客觀條件改變
小結
- 盡可能以全自動方式來處理佈署
- 人工簽核(Approval) ，不適合用來作為佈署前的品質控制
- 針對品質的控管，可以採用Release Gate或許更適合
- 人工簽核適合用來做為商業釋出前的人為市場判斷
- 若搭配Feature Toggle，可輕易隔開Deploy與Release(佈署但不釋出)
4.導入敏捷，但品質卻下降了
沒有時間測試
因為要頻繁交付，所以開發時間或測試時間都可能被壓縮，相信應該有些人碰過類似的狀況吧!但頻繁交付不會且也不應該犧牲軟體品質!可以試試一些自動化的測試方法
小結
- 測試左/右移
- 自動化單元測試
- 調整架構以實現自動化測試: 像是慢慢改成微服務、前後端分離、API First之類的
結論
- 頻繁交付讓客戶早點看到成果
- DevOps 成就了敏捷的承諾
- 如果這件事很痛苦但是正確的，繼續做下去
- 以終為始、持續鍛鍊(自己 & 自己的團隊)
