前言

今天又是一篇要來逼迫自己整理筆記的分享了~這次要整理的筆記是David Tung分享的DevOps的高階工程技術實踐。

故事開始前...

可以先思考看看

1. DevOps 是 CI/CD? 還是自動化？是工具？還是文化？
2. 頻繁交付、持續交付，哪個比較頻繁？

1.持續交付 v.s. 頻繁交付

• 頻繁交付 : 數天一次
• 持續交付 : 時時刻刻
• 舉例來說:在一般人的情況下，有可能會頻繁進食，但不會持續進食
  沒有持續的整合，就沒有頻繁的交付，頻繁交付的前提是持續整合

要如何做到頻繁交付?

首先，要先做到的是縮短cycle time，但在縮短cycle time的前提下，還是要確保品質&安全。

• 分支策略 : 分支數量越少越好、分支生命週期越短越好
• pair programming : 兩個人一起開發、一起思考
• CI pipeline : Merge 到主幹後被觸發、自動化整合與建置、自動化單元測試、程式碼品質掃描(e.g. sonar cube)、套件掃描(e.g.whitesource)

小結

1. 不要在任何地方影藏程式碼
2. 可以考慮pair programming
3. 在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之類的

結論

1. 頻繁交付讓客戶早點看到成果
2. DevOps 成就了敏捷的承諾
3. 如果這件事很痛苦但是正確的，繼續做下去
4. 以終為始、持續鍛鍊(自己 & 自己的團隊)

文章同步發布於:https://tw.coderbridge.com/@hsiaovicky567/1d60c2236f784491b33804c4fb35eb4e