owned this note changed a year ago
Linked with GitHub

Trunk-Based Development makes DevOps easy. - Paul Hammant

歡迎來到 DevOpsDay Taipei 2024 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口:https://hackmd.io/@DevOpsDay/2024
手機版請點選上方 按鈕展開議程列表。

議程介紹

收看即時AI翻譯字幕|Watch AI-translated subtitles

填寫議程滿意度問卷|回饋建言給辛苦的講者

共筆從這開始

tags: DevOpsDays Taipei 2024

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Source control with DevOps is important to me

CI and Trunk-Based Development

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

a branching model for source control

4種公司規模

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

發佈頻率 100, 10, 1, 1/10 days 佈署一次
緊急修復 2.5, 0.5, <0.1, no 次
CI 本身談論的目標是, 每個開發人員每天將工作重新納入source version control.
Release 的頻率愈高,因為 hotfix 的需求愈低,unplanned 的程度反而愈低.

理想狀況是, 持續性計畫性地發布以及 0 個計畫之外的發布.

Release 頻率愈低,抓馬愈多,加班愈多,愈多制度上的不公平(修錯誤要加班,獎金發給加班的人)

Release 的頻率相當於練習的頻率,「專家會練到不犯錯」,頻繁 release 等於增加練習的頻率
如果公司每天能發布 10 個版本時, 會發現公司的時間其實已經消除了所有可能發生的錯誤.

Bad Branching models(對應到前面四分的 Slow Enterprise)

620720
紅線表示 build 不起作用, 可能無法編譯, 或者單元測試無法運行.
Slow Enterprise : (紅線)Not deployable 數量約等於 deployable

  • 死線到了才 merge
  • merge 很痛苦,unmerge 很難

簡報圖片的來源

Traditional Trunk-Based Dev (對應到前面四分的 Better Enterprise)

620723

圖中的藍色區域是每個開發人員在工作的地方, 距離主幹分之的距離應該只有一天的時間間隔.
發布分支(灰色部分)在接近發布時間時, 不該允許開發人員在該分之上工作, 只有發布工程師和 SRE 可以在該分之上工作.
Trunk,所有開發者共享的 branch

簡報圖片的來源(中文版)

Better TBD (1/1 Transitional)

620729
基於主幹開發需要我們在source control 中實踐良好的feature toggle 機制

Google-class TBD

沒有分支,只有標籤。

(一天發布十次)

620732

Case Study - Big FX Bank

620737
這樣的分支模型, 很可能導致有些人在 release 的最後幾天內長時間的工作.
需要做的是將這混亂的建置系統轉移至都是綠線的統一建置系統, 所以需要引入單元測試以及測試自動化.
抽象分支的目的是, 使得發布意圖早於發布的工作完成之前.

More differentiators: Pre-prod 環境(QA, UAT 等)

620741
這裡以 QA 的角度, 並運用四種顏色, 討論與表達更多差異化因素.

Slow:因為QA環境都是手動建立,沒有留下任何文件,容易失去/無法重建QA環境

Better : 複製相同環境需要一天

Transitional : 通過 IaC 工具將基礎設施環境也加入source control中, 能快速建立 QA 環境並獨立執行測試
將建立 QA 環境的方法、測試都包含到主幹中,建立不同的 QA 環境變成可以計算的成本(只需要額外取得算力)。

Fast : All in trunk, 隨時產生QA env

More differentiators: Release binaries

620749
Slow: zip, 包啥誰也不知道
Better: pkg
Transitional: pkg for roll-back
Fast: Just fix forward.

More differentiators: databases

620751
Slow: 資料庫的發布計畫交由 dba 執行, 但這並不會在開發團隊的掌控之中.
Better: 會同時定義出兩個版本間的migration script 以及rollback script
Transitional:
Fast: 會一直forward fix , 不考慮rollback

Google's TBD monorepo

620757
monorepo 促進團隊, 無論使用什麼技術, 都在同一個source control repo中, 只是被劃分至不同的目錄之中.這使得所有團隊能同步更新對應的依賴.

改一個模組,所有用到模組的都會 release。

Google monorepo 是指 Google 使用的單一、龐大的程式碼儲存庫,其中包含了幾乎所有 Google 產品和服務的原始碼。這個儲存庫被稱為 Piper,它是一個集中式的版本控制系統,讓 Google 的工程師們可以更輕鬆地協作、共享程式碼,並維護程式碼的一致性。 by Gimini

One CD: Continuous Delivery

620763

is to be or not to be.要麻生存, 要馬毀滅
from Shakespare

CI 事實上只是把每個commit 或 pr, 推入 QA/UAT 環境中, 並不會直接投入正式環境中
CD(持續交付) 指在沒人覺得不妥的情況下, 將程式的變更投入 QA/UAT 環境中.

The other CD: Continuous Deployment

620764

沒有發布指令、pull requests 直接投入production env

Non Continuous Delivery

620766

CD 和 NCD

Grading companies / clients

At the get-to-konw-you stage

620767
通過以下的問題循序漸進地了解, 客戶的公司正處於什麼階段.
問客戶的問題:

  • 同一個應用程式/服務,一年有多少計畫中和計劃外的發布?
    • 從這個問題可以把客戶分進前面的四類,大概就知道後面的情況
    • 要能區分 planned release 或單純只是 bugfix
  • 製作一個 QA(或 UAT)環境要多久?
  • 製作第二個要多久?
    • 服務和資料庫不能跟第一個環境共用
    • 防火牆要分開
    • 可以清楚知道所需預算
  • 製作第三個 QA 環境要多久?

https://phdo.paulhammant.com/Trunk-Correlated-Practices-Chart

https://phdo.paulhammant.com/BofA-Platform-Case-Study

Q&A

Q:
A: 這比較是個社交技巧的問題。當然需要支持的架構。要搜集意見、找到對的人挺 TBD、讓團隊能表達安心的轉移時程、好好計畫。在舊作法和新作法之間找到一個折衷。


共筆聊天室:

TW TBD

HIHI
HI
Hi
Hi~~
morning
zzz
testingggggg
Hi
簽到~
Forward Fixing:前進就可以得到兩樣東西!
不懂就問:為何要製作多個QA環境?

  1. 測試不同feature?
  2. 不同程度的整合測試?
    翻譯是不是用不了@@

Select a repo