文章彙整

你以為在談平行宇宙,其實是版本管理的策略 (一)

By Astral Web 1 month agoNo Comments
首頁  /  網站設計與開發  /  你以為在談平行宇宙,其實是版本管理的策略 (一)

寫在前面

不管您所在的產業與職務分工,相信都聽過『版本控制』這四個字,尤其是出版業者與資訊業者,對於這四個字應該更有所感,在多人協作的專案中,如何確保每個分工的個體,能夠以最有效率的方式協作,是整個團隊成員共同關心的議題。

不過,這篇的立意不是野人獻曝-寫給工程師們的教戰守則與工具教學。而是寫給那些雖然不是身處工程團隊,但想更進一步了解的讀者,希望在本篇的講解之後,能和您的工程團隊能以相同的頻率對談。

這四個字雖然聽起來乏味又枯燥,為了怕您在閱讀的過程中恍神飛天,我們將以電商系統開發者的視角,套用近期英雄電影中相當熱門的梗-『平行宇宙』來解釋這檔事。

 

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

 

為了讓讀者對於建立分支的策略,能進一步的了解,以下,歐斯瑞參考了這套資訊業界常用的分支模型,並說明分支間的主從關係,這套模型是以資訊業界絕大多數的開發流程為基礎建立的,希望能對您有所幫助:

分支名FeatureDevelopReleaseHotfixMaster
必要性支援性必要支援性支援性必要
主要用途當一個模組包含數個子功能時,會進行任務分工,通常對應到多線開發的任務節點當前正進行開發並持續測試中的版本,對應到測試伺服器功能測試穩定,但尚未正式對外公布的版本;通常會對應到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分支。

較具代表性的情境如下:

  1. 正式站上的Master版本號為1.1.5
  2. 測試站上的Develop版本號,我們已經知道將更新許多功能需求,是個大型改版,所以標示為1.2.0
  3. 正式釋出前,我們將這次的改版放到Release分支以進行壓力測試與參數調整
  4. 測試過程中,或許會發生一些小BUG,但並不是新功能的延伸;此時我們會直接從Release分支上建立修改節點
  5. 修正後,直接合併回Release分支,並且在Staging server上進行測試
  6. 確認這些修改可以釋出之後,這個1.2的版本號才能算是確立
  7. 最後,將#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

以上內容由Astralweb 歐斯瑞編寫製作

 000

推薦文章

Category:
  網站設計與開發

留下回應

你的電子郵件地址不會被公開.

取得獨家電子商務祕技

建立更好的策略靈感

跟上全球的網路趨勢

絕佳的電商解決方案

電子商務戰略全指南

每月發送電商戰略指南,只要填寫E-mail即可訂閱!

請到您的信箱確認,即可完成訂閱。