這一篇要開始進入主題了，首先讓我們先看看下面的這一張圖吧！
這張圖是我目前在公司內規劃並且實作的流程，雖然有些東西還沒有完全實作完，但是將會以這張圖為基礎進行後續的施工與改善，主要有三個部份，分別是和Source code相關的Branch分支部份、持續整合CI的Build Pipeline部份、持續佈署/交付CD的Release Pipeline部份。
Git Branch
這部份我們的規劃是有兩個常駐的Branch，分別是Develop、Release。
這兩個Branch都不允許開發者直接Commit檔案進來，任何要異動這兩個Branch的動作都必須透過Pull Request(PR)的方式來更新。所以從這兩個Branch延伸出來的就是Feature和Hotfix這兩個類型的Branch，一個是平時開發建立的Feature，我們通常會以「Features/XXX」來命名，而Hotfix則是已上線的版本需要緊急更新的時候從Release分支建立出來的Branch。
一般來說，開發人員只需要從Develop分支建立他的子分支，完成開發的檔案之後透過建立PR的方式把子分支合併回去Develop分支，當Develop分支有異動的時候就會觸發CI的Build Pipeline，接著到CD的Release Pipeline。然後，有個特別的地方是，Develop合併到Release也是透過PR，但是並不是由開發人員來建立PR，而是在CD的Release Pipeline完成的時候由系統自動完成。
也就是說，從Develop、Release建立出來的子分支建立PR要合併回Develop、Release的PR是由人為觸發(可能要解衝突)，但是從Develop要合併到Release的PR則是由Release Pipeline裡面設計的動作來完成。
當然，如果是Hotfix分支，緊急修正上版是PR合併到Release，之後為了與開發線一致，也需要再透過PR合併回去Develop分支。
Build Pipeline
上圖在Build Pipeline的部份看起來雖然是三個，但是實際上應該是有四個不同的Pipeline，分別是
- Develop PR
- Develop CI
- Hotfix PR
- Hotfix CI
後續的鐵人賽文章只會針對Develop分支的兩個Pipeline說明，Hotfix的部份並不在目前的規劃中。
PR Pipeline的部份會在PR被建立的時候執行，所以它主要是用來做一些合併之前的檢查、分析之類的事情，像是程式碼品質分析、弱點掃描、單元測試等等的前置作業，當這些關卡都完成之後才會放行，讓子分支的內容合併回Develop或Release分支。
不過在後續的鐵人賽文章關於PR Pipeline的部份並不會有實際上的內容，我們只會透過Script輸出一些文字內容來意思一下代表它執行過了，重點將會放在Merge之後觸發CI的Build Pipeline內容的設計(就是Develop CI這個Pipeline的內容)。
在Develop CI這個Pipeline中，我們會把.Net的程式建置之後放到Pipeline的Artifacts空間(成品庫)，接著再利用它來建立Docker Image，利用這個建立出來的Image來佈署Dev、Stage、Production這三個環境。(Dev環境在Build Pipeline完成，Stage、Production在Release Pipeline完成)
Release Pipeline
Release Pipeline的部份會負責佈署兩個環境，分別是Stage和Production。圖中還有一個「QA」的節點是虛線的部份，是因為我們公司目前的QA這部份還不是很明確，也沒有專門的人員在負責這一塊(現階段由PM/PO手動驗)，所以當初在討論的時候原本主管是說先拿掉，但是最後我說還是先改為虛線保留下來，所以才會留在圖上。
如同Build Pipeline的部份有分為Develop CI和Hotfix CI這兩個Pipeline，Release Pipeline的部份也有兩個，分別是Develop CD和Hotfix CD，從圖上來看，上半部的就是Develop CD，下半部的則是Hotfix CD(沒看到QA的部份就是後續在畫的時候直接先省略掉了，並不是不需要，而是未來再補上去)。
在佈署到Stage的這部份會利用前面在Develop CI中建置的Docker Image加上Stage環境專用的環境變數來達成Build一次的Image佈署在不同的環境，接著同樣再利用Develop CI中Build source code階段取得的Git commit sha記錄來Tag，格式為stage-日期-CD編號。
佈署到Production的部份和Stage差不多，但是多了利用Git commit sha來建立暫時性的分支，然後建立PR從這個暫時性的分支合併到Release分支(併完刪除)，最後再進行Tag的動作，格式則為prod-日期-CD編號。
可以發現在Release Pipeline的這個部份都是負責佈署環境的工作，所以不管是在Stage或Production的佈署動作真正開始執行之前都設計了需要按下Approve按鈕才能夠放行開始動作，這部份在圖上是沒有畫出來呈現的。
也就是說，在前面的CI段(Build Pipeline)是不需要Approve的動作(未來或許會在PR的部份加上)，在後面的CD段(Release Pipeline)則是需要人為介入按下Approve的動作，所以Dev環境的佈署就放在CI段，和Stage、Production兩個環境是分開的。
這裡最後會有Tag source code的動作，是希望能夠透過Tags來查看哪些commit在哪個日期已經被佈署到Stage或Production環境，並不一定需要，主要還是看公司在這部份的規劃策略。
結語
因為公司內會有不同的開發團隊負責不同的系統開發，所以當初在討論這部份的規劃設計時是希望開發人員能夠最簡單理解與上手，不同的團隊與系統都是使用這一個流程規範，開發人員只要用Git管理程式碼，知道從哪裡建立PR，後續就沒他們的事了。
這份流程規劃可以用在單一的開發團隊，也可以用在多個不同的開發團隊，所以後續的文章也會分兩部份，前半部主要會以去年文章教的方式在同一個Azure DevOps專案依照這個流程建立出CI/CD Pipeline。後半部則會再以同樣的流程但是不同的做法來實現，也就是真正進階的做法，會先建立一個共用的Azure DevOps專案，然後再建立不同的Azure DevOps專案，每一個專案都是代表一個不同的開發團隊與系統，利用YAML範本在這些不同的專案中共用範本的設計來達到一致性的Pipeline規劃，要修改調整Pipeline內容的時候儘可能不需要每一個專案都重新修改Pipeline。