# Outline
一、論述

# TL;DR

在國慶連假前，此系列文每天的發文時都會以最簡陳述為主，以求在繁忙的日常中，至少能先維持挑戰鐵人賽的進度，並且逐漸拓展思路與系列構成。預期會在國慶聯假好好的去修文。

一、論述

持續整合流程和 Git 的分支策略與部署環境是息息相關的，在本次範例中會以 Trunk Base Development 為分支策略，並假設有 Staging、UAT、Production 三種環境。

在分支策略上，有一主線 master，但不能對其直接 push 程式碼。要進行任何變動，都必須從 master 最新的進度去建立新的 Feature 分支，並在該分支開發，並且在完成後合併為 master。

只要 master 有最新進度，就會自動 Deploy 的 Staging 環境。

若要交付某個版本，就從 master 上的某個節點建立新的 Release 分支。但若該 Release 版本有什麼錯誤需要修正，不能直接在該 Release 分支上開發，而一樣要從 master 建立 Feature 分支，修正錯誤後合併回 master，最後再將需要的 commit 透過 cherry-pick 同步到 release 分支。若是要釋出新功能，則另外再建立新的 Release 分支，而不是將新功能的 commit 透過 cherry-pick 套用在舊的 Release 分支上。

Release 分支預期會以 release/<major>.<minor> 為名，像是 release/1.12。只要 Release 分支有新進度，包括建立一個新的 Release 分支，就會將該進度自動部署到 UAT 環境。

若想要部署到 Production 環境，就是在 Release 分支上進行 Tag，並且以 v<major>.<minor>.<patch> 格式為名，像是 v1.12.35。只要該 Commit 有標記該格式的 Tag，就可以透過 GitLab CI 手動部署到 Production 環境。只要透過 cherry-pick套用修正的 commit，就會增加 <patch> 的數字。