在開發人員確認即將要發Pull Request之前，開發人員應該要先準備好Release note，我們就拿昨天那份來做為開場。
我們決定要進行版本發布，因此我們敘明了：
版號：1.0.0
填寫日：2023.10.15
預計發布時間：2023.10.15的營業時間
發布內容：#74 以及#75 的需求，以及#76的Bug修復。
需求單位通知：這裡我們mention了兩位需求單位人員。
測試內容：說明Test Plan的測試情形，提供相關連結以及Test Plan name，並且敘明了需求單位並未使用Test Plan，而是以傳統的方式提供文件進行。
好，再來，就是要發動Pull Request了。
在這裡，開發這準備開立一張Pull Request 的需求，併入的位置為main，也就是營運環境。為了併入營運環境，我們準備了release note 的資訊，準備給審核人員確認相關資訊。
與此同時，因為Pull Request已經取號，因此記得回到Release Note 新增這個號碼。
AP Leader決定對這張要併入main 的Pull Request 進行審查，他注意到需要經過他或是其他Leader 的審核才可以通過，他也看到這裡對這張Pull Request 有提供了一個Release Note 可以直接連結進行審閱的動作。同時他也注意到這個Pull Request 有一個Tag，為1.0.0。
因此，這個時候AP Leader 就可以確認各項目已經完成了開發，並且在Release Note確認版號是否相符，相關測試是否完成，是否已經通知需求單位準備發布以及確認要放到營運環境的時間是否可行。
好，就在AP Leader 按下許可後，開發人員就可以進行merge，並完成這次併入main的目的。
再來交付到營運環境的pipeline就會被正式驅動。
Pipeline 正式被驅動之後，由於我們在存取environment Production 有設定需要經過AP Leader 以及OP Group的允許後，才可以正式被佈署到營運環境，因此我們會看到上圖有一條Pipeline 在Pending的狀態。
點擊進去Pipeline執行細節，會發現到要發布到營運環境的ProdCD這個Stage，需要有人進行Review 以及放行的動作，讓我們按下右邊那顆藍色Review按鈕。
會看到關於AP Leader 以及OP group需要給Comment的訊息，我在這裡輸入了 營運環境過版，版本號1.0.0。 以及提供了這次的Release note 的url，然後按下Approve的按鈕。
好，再來切換成OP Group的腳色。
營運單位的人員，同樣的進入到了pipeline，點擊進入等待批准的Pipeline，也會發現到有一個Approval在等待許可，當他進入細節後，會注意到AP Leader 有下了一些comment，提供了Release note的超連結資訊讓他可以直觀的看到。
這種做法可以讓營運人員在需要確認其他相關資訊時，可以方便的不用去查找，直接透過超連結就可以進行。
那當然，如果AP Leader 沒有提供這項資訊，還是可以從Pipeline的相關Link去找到相關的資訊，如下：
先點選source code的repo，然後點到那一個version。
點選上面紅色圈起來的Details 頁籤，也可以看到所有的敘述細節，那也由於之前我們有將Release note資訊放在Pull Request 的敘述中，所以這裡也是可以找到相關的資訊的。
好，再來就是按下Approve，接下來就是CD的自動化流程讓他進行佈署的動作。
到此，一次營運環境的交付就完成了。
上述的這些做法，我們透過了Release note 的詳細敘述，讓營運單位的成員也可以容易的找到這次要放行的版本資訊，AP Leader也在Pull request 的階段，透過 Release note的敘述，可以直觀的看到所有應該要確認的相關訊息。
那當然，交付過程並不是僵化的，我們可以隨著各方的需求，在去探索是否有更棒的方式，讓大家可以在交付到營運環境的這件事情上，可以更一目瞭然的進行。
回頭看了這三十天的鐵人賽文章，我本來以為我前面就寫很多了，結果反而專案管理的部分寫得少少的，後面就反而內容越堆越多。導致回頭看前十天的文章感覺內容有點不夠充實，真是有點慚愧。
但是其實這系列文很大的目的其實是在強迫自己，把心中所想的所設計的一切使用方式以及流程，用文章的方式逼自己說明清楚，同時也藉由寫文章的過程進行了一大堆實驗，以釐清未來夥伴們應該要怎麼樣進行下去。
這系列文其實技術成份不算太高，會看很多都是在說明工具探索後，建議使用的方式。反而比較像是一系列在Azure DevOps 上面如何讓一個大家都可以進行協作的一個流程設計，目的就是希望讓大家可以完成任務，而寫出了或許屬於我們的最佳實踐。
流程改造是困難的，要一次大規模的直接轉變，在我們的經驗是比較不容易的。
所以從一年前的Git Lab community 地端版本，讓開發者體驗開發協作以及工作管理。到Azure DevOps Server 的教育訓練以及地端實驗環境的建置，讓使用者也進入到專案管理階段。最後到今年的Azure DevOps Service的開通，讓外包廠商也進入共同協作與交付。
其實筆者是認為需要時間的演化，以及一種佈道者的傻勁跟大家不斷的一起變強，才有機會慢慢往前邁進。
筆者非常感謝上一階主管的支持，團隊夥伴的配合以及所有協助過我在這件事情上的人。畢竟流程改造是很辛苦，那也希望針對現有痛點的一些處理，可以讓團隊獲得一些甜美的成果，讓大家在軟體開發交付上可以更為順利。
最後，未來我還是會記錄一些團隊在使用的過程中，遇到的一些問題，以及對應使用的解決方案，來分享給大家。
這次的任務完成了，未來還有更多的任務。持續整合，持續交付，讓我們持續改善。
iThome鐵人賽
看影片追技術