# Community Driven DevOps - 劉栢峰 Bryan Liu

{%hackmd @DevOpsDay/BJXaW1_k6 %}

> 講師提供的資訊連結:
* Blog: [Community Driven DevOps](https://pofengliu.github.io/devops-notes/#/page/community%20driven%20devops)

具講師說以上內容都是講口語轉文字的

## Devops Evangelist & Faiths
* RD 聽得下多少

### 信仰來源

- 解決身邊沒效率的問題
- hotfix 到底要測幾次？
- Bug 重複出現
- Merge hell
- Long intergration & code freeze
- QA 沒時間
- 解決身邊不合理的流程
- 質量反饋滯後性
- 每天早上花一定時間檢查為何失敗
- 數百數千隻的 test automations
- RD也不看測試了什麼

### 軟體公司的數字化轉型?
* 轉型代表什麼事情
Dev 開發很快 但後續的成效跟 Dev 都沒關係

### 快速交付是種能力
> 能力是需要培養的，不是等著被催促後才想辦法變快
> 不是求[快速]兩字，是需要[快的能力]。

* 現在企業生存的關鍵
* 快速交付，是需要跨部門的合作
* 商業的敏捷是企業生存的本能，也必須依賴科技
* DORA 4 要素

實際情況：
* Biz 說：不需要這麼快啦
* 團隊是做 Platform 的，穩定性是最重要的。
* 風險的衡量
* 各部門的利益考量衝突
* 反例：Guardian 日報，biz 認為要快，並且為了做到一天 release 多次，總共只有 4 個 automated test 套在全產品

為什麼快？
* 有能力快，但不用使出來
* 要多快？試錯成本有多少
* 大家學到的 Agile, Scrum, DevOps 核心概念都差不多，但為什麼別人做出來的效果不一樣
* 重點在 Culture

試驗假設
* 開發的功能沒人用？A/B testing

實踐方式：Trunk-based with Feature Toggling
* 快速上版快速實驗快速 release 的 strategy
* 快速 toggle off to fast rollback
* 讓 DORA metrics 動起來！縮短 cycle time

### 基本定義
* 很難執行 unless base on Trunk development ENV
* Unit test 都沒有算是 CI 嗎

Trunk-Base-Development (TBD)
- 每天至少 release 到 trunk 一次
- trunk always releasable

* 定義的存在為了少走錯路

* web & cloud 適合 trunk not GitFlow

### Automation Strategies
- 快速反饋中的測試驅動的開發
- PBR meeting in every sprint

* Acceptance Criteria (AC)
* pipelinedriven.org

Test 在 PR 就要跑完了，並且保持 Trunk branch 綠色狀態

工法的重要性：
* 沒有嚴謹的準則，會帶來看似都對的彈性
* 久了，會變成要處理的 Legacy

### History of DevOps TF
Community of DevOps Task-Force

透過 dashboard 觀測 new code coverage

透過**溝通** Development mindset
導入 Community 的幫助，推動 team consensus
思考 checklist 一多是否可以自動化

---
## 聊天室
Logseq 原來可以匯出為靜態網頁檔阿

求投影片~
怎麼投影片內容跟上方連結的內容不同啊~

求投影工具，可以放大好酷呀
> [name=Bryan][time=Tue, Sep 26, 2023 4:50 PM]
> [Pro Mouse](https://apps.apple.com/tw/app/pro-mouse/id1505869474)
>
這台可以 [SPOTLIGHT 無線藍牙簡報器(金/灰) | 羅技 Logi 網路旗艦店](https://store.logitech.tw/products/spotlight-%E7%84%A1%E7%B7%9A%E8%97%8D%E7%89%99%E7%B0%A1%E5%A0%B1%E5%99%A8%E9%87%91-%E7%81%B0?variant=40018441830423&currency=TWD&utm_medium=product_sync&utm_source=google&utm_content=sag_organic&utm_campaign=sag_organic&gad=1&gclid=CjwKCAjw38SoBhB6EiwA8EQVLpnWWXePfwvKwkI48iOovLx8AZAaNU3i9N1RfONBClTUB9Y7926SORoC2WQQAvD_BwE)
講者不是就單純用滑鼠😅😅😅
> 你需要先有一臺 MacBook

麥克風收音感覺不太行
+1
一直噴麥 🥲
需要麥克風套套？😳😏
> [name=Bryan][time=Tue, Sep 26, 2023 4:56 PM]
> 難怪 Rudy 老師要帶自己的耳麥 ...
>

rd沒反應大概是mic的關係

守舊就是美 你改了流程影響產品你要負責嗎(🫠

會場二的音響好小聲 QQ
+1，而且聲音好模糊，聽不清楚
講者的聲音其實本來就有點糊

而且聲音好柔 快被催眠 😵‍💫

希望講者下次演講可以有精神一點

快還要更快～又快又要穩 - -
**摸豆嗨壓哭！**
~~摸頭還要哭~~

比較像是三步工作法說的要先快速取得反饋？不過個人認為更難的是是否有交付對客戶有價值的產出共識，那就需要先定義什麼才算對於客戶有價值的指標
> [name=Bryan][time=Tue, Sep 26, 2023 5:00 PM]
> 對呀，要快就要先確認需求，需求錯了之後還要 rework，哪快得起來還更慢吧？！
> 所以我們花了三年多導入實例化需求，開發前就讓相關人等確認需求。
> 用 toggle 小批量上版，MVP 好了先上，toggle 打開讓客戶做 beta user testing，先拿到初期反饋！不要等到功能全部做完了再交給客戶 ...

但常常 untoggle 是 untoogle 了 但改壞了既有的 code (X
> [name=Bryan][time=Tue, Sep 26, 2023 5:07 PM]
> Toggle on/off 的 scenarios 都要測呀，印象老馬 blog 有寫過一些跟 toggle 相關的文章有提到，建議可先看看。

feature toggle 拔掉的時候是不是還要再測一次相對應的功能？
> [name=Bryan][time=Tue, Sep 26, 2023 5:07 PM]
> Toggle 拔掉代表新 feature 已經在 production 且沒問題才會拿掉。也代表新 feature 的 AC (Acceptance Criteria) 已經被自動化覆蓋了，你拔掉的 code commit 上去，pipeline 不就自動幫你驗證了嗎？
> 一般來說現代化的開發，每個 store 的 AC 要寫成自動化測試提交，必需就是 team DoD (definition of done) 的一部分！

話說金絲雀部署，會限制每次進來的 ex: 1% 都是同一群使用者嗎？
> [name=Bryan][time=Tue, Sep 26, 2023 5:07 PM]
> 一般來說，為了避免老是同一群人都一直被派到實驗組 ... 都會 append 一個 salt key 跟著這個 user 的 entityID 進去做 hash. 習慣會用每個 user story 的 name/ID 當成 salt key。 臨時找不到範例，概念上有點像[這個](https://www.geeksforgeeks.org/what-is-salted-password-hashing/)。

依據使用情境吧，可以透過特定的 header 或是 cookie 來讓指定請求導到新版本
感恩大大👍

我想問: 用feature toggle 把未完成的code加進trunk增加devlopment frequency有什麼意義?
儘早合併，避免 feature branch 生命週期過長，待合併的時候還要花時間來去解 conflict
-> 增加feature toggle的overhead有比解conflict的overhead還要小嗎?
推昨天那場: https://hackmd.io/@DevOpsDay/2023/%2FDP9XoKV8TTyeCvhz2ygg_A
Feature Toggle 應有現成 framework/library 可以協助管理，高級的甚至可以直接線上管理開關，不需要重新部署
> [name=Bryan][time=Tue, Sep 26, 2023 5:30 PM]
> 的確！只要你進的 code 不影響線上功能，你是不需要加 toggle 的。
> Hide unfinished code 只是 toggle 的其中一個好處，早早 merge 到 trunk 而不是留在 isolated feature branch，避免你同事根據你舊的 code 在改他的新 features.
> 別忘了，toggle 還能帶來後面 cannary, a/b testing, kill switch 等好處！功能開關的確是一個 technical debt，但好好 manage (ex: 用 process, library 去限制 toggle 數量)
toggle 帶來的好處應該會多過處理 toggle 的 efforts.
> 網路上有很多如何管理 toggle 的文章，建議看看然後選擇適合你們的

各位大大有推薦 Feature Toggle 的 framework/library 嗎？
- [GrowthBook - Open Source Feature Flags and A/B Tests](https://www.growthbook.io/)
- [OpenFeature](https://openfeature.dev/)
- [Unleash](https://github.com/Unleash/unleash)
- [launchdarkly](https://launchdarkly.com/)
> [name=Bryan Liu]
> 因為種種特別的因素，我們 task-force 測試了許多工具，最後選了這個
https://openflagr.github.io/flagr/#/ ，僅供參考～
Commercial 最有名的就屬 Launchdarkly，就算你不用它，他們有許多文章也可以學到很多跟 toggle 相關的知識～

感謝大大👍

想問：當專案的測試覆蓋率還很低的時候，是不是就不適合使用單主幹開發? 尤其當專案規模已經很大的時候
測試涵蓋率跟 Git 分支模型的關係是？
因為如果沒有保護好，那一個新人不就很容易摧毀核心的Code?
假設既有運行最複雜的 Git Flow，那 Git Flow 的哪些做法可以做到保護核心功能？依個人見解還是需要靠自動化測試跟人工程式碼審查
> [name=Bryan][time=Tue, Sep 26, 2023 5:37 PM]
> 想快，基本功就是要打好。所以整個簡報，核心理念不就是卓越之路看起來就是困難、艱困、無聊的嗎？所以今天講我們推廣 DevOps，前面不就是先把 unit-test, 需求探索等基底做好... 而且是花了幾年時間慢慢讓大家習慣做這些事 ...
> > 感謝講師回答！
> >
OK 感謝大大👍

延伸：專案規模很大的狀況應該是要研究怎麼抽離或模組化成小物件，再每個小模組獨立執行單元測試，head再做整合測試，這個流程小弟覺得會是比較好的解決方案，想問一下實際上執行會遇到甚麼問題~

我們的情況比較像是太多的技術債．當我們在模組化功能的時候，時常會踩到前輩留下來的驚喜(常常一個function 負責處理10~20種需求)，次數多了主管就會開始要求先做完需求了

想問: 如果有N個feature toggle，每次測試都要跑2的N次方嗎? 不然有些feature toggle的開關組合沒測到會不會就有test coverage不夠的問題

引用 Java 社群 qrtt1 前輩的一段話
> feature toggle 如果是用在控制 feature 在適當的時候 release 的話，千萬不要一直留著他不讓他退場，以前公司有用的時候，明明東西都 GA 了過了好多版後才刪。

> [name=Bryan][time=Wed, Sep 27, 2023 12:03 PM]
> 一般上線後沒問題，幾天後就可以撤掉了。
> 每個 toggle 設計還是偏好是各自獨立的，但難免功能 B 是在功能 A 之上所開發的，所以功能 A toggle 沒開之前，功能 B toggle 是不能開的！所以 toggles 之間的 combination 其實並以不是各種組合都要測，是有邏輯性可推論。重點還是限縮 toggle 數量。
> 我的想法是，同樣開發兩個功能，你可以用兩個獨立 branches 各自開發，也可以用 toggles。 功能開關的排列組合是 process 可控、所需測試情境是有邏輯可推敲的; 但兩個 long-lived branches 在 merge 後可能出現的 bugs 是毫無邏輯可預防直到佈署上去。

那大家有的feature toggle的數量級大概在哪裡?
以我們團隊對於 Feature Toolge 的實踐僅有部分同仁有做，因此量級在個位數而已 (單個微服務)

話說有 feature toggle 的話可以當熔斷機制用嗎 XDDD
人工熔斷嗎？
應該說有些指標達到時，直接呼叫 API 開關 toggle，這樣是否就達成熔斷機制？
蠻好奇各位怎麼實作熔斷機制？好像都沒有現成的 library 需要自己實作？
[斷路器模式 - Azure Architecture Center | Microsoft Learn](https://learn.microsoft.com/zh-tw/azure/architecture/patterns/circuit-breaker)
> [name=Bryan][time=Wed, Sep 27, 2023 12:01 PM]
> 沒錯，所以我們在 feature toggle 工具選型時，能夠用 API 去控制 toggle 是其中的一個需求。在自動熔斷或是自動化測試 on/off 狀態時都會用得上。

想問：feature toggle 適合用在產品中給客戶只需要用到的功能開關嗎？例如Ａ客戶只需要ＡＢ功能、Ｂ客戶只需要ＢＣ功能
理論可以吧，不過客戶是要高度客製化，那可能就不是那麼合用
> [name=Bryan][time=Wed, Sep 27, 2023 12:21 PM]
> 沒錯，以前做白牌產品，每個客戶所用程式是用一個 branch 來維護，一段時間後眾多版本的維護成本就超高的。現在產品都是 SaaS，只有一份佈署在雲端，＂Permission toggle＂ 用來控制不同客戶需求就是常用到的情景。
> 但＂高度＂客製化的需求，是不是 feature branch 反倒比較合適呢？！這可能就是業務跟開發單位要一起評估的。

引用 LaravelConf 的工作坊筆記，這場內容就是在談 Feature Toggle
[LaravelConf 2023 - HackMD](https://hackmd.io/@mileschou/laravelconf2023-workshop)

怎麼突然講的很糊
我已經半放空了，還好有 Blog 文章可以補充

Blog 手機適配版面好醜QQ
波動拳 XDDDD

想問：那頻繁部署時要怎麼跟業務 BD 互相 sync ，畢竟有可能人家在 demo 的時候結果你上了一個有問題的版本？
+1 想頻繁上版有時候是卡在跟其他部門sync，而不是自動化的問題
+1 +1
環境切乾淨 你有pre_demo就不怕demo撞車了🙃
很多2B的產品要release前還要通知客戶，這種狀況要做到一天多個release，客戶每天被我們的release轟炸，滿意度真的會提升嗎?
聽起來問題是每一次的 release 是會影響到客戶使用的，而無法無痛切換
-->用藍綠部署來解決此問題？
> [name=Bryan][time=Wed, Sep 27, 2023 12:31 PM]
> 對 toggle 的使用情景還是需要多點想像力，同一套環境你完全可以讓不同公司的人看到不同的功能！要讓同一間公司的線上使用者跟 beta 測試人員看到不同 features 且互相不影響也不過是基本 segmentation / whitelist 的用法而已~
> 使用 toggle 就是要減少 branches、testing envs 的使用，如果還要另一套環境來做 blue-green?! 外面的 cloud resources 都很貴不是嗎？

文化/政策這種東西要從下而上好難 QQ
-->大家都在喊向上管理，但是沒有主管的支持，也無從推行也只是自己喊爽的
> [name=Bryan][time=Wed, Sep 27, 2023 12:37 PM]
> 這邊 Community driven 漸漸走出的模式就是用 community 的決定去影響並取得上面的 concensus & endourcement，然後變成 top-down 下來加快大家的採用。 管理層同意 community 或 task-force 的成立，就代表他也要賦予這個社群某些的 authority 去驅動變革不是嗎？
> 這幾年的 community 經驗， buttom-up & top-down 都各有各的好處且都是需要的

針對地端的feature toggle 會怎麼做?
~~去買 Google Anthos 或是 Azure Stack~~
XD
其實不太確定這個問題的上下文，對於地端環境實踐的難處是？
- Istio