描述軟體開發的理想世界
在理想世界我們只有一個版本，沒有bug，有足夠的時間開發，開發不會延遲。但是現實世界並非如此，所以我們有了軟體版本控制系統，我們有了分支。
限制分支的數量，把分支看成一個一個stage(development、QA、Beta test、Live)，來處理短周期Release，避免分支過多，不管Release再怎麼短，Release Branch只會有三個(所以並不會限定development branch)，這個作法稱為staging codeline。
從mainline中分支出development分支，來處理不同開發者，不同團隊開發延遲或是錯誤的程式碼造成無法Release的問題
除非開發者的成果可以正常編譯且功能正常，否則不會進mainline，達成mainline可以維持在理想狀態不斷前進
用Map(地圖)、Protocols(協定)、Convention(公約)、Etiquette(禮讓)來讓Branch可以被管理，
Ex：道路
只接受穩定的改變，決不強加不穩定的改變
一但relase line被改變，即刻把change整合進baseline，因為release line的改變就是bug fixes and patches，所以會讓baseline更穩定。
絕對不能從baseline把change送進release codeline，因為release line有被更多的測試，所以更加的穩定，而baseline的change會造成release line的穩定度下降，這個原則經常被違反。
change應該被持續整合到development codelines，可以帶給development更多的穩定度，而且可以反映最新的狀況。
development codeline不是持續整合到baseline，而是分批整合到baseline，要整合到baseline，必須滿足以下條件：
要實作的功能都已實作到一個好的點(Point of completion)，實際上可能還有bug，只要不打亂baseline就OK，
通過development line自己的test
baseline要是正常狀態(不能有build is broken)
通過baseline的test
module：一個包含檔案的目錄架構，檔案的內容就是軟體的一部份，可稱為source tree、component、subsystem、folder，module裡面的相對路徑是該元件能夠正確運作不可或缺。
codeline就是module的集合，通常mainline會包含所有的module，分支出去的codeline，會包含所有或是部份的module。
module分成幾個種類：
Active：就是要被開發的module，就是branch出codeline的理由，隨著工作進行不斷改變，會流向baseline或是從baseline流過來，例如正在開發的物品使用功能。而流向的規則就是比較與baseline的軟硬。
Inactive：拿來作編譯、測試、除錯，並不會隨著工作進行而改變，流向也只會從baseline流過來，例如公司內部開發的數學運算函式庫，從mainline分支過來某遊戲的development codeline之後，就只是叫用功能而已，不會作改變，當這個函式庫開發者作了大更新到mainline上面，而這個更新的功能codeline有需要，就會從mainlien merge過來。如果是外部的第三方函式庫，可能連更新都不會更新。
Private：是baseline的縮減版，在開發時期會持續改變，但是不會與baseline有任何流動，例如bin/，內容都是編譯出來的，或許包含設定檔，但這些設定檔也是給debug或測試用，不會回到baseline。
根據以上定義，不同的Module與baseline的互動，可以歸納出如下的結果：
Active:只需要merge
Inactive Module：只需要copy
Private Moduel：什麼都不用作
雖然coding&mering會破壞穩定性，但這是一定要作的事情，不然就不會有產品。但是可以把風險集中在某些地方，因此coding&merging應該在soft codeline。
所以要"Merge down, copy up"，從Release line到mainline作merge，從mainline到development line作merge，然後development要作好編譯與測試，然後copy回去mainline。此外，在copy回去mainline的這段時間，mainline必須是被鎖定的，這樣會中斷其他開發者的開發？所以流程必須要建立在development line常常從mainline merge過來，而且有畫分好Active module與inactive module，測試也要很快就能測試結束的狀態下。
心得
baseline必須有一套測試機制，最好是自動，如果還要動用到QA，那QA會太多工作，讓QA只處理Release line就好。
development line也必須要有一套測試機制，通常可以把baseline的拿來用。
要使用module來表達軟體，就要先把軟體切分好元件，或許一開始沒辦法一步到位，但是可以透過重構的方式來改善。
問題
怎麼在Perforce上分Active、Private、InActive Module?好像也是用想法分?
在理想世界我們只有一個版本，沒有bug，有足夠的時間開發，開發不會延遲。但是現實世界並非如此，所以我們有了軟體版本控制系統，我們有了分支。
限制分支的數量，把分支看成一個一個stage(development、QA、Beta test、Live)，來處理短周期Release，避免分支過多，不管Release再怎麼短，Release Branch只會有三個(所以並不會限定development branch)，這個作法稱為staging codeline。
從mainline中分支出development分支，來處理不同開發者，不同團隊開發延遲或是錯誤的程式碼造成無法Release的問題
除非開發者的成果可以正常編譯且功能正常，否則不會進mainline，達成mainline可以維持在理想狀態不斷前進
用Map(地圖)、Protocols(協定)、Convention(公約)、Etiquette(禮讓)來讓Branch可以被管理，
Ex：道路
codeline=觀念
branch=實作
codeline分支出來的起源稱為baseline
沒有baseline就稱為mainline
aka=also known as
tofu scale：越上面越硬(可測試，接近Release，也就是穩定)，越下面越軟(不穩定，離Release遠)，這個等級代表改變codeline的風險程度。mainline在中間的位置，每個codeline的tofu scale相對於mainline，注意：親子codeline可以表示相對硬度，兄弟codeline只能跟baseline比較
staging codeline與tofu scale在mainline上合體，形成可以兼顧Release與development的分支策略
以map方式表達分支狀態，處理兄弟codeline表示的問題，表達Change該如何流動
使用Change Flow的策略，完成把所有Change Flow全部匯流到mainline的理想，所以mainline只會穩定的成長
branch=實作
codeline分支出來的起源稱為baseline
沒有baseline就稱為mainline
aka=also known as
tofu scale：越上面越硬(可測試，接近Release，也就是穩定)，越下面越軟(不穩定，離Release遠)，這個等級代表改變codeline的風險程度。mainline在中間的位置，每個codeline的tofu scale相對於mainline，注意：親子codeline可以表示相對硬度，兄弟codeline只能跟baseline比較
staging codeline與tofu scale在mainline上合體，形成可以兼顧Release與development的分支策略
以map方式表達分支狀態，處理兄弟codeline表示的問題，表達Change該如何流動
使用Change Flow的策略，完成把所有Change Flow全部匯流到mainline的理想，所以mainline只會穩定的成長
Change Flow只能在codeline與它的baseline之間流動，所以一個codeline的改變只能流到baseline，基本上不能跳著流動
只接受穩定的改變，決不強加不穩定的改變
一但relase line被改變，即刻把change整合進baseline，因為release line的改變就是bug fixes and patches，所以會讓baseline更穩定。
絕對不能從baseline把change送進release codeline，因為release line有被更多的測試，所以更加的穩定，而baseline的change會造成release line的穩定度下降，這個原則經常被違反。
change應該被持續整合到development codelines，可以帶給development更多的穩定度，而且可以反映最新的狀況。
development codeline不是持續整合到baseline，而是分批整合到baseline，要整合到baseline，必須滿足以下條件：
要實作的功能都已實作到一個好的點(Point of completion)，實際上可能還有bug，只要不打亂baseline就OK，
通過development line自己的test
baseline要是正常狀態(不能有build is broken)
通過baseline的test
module：一個包含檔案的目錄架構，檔案的內容就是軟體的一部份，可稱為source tree、component、subsystem、folder，module裡面的相對路徑是該元件能夠正確運作不可或缺。
codeline就是module的集合，通常mainline會包含所有的module，分支出去的codeline，會包含所有或是部份的module。
module分成幾個種類：
Active：就是要被開發的module，就是branch出codeline的理由，隨著工作進行不斷改變，會流向baseline或是從baseline流過來，例如正在開發的物品使用功能。而流向的規則就是比較與baseline的軟硬。
Inactive：拿來作編譯、測試、除錯，並不會隨著工作進行而改變，流向也只會從baseline流過來，例如公司內部開發的數學運算函式庫，從mainline分支過來某遊戲的development codeline之後，就只是叫用功能而已，不會作改變，當這個函式庫開發者作了大更新到mainline上面，而這個更新的功能codeline有需要，就會從mainlien merge過來。如果是外部的第三方函式庫，可能連更新都不會更新。
Private：是baseline的縮減版，在開發時期會持續改變，但是不會與baseline有任何流動，例如bin/，內容都是編譯出來的，或許包含設定檔，但這些設定檔也是給debug或測試用，不會回到baseline。
根據以上定義，不同的Module與baseline的互動，可以歸納出如下的結果：
Active:只需要merge
Inactive Module：只需要copy
Private Moduel：什麼都不用作
雖然coding&mering會破壞穩定性，但這是一定要作的事情，不然就不會有產品。但是可以把風險集中在某些地方，因此coding&merging應該在soft codeline。
所以要"Merge down, copy up"，從Release line到mainline作merge，從mainline到development line作merge，然後development要作好編譯與測試，然後copy回去mainline。此外，在copy回去mainline的這段時間，mainline必須是被鎖定的，這樣會中斷其他開發者的開發？所以流程必須要建立在development line常常從mainline merge過來，而且有畫分好Active module與inactive module，測試也要很快就能測試結束的狀態下。
解決分支複雜度的方式，在本文中就是以下四種觀念：
Map(地圖)：就是流動的圖，描述軟硬關係，流向
Protocols(協定)：就是baseline protocol，Release line到baseline持續Merge，baseline不能流向Release line。baseline持續流向development line，development line分批流向baseline。
Convention(公約)：分成Active，InActive，Private三個Module，"Merge down，Copy up"。
Etiquette(禮讓)：進baseline要切出空檔時間，讓不同Team&Member copy回去，其他人禮貌地等待。
心得
公司裡所有的專案與元件全部都會在mainline上面，也就是直接在Perforce的depot下。
只要一分支出codeline，擁有者必須要持續維護，還有作測試，雖然不管是perforce，Git，或是Subversion都可以分支，但是如果是牽扯到共同開發的分支，就必須遵守規則，換言之就是維護成本提高，但是如果可以讓事情變得更好，就算成本提高也是值得。
baseline必須有一套測試機制，最好是自動，如果還要動用到QA，那QA會太多工作，讓QA只處理Release line就好。
development line也必須要有一套測試機制，通常可以把baseline的拿來用。
要使用module來表達軟體，就要先把軟體切分好元件，或許一開始沒辦法一步到位，但是可以透過重構的方式來改善。
問題
用copy或是merge在perforce的codeline會有什麼不同的呈現方式?還是用想法管理?
實際將private copy到mainline，可以看到copy的選項與merge不同，基本上copy就是將branch mapping整個蓋過去。所以為防止蓋到不想蓋到的地方，ㄧ定要先作merge，保證沒改動的地方與mainline完全相同之後再copy上去。完成之後在reversion graph看到的與merge一樣，方向也相同，不過可以看到chang list裡面描述的不同，有copy from。那copy到底有什麼意義，經過思考之後，我的理解是：
- Merge可選擇來源codeline的change list要不要進目標codeline，可以看到額外的選擇很多，所以是用在從hard to soft，Ex：從Release到mainline
- Copy就是從來源codeline覆蓋到目標codeline，所有changelist照單全收，所以適合將新功能進baseline，也就是從soft到hard，Ex：從private到mainline，如果弄了新功能，卻又不想進mainline，那merge也沒有用。真的發生這種狀況，就是codeline的作用定義不清楚。
怎麼在Perforce上分Active、Private、InActive Module?好像也是用想法分?
沒有留言:
張貼留言