這段時間，一直在進行CICD過程的研究設計和實施。現在寫一些關鍵的、與團隊成員不斷反覆討論的點。
我們開發過程，保護主分支有一個分支叫B標分支。
1. 爲什麼要有B標分支。以前在DT的儀表團隊，我任了一年多的版本經理。仔細學習和理解了升級過程的一些細節問題。爲了防止出現以往我們大團出現無數個分支的困境，最後我精簡爲兩個分支，一個是主分支，一個是B標分支。B標分支是我學習公司其它項目的做法。
當時，雖然任了一兩年的升級經理，但沒有真正整理和理解一個B標分支，這次開發CICD過程，重新理解了一遍。
（1）保護主分支。主分支有時也叫商用分支，B標分支，有時也叫團隊開發分支，有的公司叫pre_release分支。但實際上，我還是覺得B標最精準。它不是開發分支，也不是pre_release，實際是一個pre_test分支，甚至叫pre_test也不精確。它的存在，主要是爲升級服務的。
從事軟件開發的這20年來，我感覺軟件業需要學習一些傳統行業積累下來的經驗教訓。
許多公司，有研發部，有測試部，但實際上，最最難的正在在這兩個部門之間的那些活在夾縫中的人。而且，他們非常 之重要。
比如，我時任版本經理時，可以說時常非常緊張。
例如，每週都要發佈一個版本到測試，我首先將這兩週分爲激進周和保守周。激進周儘量提目前技術經理要求滿足的特性(C&R)，但保守周則不允許提新特性，只能提bug的resolve.
每週五，我會發出預升級通告，給所有的子項目經理，給出下週是激進周，還是保守周的說明，然後給出升級請回接收的最後時限，一般是下週一的11點左右。還有其它所有質量部給出的所有的升級環節的時間點（質量部定流程，我這裏定時間）。
要求，週一前，信息中心的生產數據管理部門，會給出PDM product標和軟件B標和正式標。
然後，週一下週一點到2點間，升級會，最後確定升級清單，然後交給測試部測試經理執行。這個過程，是我重要的關注點，我會一項項審覈所有的升級請求。因爲一般在週一的上午9點左右，我們會與技術經理和商務人員，有時項目經理也會參與，討論目前用戶的意見和關心的新需求，我會詳細記下來。然後會發一封給所有子項目經理，本週升級的特性目標，作爲正式升級通告。所以，下午這場會，我會詳細審覈每個升級項。與大方向不符合的，將會被無情地打回去。但那些版本計劃中，本該升的，相關的子項目經理一定要有明確解釋，如果認爲理由不充分，有問題，也要升，升了以後提bug，但是也要升級！因爲這是研發升級，每三個月纔有一個商用版本release. 升級經理，永遠要注意向計劃負責，向需求負責，不是向穩定無限的地負責，穩定不是升級經理關注的，而且保守升級這一週，已給了研發方喘息之機。
最晚一般在週三前，所有開發者將私人分支、開發分支信息，提交到B標分支，週四下午5點前，由信息中心數據部門鎖標，啓動自動編譯和打包過程，週五早晨測試部從數據中心（持續集成部門）得到最終大包。開始准入測試。週五下班前，給出準出結果，完成升級過程，進入測試部的範疇。與升級經理脫離。
可見過程的艱辛。以至於後來沒人願意幹這事了。技術經理後來成了官僚，升級經理不存在了。這是後話。也是令人痛心。
我以自己任項目經理時，我是請大家轉班，一人輪值一個月來完成升級過程，因爲實在是太複雜和累人了。但公司層面，一路糊塗到底。最後連質量部也沒了。流程都沒人定，沒有質量部來執法，大家炒成一鍋粥。不過現在都與我無關了。
今天我想到哪說到哪。再回頭說B標，爲什麼要有B標分支。和現在的CICD有什麼關係。
===============================================
從上面這段文字來看，B標有如下功能和特點：
1. 永不後退。這是一個很重要的特性。這也是我任升級經理時的重要要求。子項目團隊的開發分支，個人分支， 甚至是主分支，都有可能回退，但B標絕不能回退。
B標爲什麼不能回退？難不成升級過程中，不能回退嗎？的確是這樣。一個大的系統，強調的是完整 ，有子系統回退，其它人會被波及，結果是每次都升不了級。有人會說，難道我們要發佈有缺陷的產品嗎？的確這就是生物的生存法則。我們只是選了缺陷相對少的那個而己。這是設計問題，如何讓產品容錯，防止錯誤累積，如何在線升級，等等，這是另外一個學科，對於升級來說，絕不能後通。錯誤要在錯誤的基礎上修正，每次升級，最多一般我只允許一次被生產部門打回來。再出問題，我會禁止相對的組參與升級，否則時間點一定會被推遲。
2. 允許髒信息。B標就是一個幹髒活累活的分支。所有的代碼歸併的問題，將集中在 B標上被發現。衝突由後發起的人解決，直到代碼可以歸併。一次升級，可以有N個merge 節點。這裏不需要完美。我們要力求完美 的是主分支（商用分支）。B標可以挪，但只能向前挪。後退也要用前進來實現。
3. 這個地方很難理解，很多人會以爲B標分支會帶來各團隊代碼不同步的問題，這裏是不存在的，工具將會保證。也是B標分支的關鍵作用。假如兩人修改了同一個接品文件，後merge的一方，將在歸併時被deny，不得不回去改。
4. B標分支只有一個，這個是前面的描述包含的。我發現，許多人，有一種拉分支的天然慾望，在升級過程中，作爲升級經理，你必須要非常非常的tough，絕不能在這方面通融。根據質量部的流程，B標是由信息中心給出的，不是由研發部定的，理論上，也不允許研發方在這方面動手腳本。
5. B標的鎖定者，是信息中心根據版本經理的計劃執行的。研發人員是無權干涉的。所以，技術經理可以是個官僚，但升級經理，必要是非常 tough，到點就鎖，絕不拖延。鎖了就不要開。
6. 鎖標後，由信息中心的數據生產部門，自動進行編譯和打包。並且與研發經理自己提交的B標研發方編譯結果進行二進制比對。這項是極爲重要的。我不象其它人誇誇其談，你要是開發公司，就會明白，在沒有法制的情況下，公司內部大家是如何進行扯皮的。比如，研發方可以說我代碼是好的，是你信息中心給我們編壞了。
所以要二進制比對。當然，有的文件，二進制不能完全一致，這理論是不合法的,gcc可沒這毛病,毛病出在人身上。但有時也沒有辦法。
許多公司不注重打包這件事，這件事實際更重要。你把寶馬裝上奔馳的輪子，兩個研發團隊都可以說不是自己的事。許多公司的客服，總是自己拆拆裝裝，然後提交給客戶，最後研發一推二一五，這其實只要與OM部門協調好，不合規定的包，就不要加載即可，但前提是定是大包，一般一塊板卡，最多只能有一個包。而且最絡要打到更大的包裏。
有人問，爲啥多道手序，要信息中心這些文職人員給編出來呢？沒錯，美國爲什麼是文官體系？這些道理，我們就不說深了。最重要一點是，研發和測試可能合起夥來忽悠公司，例如每次升級的東西是根本不能跑的。爲什麼要這樣呢？自己思考吧。
7. 然後是准入測試。這個過程之後，升級經理就解放了。
可以看到，升級的過程的艱辛和危險。實際上也很漫長。但許多公司完全忽略這些人的存在，更是不明白，如何由質量部來司法。升級經理在這裏是執法者，司法是質量部，立法是所有人蔘與的，主要是技術委員會。
先說這些吧。有空我再寫CICD的事。CICD是研發者自己的事，理論上也用不着B標，但對於平臺開發者來說，還是可以將二者結合起來的。
標準的CICD的含義和被觸發執行的時間點
gitlab-ci 標準的CICD見gitlab網站的Introduction:
https://docs.gitlab.com/ee/ci/introduction/
可以有如下總結：
（1）與傳統的持續集成不同，CICD的服務對象是developer，更直白說是請開發者自己挖坑自己跳。這是西方管理學將第三方管理進一步推進到由平臺監督的自我管理的方向。
（2）CICD的發生時間點，在兩種地方：開發者向自己的遠端開發者分支push或merge時。這裏push表示開發者沒有進一步展開第四個所謂的針對某個特定的feature（或bug,C&R）分支，直接在自己的開發者分支上，merge則是從開發者自己的feature分支，merge到遠端開發者分支上。相關的圖大家自己找吧，二者沒有本質分別，不同是3個分支，還是4個分支數。
（但注意，這只是管方說法，這兩種方式，最後我們都拋棄了，我們最後用的類似merge request時，進行CICD）
這個觸發過程，是理解和實施時的核心要點。一般來說，作爲GK的你，不要給程序員過多的選擇。如果項目不是那種特別活躍的，三個分支的方案已足夠。
觸發，進一步從主動賓角度來分解，主語是開發者自己，這點很重要，這是根本需求，所以設計和實施時要注意這一個基本點;物因和本因，要搞清楚。物因就是觸發前是什麼樣，本因是觸發後是什麼樣。但一定要理解，從物因到本因的過程，纔是CICD。而且還不是全部。
具體來說，假如開發者從自己的本地開發者分支，push到自己的遠端開發者分支，這裏，平臺自動觸發CICD過程。這個過程相對簡單容易理解。平臺是坐莊者，它知道發生了什麼，要做什麼，這個自不必說，開發者向遠端push到自己的遠端開發者分支上，這也沒什麼可說。
但這樣，並沒有什麼輸出。這裏說的輸出，是可以做爲平臺的輸入的輸出。因爲CICD表面服務對象好象是開發者，真正服務的對象是平臺。它在CICD成功後，將要自動發起merge過程。
但明眼人一看，問題就來了。
merge就要提merge request，因爲developer沒有權利向officel分支push或merge。如前所述，平臺在收到CICD過程後，就要自動發起merge request，這個不是說不能做到，但幾乎一定需要大量的二次開發，因爲提交的信息往往很多。然後TA進行codereview，然後GK，然後check in.
這樣對於我們這種程序員被抓了壯丁來實施CICD的兼職者來說，顯然是無法接受的。
這樣也就是說，管方的流程，在這一點上，我們不應當採用。成本過高。
所以，我們回到B標分支的原始思路。
B標分支（以後稱爲CICD分支）方案
事實如上，gitlab公司的想法是，你們這些人，只需要出錢就好了，其它的我們包圓。所以google一下，許多人勸大家用自己的方案，不要用gitlab的方案，要free你從gitlab的方案中。這很容易理解，我也是給老闆打開，我們老闆也是爲還沒付錢的甲方打工，誰能一開始就拿錢出來呢？
所以，官方的方案，我們不能用。因爲從mergerequest開始，都要錢了。。。怎麼說到錢了呢。。。
所以，我們回到一個新的舊方案，就一個永不回退的髒分支，來保護offical分支。
我們叫它CICD分支。如果前面你理解了B分支，它就是B分支。
我們採用了B分支，有一個最最重要的好處：開發者向B分支push（或merge）時，我們發起CICD，那麼merge過程是先發生，然後CICD的。
看起來是不是流程倒了？不是應該先CICD再merge到offical分支上嗎？
這其實是合理的。
因爲gitlab-ci 的mergerequest 過程，實際上，也是偷偷合到一箇中間分支，然後纔開始編譯的。
這是本文很要的一個理解。
稍思考下就明白了：CICD要檢查一種合理的代碼，這個代碼應當是主分支的代碼，但要經過CICD確認才能合到主分支。是不是死循環了？所以實際上merge的過程（CICD有兩個觸發點，一個是研發人員自己查自己，我們不再提這種對於我們系統無意義的方式，以後只提與offical分支相關的CICD），是一定要有的，而且也的確是合到某個master分支的臨出拉出的隱藏分支去之後發起的CICD。也就是實際就是merge了兩次，一次爲CICD，一次在CICD成功之後（失敗當然不能merge了），這也是B標分支的另一個含義。
再回頭看我們的改進方案，這樣就合理了。
我們把潛藏的B分支，拿了出來，不再是不可見的了。
有人又會說，出了B分支，是不是應當每次編譯前，從offical分支fetch到B分支呢？
這裏需要詳細分析情況。
理論上不需要。
爲什麼呢？因爲一旦B分支存在，而所有的升級流程都是經過B分支編譯成功，且自動測試通過（定點回歸和准入），那麼也就是說offical分支的所有內容，都是從B分支合過來的，也就是說，B分支纔是永遠最新的分支，所以，信息流是單向的。
但爲什麼說理論上呢？
如果你實際上，有兩個B分支，那麼情況就不同了。
也許讀到這，可能會疑惑，爲什麼可能會存在兩個B分支呢？這完全與系統思想不符合？因爲系統第一定義是完整、完備。兩個分支，這一定是出了問題吧？
這也不對。
我們的世界是10維（有人說是11維），這裏面，一個含義是各維度是相互獨立的。
似如，在編譯linux時，linux的代碼，必須只能在一個維度，這容易理解，因爲我們發佈給用戶的linux必須是完整的事務（linux是宏內核的，理論上不允許一部分是二進制文件，另一部分是代碼的方式編譯，如果微內核要複雜得多）;但是gcc則是另一個維度。它理論上有自己的升級鏈;再例如yocto則是另一個維度，所以，對於多維度複雜項目 ，B標分支有多個，每個B標分支，代理一個行政上完全獨立的開發團隊。
這們這裏，比這還要複雜。
因爲我們要繞過gitlab-cicd，所以，我們需要一種方案，在我們原有的庫裏，如bitbucket裏的代碼，能在gitlab-ci 中CICD。但是用過gitlab 的人知道，gitlab-ci 過程依賴（確切說是binding）在.gitlab-ci.yml文件之上，但用戶可不希望他的代碼裏有這個文件。
所以，必須有兩個B標。
但是，實際上我們執行時，因爲gitlab這邊，不需要offical分支，所以gitlab這邊，只有一個用於cicd的B標分支，.gitlab-ci.yml自己在一個獨立分支上，每次CICD前，我們需要將之fetch到B標（CICD）分支上。
最後再push.
蛇足
B標的缺點：
B標分支的好處明顯，它像一個衛士保護着官方分支。髒活累活它幹，它永不後退。
但是如果開發者人數多，對同一個文件的修改，可能發生衝突。這是git本身的缺陷所致。倒如，前段時間我在開發中，數次被打回來，就是因爲我改的文件，別人也改了，例如yocto的白名單的文件，許多同事都要改。一般GK會將這些相關的修改都給一個人，但當時任務多，兩人同時處理，就一再被打回來。當然，有一些也是我忘記fetch所致。
還有更嚴重的是，兩個代碼雖然可以歸併，但編來的二進制文件因爲相互影響而不能通過測試。
這些都裏需要考慮的。但不能因爲這些小毛病，改變基本法則。
最重要的是：B標分支不能回退，開發人員，也要清楚這一點，並且服從。
不能回退的原因是，CICD過程需要時間，在這個過程中，其它開發都可以也會將自己的修改提交CICD分支，如果前面的人失敗，revert，後來的人，即使沒有錯，也會跟着回退。讀過我之前提到的系統思想，大家會明白，自然界沒有這樣的系統。系統是殘酷的，沒有後悔藥，後退也是前進中的後退。速度是最重要的。系統的服務對象不是開發者，是外界，是用戶，是競爭對手，是儘可能佔據生物鏈的外部資源。
所以，這裏雖然是多說的，但還是很必要。許多人不瞭解B標的概念，正是因爲事事想着要後退。
這是我任版本經理（兼升級經理）時，最常向各團隊解釋的話。另一個我天天強調的就是絕不允許拉第二個B分支——那是我的權力。
<完>
