or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Trunk-Based Development makes DevOps easy. - Paul Hammant
歡迎來到 DevOpsDay Taipei 2024 共筆
- 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
- 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
- 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種公司規模
- 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 →- 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 →- 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)
紅線表示 build 不起作用, 可能無法編譯, 或者單元測試無法運行.
Slow Enterprise : (紅線)Not deployable 數量約等於 deployable
Traditional Trunk-Based Dev (對應到前面四分的 Better Enterprise)
圖中的藍色區域是每個開發人員在工作的地方, 距離主幹分之的距離應該只有一天的時間間隔.
發布分支(灰色部分)在接近發布時間時, 不該允許開發人員在該分之上工作, 只有發布工程師和 SRE 可以在該分之上工作.
Trunk,所有開發者共享的 branch
Better TBD (1/1 Transitional)
基於主幹開發需要我們在source control 中實踐良好的feature toggle 機制
Google-class TBD
沒有分支,只有標籤。
(一天發布十次)
Case Study - Big FX Bank
這樣的分支模型, 很可能導致有些人在 release 的最後幾天內長時間的工作.
需要做的是將這混亂的建置系統轉移至都是綠線的統一建置系統, 所以需要引入
單元測試
以及測試自動化
.抽象分支
的目的是, 使得發布意圖早於發布的工作完成之前.More differentiators: Pre-prod 環境(QA, UAT 等)
這裡以 QA 的角度, 並運用四種顏色, 討論與表達更多差異化因素.
Slow:因為QA環境都是手動建立,沒有留下任何文件,容易失去/無法重建QA環境
Better : 複製相同環境需要一天
Transitional : 通過 IaC 工具將基礎設施環境也加入source control中, 能快速建立 QA 環境並獨立執行測試
將建立 QA 環境的方法、測試都包含到主幹中,建立不同的 QA 環境變成可以計算的成本(只需要額外取得算力)。
Fast : All in trunk, 隨時產生QA env
More differentiators: Release binaries
Slow: zip, 包啥誰也不知道
Better: pkg
Transitional: pkg for roll-back
Fast: Just fix forward.
More differentiators: databases
Slow: 資料庫的發布計畫交由 dba 執行, 但這並不會在開發團隊的掌控之中.
Better: 會同時定義出兩個版本間的migration script 以及rollback script
Transitional:
Fast: 會一直forward fix , 不考慮rollback
Google's TBD monorepo
monorepo 促進團隊, 無論使用什麼技術, 都在同一個source control repo中, 只是被劃分至不同的目錄之中.這使得所有團隊能同步更新對應的依賴.
改一個模組,所有用到模組的都會 release。
Google monorepo 是指 Google 使用的單一、龐大的程式碼儲存庫,其中包含了幾乎所有 Google 產品和服務的原始碼。這個儲存庫被稱為 Piper,它是一個集中式的版本控制系統,讓 Google 的工程師們可以更輕鬆地協作、共享程式碼,並維護程式碼的一致性。 by Gimini
One CD: Continuous Delivery
CI 事實上只是把每個commit 或 pr, 推入 QA/UAT 環境中, 並不會直接投入正式環境中
CD(持續交付) 指在沒人覺得不妥的情況下, 將程式的變更投入 QA/UAT 環境中.
The other CD: Continuous Deployment
沒有發布指令、pull requests 直接投入production env
Non Continuous Delivery
CD 和 NCD
Grading companies / clients
At the get-to-konw-you stage
通過以下的問題循序漸進地了解, 客戶的公司正處於什麼階段.
問客戶的問題:
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環境?
翻譯是不是用不了@@