你以為在談平行宇宙，其實是版本管理的策略 (一)
寫在前面
不管您所在的產業與職務分工，相信都聽過『版本控制』這四個字，尤其是出版業者與資訊業者，對於這四個字應該更有所感，在多人協作的專案中，如何確保每個分工的個體，能夠以最有效率的方式協作，是整個團隊成員共同關心的議題。
不過，這篇的立意不是野人獻曝－寫給工程師們的教戰守則與工具教學。而是寫給那些雖然不是身處工程團隊，但想更進一步了解的讀者，希望在本篇的講解之後，能和您的工程團隊能以相同的頻率對談。
這四個字雖然聽起來乏味又枯燥，為了怕您在閱讀的過程中恍神飛天，我們將以電商系統開發者的視角，套用近期英雄電影中相當熱門的梗－『平行宇宙』來解釋這檔事。
Source: Youtuber Channel / Because Science
為什麼要做版本控制
『是啊，為什麼呢？功能一次到位不是很好嗎？』
可惜在實務中，這樣的設想難以成立，所有系統幾乎無一例外的都是有機體，隨著客觀環境的變化而變化，老話一句－『計畫永遠趕不上變化』，在系統即將上線貌似一切風平浪靜的前一刻，冒出個薩諾斯，彈指一響推翻了一半的已開發的進度，這樣的情節相信您一定不陌生。
Source: Giphy
當變化發生的當下（對於某些人來說，「災難」可能是更合適的詞彙），電影中的超級英雄其實和一般人的策略相同，回到過去，試著讓這些計畫外的變化回到常軌上。積極面來說，一套優秀的版本控制策略，應該能夠促成團隊同時具備效率與彈性的特性，同時讓系統本身具備持續進化的延展性。
消極面來說，也能降低事件對系統造成的負面衝擊，即便是玩遊戲，玩家們也利用著『存檔／讀取大法』，讓你重新嘗試所需花費的時間成本降到最低。
『聽起來雖然有點耍無賴，但時光機真的是所有問題的解答啊！』
工具的選擇
在數位領域，要弄台時光機可比真實生活簡單的多了，早在2000年，開發者們意識到若要靠複製出來的程式碼文件（也就是我們前面提到的『存檔／讀取大法』），來進行版本控制，已經不足以應付日趨複雜的各式系統，也就有Subversion這樣的工具問世。除此之外，隨著雲端協作的開發模式越來越常見，市面上出現了另一套解決方案－Git，這兩者算是資訊業最具代表性的兩套主流方案，兩種方案各有許多工具可以選擇，有的要付費／有的免費；有的利用圖形介面／有的則是透過指令碼操作；各有優劣，本文暫不詳細解釋比較。
兩者最關鍵的差異點在於對於原始碼的管理方式，前者主要採用集中式的管理方式，而後者則是分散式管理，然而由於開發過程中團隊成員越發分散的趨勢，Git的市佔使用率也逐漸高過Subvision，但不管工具的選擇為何，關鍵概念是相同的，以下我們將以市占率較高的Git為例進行解說。
Source: https://www.git-tower.com/
要開始討論版本控制的第一步，得先搞清楚什麼是「分支」（Branch），我們又將如何管理這些看似繁雜的版本脈絡，準備好了嗎？上車囉。
建立分支的策略
分支（Branch）可以理解為近年影視作品常見的關鍵字－『平行宇宙』，是具備連貫性卻又各自獨立的時間軸。在系統開發的實務上，至少都會有對外運作中的正式伺服器，以及開發中的測試伺服器兩個組別；當我們採用Git建立每個專案的當下，同時也生成了Mater & Develop兩個有著主從關係的分支，分別對應到正式伺服器與測試伺服器兩個不同的環境；不論系統的規模大小，這兩個分支是必要性的存在。
但隨著專案與團隊規模的擴大，會依照開發流程，衍生更多的支援性分支，值得注意的是：不管您使用哪套工具，管理者都保有命名的自由度。
而每一個分支在建立之後，也可以於上建立子節點，撰寫源碼，進而合併回分支成為實際的成果。
所以，如果沒有一套共同的管理策略…讓開發團隊的每個成員放飛自我，恣意更迭源碼，必將導致隨之而來的紊亂，恐怕史傳奇博士也救不了你啊。
Source: Tenor
為了讓讀者對於建立分支的策略，能進一步的了解，以下，歐斯瑞參考了這套資訊業界常用的分支模型，並說明分支間的主從關係，這套模型是以資訊業界絕大多數的開發流程為基礎建立的，希望能對您有所幫助：
| 分支名 | Feature | Develop | Release | Hotfix | Master |
|---|---|---|---|---|---|
| 必要性 | 支援性 | 必要 | 支援性 | 支援性 | 必要 |
| 主要用途 | 當一個模組包含數個子功能時，會進行任務分工，通常對應到多線開發的任務節點 | 當前正進行開發並持續測試中的版本，對應到測試伺服器 | 功能測試穩定，但尚未正式對外公布的版本；通常會對應到Staging Server | 在正式公布後的版本，若發生了預期外的Bug修復或是參數的調整，將透過此分支進行 | 對應到實際運作中的正式伺服器，想當然爾，由於眾多使用者不間斷的存取資料，只有在計畫排程中的異動是被允許的 |
工具本身是有高度自由度的，支援性分支的命名並不是絕對，本文為了便於理解，以Feature / Release / Hotfix命名之，而合併／建立任務節點的動作也是不受主從關係限制的，因此以下所提出的分支模型，可以說是為了不使管理規則紊亂，而存在於團隊成員間的策略與潛規則。
為了達成多人協作而存在的 Feature 分支
應繼承自：Develop 分支
必須合併回：Develop 分支
既然稱為Feature分支（有些時候也被稱為Topic），的確是用作新功能的開發；在實務中，一個模組往往是數個子功能交互運作的結果，舉個較容易理解的例子來說，你的電商平台需要新增一種支付方式，除了前台需要提供相對應的選項和動線流程之外，後台也需要配合提供相關設定的介面，在這樣的狀況下，很可能就分成兩組人員進行實作，也就因此分成兩個獨立的分支各自開發。
而合併則是將兩者的成果整合為一，回到Develop分支，以進行後續的內部測試。這樣獨立出來的結果還有個好處－「彈性」，可以能夠在不影響最終成果的前提下，保留每個工程師各自的撰寫風格。
Source: A successful Git branching model
為了達成嚴謹測試而存在的 Release 分支
應繼承自：Develop 分支
必須合併回：Master & Develop 分支
在很多較為嚴謹的開發流程中，雖然功能已經過測試，但尚未確認其穩定性，往往在正式對外釋出之前，建立另一組測試用的伺服器，前者的Develop server主要用作功能測試，而這組則稱為Stanging Server，用以進行壓力測試與參數調整，同時也會讓更多人員加入，舉個較為代表性的例子，例如遊戲界中常聽到的PTR（Public Test Realm）。
而這個Release分支，即是為了這個需求而存在的，所以在這個過程中發生的變化更迭，必須繼承自最新的Develop分支版本，修改調整後，當然要準備公開上線，得合併回Master分支；此外，為了讓測試環境也能跟上這次的更新，也需要同步合併回Develop分支。
較具代表性的情境如下：
- 正式站上的Master版本號為1.1.5
- 測試站上的Develop版本號，我們已經知道將更新許多功能需求，是個大型改版，所以標示為1.2.0
- 正式釋出前，我們將這次的改版放到Release分支以進行壓力測試與參數調整
- 測試過程中，或許會發生一些小BUG，但並不是新功能的延伸；此時我們會直接從Release分支上建立修改節點
- 修正後，直接合併回Release分支，並且在Staging server上進行測試
- 確認這些修改可以釋出之後，這個1.2的版本號才能算是確立
- 最後，將#5的修改項目，合併回Develop & Master兩個分支
Source: A successful Git branching model
為了達成火速修復而存在的 Hotfix 分支
應繼承自：Master 分支
必須合併回：Master & Develop 分支
和前者的概念十分類似，差異點在於發生的時間點，Hot fix通常是已經正式釋出後的亡羊補牢。
所以，需要火速修復的項目，當然是盡量越少越好，而且，這些修改為求時效，往往在修改後會直接更新到正式伺服器上，也就是說，並不會經過嚴謹的內部測試。
實務上，這些修改可以是參數的調整，或是說明標籤的小部分異動，不該是跟功能邏輯相關的。
Source: A successful Git branching model
下一步呢？
本篇所提及的內容，是版本管理的基礎－Branching，對於資訊業的開發者來說，更是重中之重；你知道的，特定領域的專有名詞，真的要用中文解釋，還真的挺累人的，看到這兒，希望讀者對於版本控制的分支管理策略，有個基礎的認識了。
回到策略這回事吧，其用意在於能夠更有效地在成員間形成共識。雖然本篇中的分支模型，洋洋灑灑的條列了五個主軸，但還是得依照實際的專案狀況運用，『Keep it simple』總是最高指導原則：在相較小型的專案中，或許根本不存在Staging Server，支援性分支當然也將更加單純些。
以上是本次針對版本控制的介紹，歐斯瑞將在下一篇再更加深入一些，以Git為例，說明工程團隊稱為「Repo」的用途，並說明「Merging」、「Revert」、「Pull/Fetch」…等等行為，看完之後，不管您在團隊中的角色扮演是什麼，相信您也能對版本控制有更全面的理解。
參考資料
[wikipedia]｜版本控制軟體比較
[wikipedia]｜Deployment environment
[perforce.com]｜Git vs. SVN – What Is The Difference?
[git-tower.com]｜Learn Version Control with Git
[MicroSoft Azure DevOps]｜Adopt a Git branching strategy
[Vincent [email protected]]｜A successful git branching model
我要留言