# DevOps 的高階工程實踐 - David Tung

{%hackmd @DevOpsDay/BJXaW1_k6 %}

問券調查 https://app.sli.do/event/ostaRWw7C6tchJT7KX54cD/live/polls

加 LINE 領簡報

## 什麼是 DevOps?

~~David: 這樣感覺好像沒有提前開始~~ 😆
~~去年聽過的就不用聽了 內容差不多~~
送的第一本書：[原來你才是絆腳石](https://www.books.com.tw/products/0010790571)


### 4+12
- 左邊 4 條，[敏捷宣言](https://agilemanifesto.org/iso/zhcht/manifesto.html)
- 右邊 12 條，[敏捷原則](https://agilemanifesto.org/iso/zhcht/principles.html)
- 前面三件事情都在講，頻繁交付，要同時兼顧品質和安全性，其實難度頗高


### 沒有 DevOps 的支撐，只能凸顯問題
- DevOps 成就了敏捷的承諾，沒有技術能力與工程方法支撐的敏捷，只能凸顯問題


### 心態 vs 能力
- 要快速迭代，你需要頻繁交付 CD 的能力
- 要頻繁交付，你需要持續整合 CI 的能力
- 要持續整合，你需要團隊合作的技術能力
- 要確保高品質，你需要敏捷測試的能力


### 故事
- DevOps 是 CI/CD? 還是自動化？是工具？還是文化？
- 人們缺少什麼，往往就會覺得什麼很重要，重要與否，跟你所在的情境有關



## 頻繁交付、持續交付，哪個比較頻繁？
- 都很頻繁 by 台北張先生
- 你覺得應該要多頻繁才算“頻繁交付”
- 現場有多少人可以『一天數次』交付，可能是願望、不是現況
- “頻繁交付” 數天一次
- “持續交付” 時時刻刻
- 沒有持續的整合，就沒有頻繁的交付
- 頻繁交付前提是持續整合


在品質與安全性不被犧牲的情況下減少 Cycle Time


- 團隊的所有成員，在迭代裡、都會在同一個分支做開發
- 直接寫主線 (main/master) 的人有兩種，一種是藝高人膽大，另一種是沒進入狀況

> 新專案由新成立的團隊負責，這是團隊成員第一次合作，團隊中較資深的開發人員過去是採用 gitflow、而年輕的開發人員都有使用 github flow 及透過 PR 進行Code Review 的經驗，這個專案初期希望以『每周一個』迭代進行頻繁交付。

你是團隊的 Leader，你會採用哪一種版控分支？

雖然很多人一起開發，但是程式碼看起來是同一個人寫的
希望開發人員能夠時時刻刻分享程式碼，不要做隱藏
CI 想做的事情就是能夠在同一個地方、編輯同一份程式碼


我們可以做 pair programming，還有 Pipeline 可以保護我們在程式碼變更的時候，可以更有保障

> 一個需要每周頻繁上版的敏捷專案打算採用全自動化上版，但團隊中有人覺得，這樣風險太高，誰能保障修改程式碼時不會改壞了東西？
> 誰知道開發人員是否隱藏了什麼不良的程式碼？
> 會不會為了修 bug 改了這邊、壞了那邊？老闆也覺得，是不是人工測試一下再上線比較好...

如果你是團隊的 Leader，你會怎麼做 ?


## Deploy 之前，你會做什麼事情

- 自動化測試放在 Pipeline 中，從單元測試裡面，抓出有問題的地方
- sonarcloud: 掃出有 Bug 的地方，程式碼品質、程式碼安全性的部分

#### CI Pipeline
- Merge 到主幹後被觸發
- 自動化整合與建置
- 自動化單元測試
- 程式碼品質掃描


- 透過套件的掃描，可以幫助你專案內的問題
- PR-CI 在合併前檢查
- 掃描請在 merge 主線之前 （隔壁棚是建議在build完之後就直接執行）

- Azure DevOps 裡面開個 Bug 單
- Azure Devops 有個看板能記錄item事項並sync至線上
- 程式碼品質掃描，套件掃描，邊 code review 邊掃描


盡可能多做自動化的單元測試 (快)

-

- 如果你希望頻繁的交付， TBD 可以實現的自動化比例越高
- 一天數次，是會有代價的，跑流程需要時間，要壓在十五分鐘內做完，沒有這麼容易


### 第一個結論

- 多做單元測試（速度快、成本低）

#### 隨堂測驗
當你積極地開始推動DevOpS，根導入舍自動上版。但卻發現，企業內的同仁認為，太快速、太自動（沒有人工介入）的交付，會讓軟體的品質變低，甚至危及系統安全。
你該如何讓同仁放心？
a）告訴老闆，良好的自動化不僅不會降低還會提升品質。
b）告訴老闆，全自動化可以提升Lead Time，用戶會開心。
c）提出成效與證據（自動化掃描報告、交付速度、改善報告），**讓數字說話**。
d）告訴老闆，自動化上版可以降低人為疏失，減少人力。

答案：c

- 可以用同一份 Code 部署到四個環境上面嗎？一版多用

過去，系統的環境分為Dev / Test / Staging /Production 等四個環境，但前陣子公司聽你的建議，採用 Github Flow 並且進行全自動上版以及頻繁交付，但卻發現一個問題。現在這四個環境全是同一份 Source Code所產生的同一份 Artifacts，PM 發現還沒做完的功能直接上了正式機，怎麼辦？測試人員也反映沒法測試屬於開發階段的功能？你是負責人，現在該怎麼辦？

- Azure DevOps Enable checkbox 功能：交付到正式機的切換
- Azure App Configuration



#### 隨堂測驗
下列何者是Feature Toggle可以派上用場的地方？
a）實現佈署（Deploy）但不開放（Release）功能
b）實現系統的A /B Testing
c）將知名作者在 FB 上發表的冒失言論下架
d）實現新功能發佈後的Rollback

答案：a b d


- 你的一次 PR 花多少時間
- 實務上：大多半天到一天跑一次 PR
- 如果你有人工簽核，一定會卡住
- 自動化簽核方式，是一種方法，每隔五分鐘去檢查某個條件、是成立還是不成立，檢查外在客觀條件改變，成立的話，就去交付到下一個動作





---

## 聊天區

可是共筆只有一個人在寫吧? 不是大家一起寫嗎 ＸＤ？

看起來是寫的1個，拍照的1個，剩下的打水，跟上班一樣?

不過如果可以專心聽是比較好啦（我是拍照的那個 哈哈）

😆

有人說之後會寄簡報給參加的聽眾 (聽說的)

希望會...不然也是蠻貴的 😖

順便求一下上一場的第三代簡報 😂
第三代簡報，我有，已更新共筆 from Anna Su
🥰🥰🥰感恩惜福

因為上一場沒拍到 所以這場全拍 害怕錯過

恭喜台北張先生獲得 「原來你才是絆腳石」
賀～！外加附魔麥克風*1

呼吸就會胖, 應該是一種持續吃飯?

~~你我現在都在 main 分支修改~~

選擇要正確 ＸＤ

feature toggle能做做退版嗎？
> 把 toogle 關掉，新功能就不會運作了

>>功能有調整的話,等於是上一版code和新版的code都在主線上囉？
>>> Yes, 也因此需要定期把舊 code 清掉，不然 code 裡會有一堆的新 code 與舊 code, 建議看一下 Martin Fowler 寫的文，會比較清楚 https://martinfowler.com/articles/feature-toggles.html