完整的變更管理

故事

Lala：原來Kong的設定變更也打算走Pull Request，而且設計原則與一般我們應用程式過版不太一樣耶。

Sam：沒錯，原因就如同前面說過的，我們在開發程式碼時，軟體開發生命週期通常會允許我們在不同階段進行驗證，因此同一包程式碼一定會經過至少兩到三個環境驗證。但基礎設施的設定則不太一樣，要將他視為各個不同環境都是一個獨立的個體，用每一個檔案來敘述各不同個體的當下設定展現比較適合。

Aries：Pull Request階段也不太一樣，一般我們開發程式是透過pipeline驗證能不能夠編譯成功，或是進行Unit Test的自動化測試，但這邊則是用特別的工具去驗證格式問題而已。

Sam：IaC基本上是將各種Infrasture的設定檔作為變更標的，這些設定檔與程式碼類型當然不同，沒辦法進行編譯或是Unit Test。通常產品如果有支援IaC，通常會出一些工具提供變更前的格式或是設定檢查。Kong就是使用decK這個工具進行，這個工具的命名其實是decorative 加上 Kong的組合而來，專門用來做IaC支援使用。

Lala：那來變更一次看看，看與我們習慣的變更管理有甚麼不同吧。

變更管理示範

圖24-1 完整的變更管理流程

今天筆者要帶著大家走一次完整的變更管理流程，可以先參考圖24-1。變更管理通常不能夠像Day22那樣，直接變更main，因此要先建立別於main以外的分支，接著透過Pull Request的方式進行變更與審查。

1.根據work item建立建立feature分支並修改需求

work item是Azure DevOps Service中用來記錄與溝通的功能，因為所有的變更都有所本，一定是有需求與討論後，才會進行變更的行為。這系列文不特別說明關於在Azure Board的各項功能，簡單先用一個task來開立希望變更的內容即可。

圖24-2 work item -task

可以看到圖24-2 已經有一個工作單被開出來，接著就是接單做事情了。過往如果是Infrascture的同仁，一定是打開產品GUI或是putty連入，然後開始找按鈕或是下指令進行設定與驗證。IaC的世界則是改變習慣，會打開VSCode開始調整。

筆者使用gitgraph來示範，首先先在main分支上，開啟一個新的分支名為 features/#543(這是筆者工作環境的約定俗成的協議)，並且切換過去，可以參考圖24-3。

圖24-3 建立工作分支 features/#543

接下來為了要符合這次的工作單上所做的描述，直接修改kong.yml以符合需求。

參考：SIT\Kong_declarative\declarative\kong.yml

...上方相同省略...
  keyauth_credentials:
  - key: user2-api-key-2025
- acls:
  - group: FinancalHMAC
  username: customer-user1@financal.com
  custom_id: customer-user1
  hmacauth_credentials:
  - secret: 4MfcLIDVuxfH67gwuANeFiUTineOHHVs
    username: 2025_customer-user1

完成後，將這次要變更的內容進行commit and push，在這邊有一個要注意的是，在協作的過程中，通常為了可追溯性，會盡量將work item與git commit關聯。因此在git message的訊息第一欄最前面，都會用#開頭並帶上work item編號來進行註記，就同圖24-4。接著就是 commit and push。

圖24-4 commit and push

2.建立Pull Request並進行預驗證

圖24-5 建立Pull Request

接下來回到Azure DevOps，關注到Iac_Demo這個repo，應該會看到圖24-5的畫面。系統告知feature/#543剛剛被更新了，請按下Create a pull request。

圖24-6 Pull Request

圖24-6則是建立的頁面，圖片有稍微修飾過。讀者可以想像，如果準備要交付一份變更要提供給其他同事進行確認，那應該要先寫上一些基本的標題與敘述，讓同事知道你想要做的事情。另外如果這次變更只有一個commit標題與內文就會被git commit預設填入，接著直接先按下Create。

圖24-7 check and wait for approve

接下來，就可以在圖24-7看到，當建立一個Pull Request的時候，會自動地去觸發設定好的pipeline，確保檢查有被完成。這時候可以點進去編號1畫起來的部分，確認執行的內容。

圖24-8 pipeline 檢查的內容

圖24-8 可以看出來，檢查很順利的完成了，pipeline透過 deck 檢查了 kong.yml，確認符合規範。

　補充：格式不符合的狀態

圖24-9 檢查失敗

從圖24-9 就可以看出來，如果人員失誤了，pipeline會檢查出來這次的變更有問題，因此 pull request就不能夠被完成。直到該錯誤被修正後，重新檢查確認格式沒有問題才能，才可以完成這次的變更管理。

這種做法可以讓團隊成員在審查期間，不需要僅憑肉眼確認格式是否正確，這與預先進行程式碼的編譯與Unit test作法類似，透過編譯器或是單元測試進行驗證才是科學。

老闆那句：測試的時候，你怎麼沒看出來有問題的那種不科學年代，應該要讓它逝去了。

回到圖24-7，由於設定中還需要有reviewer 按下approve，因此當團隊其他成員收到檢核通知時，可以共同確認這次要變更的內容(圖24-10)，相關的工作項目以及確認自動化檢核已經通過了之後，按下approve的按鈕同意這次的變更。接下來就可以完成合併，發起pull request的成員就可以按下compelete(如果條件尚未滿足，按鈕名稱會是set auto-complete)的按鈕。

圖24-10 確認變更內容

下一個步驟則是，要選擇要併入main的合併模式，可以參考圖24-11，這邊請選擇squash commit(這裡不贅述四種合併模式，如果讀者有興趣，可以參考2023年筆者的 Azure DevOps 系列文-四種合併模式)，這種合併模式很適合主幹式開發(TBD)的協同合作方式。最後，請按下Complete merge，完成這次變更管理的合併審核。

圖24-11 complete merge

3.完成合併並檢查

當按下Complete merge之後，就表示這次要變更的設定內容，已經被併入main分支當中，接著設定好的pipeline就會被觸發執行變更(圖24-12)。

圖24-12 合併觸發pipeline

不過與前次不同的是，這次的變更管理除了直接將設定生效以外，還新增了人工確認的流程。圖24-13可以看到，stage Setting_Kong已經完成了，但停留在Manual Approval的階段，等待人工核可。

圖24-13 流程暫停-等待人工確認

這在變更管理的流程中代表，變更已經完成，需要人工介入確認一些事項。身為kong負責人，首先一定要確認服務是正常運行，畢竟變動基礎設施是一個涉及範圍甚廣事情，因此在這階段可以先透過如Grafana加上Kibana來確認，API的請求是不是還有持續而正常的進入。

圖24-14 人工確認-Resume

如果確定服務正常運行，下一步當然是確認該設定是否正確生效，因此可以考慮通知需求者進場確認。不過通常這時就可以進行下一個stage，可以按下圖24-14中的Resume讓流程完成。

圖24-15 成功完成變更管理

當按下Resume後，在圖24-15可以發現這個流程在前兩個stage已經被完成打勾，而且pipeline最前面也是一個執行完成的綠色勾勾。為何最後一個沒有被執行呢？原因在於整個流程的第三階段，是為了快速還原所設計。

既然是為了快速還原而設計，一定是為了某個變更失敗，才需要採取的還原措施。因此在一切順利的流程中，這個階段當然不會被執行，才是合理的。

補充：還原程序

圖24-16 reject-啟動還原程序

圖24-17 變更管理失敗-還原

這邊補充一下變更管理失敗的還原實際操作，如果確認變更發生了災難，在第二階段按下了reject的那顆按鈕，就會看到第二階段發生了錯誤。這時候就會驅動第三階段的還原程序，開始進行還原(圖24-16)。

另外圖24-17 則是看到，流程中由於第二個階段是錯誤的狀態，因此整個pipeline認為這是一個失敗的執行。

在這樣的設計下，可以直觀的看出來，這次的變更管理行為是失敗的，但有賴於還原，變更並沒有生效。這可以讓設定人員有時間回頭去檢視或調整需求內容。

小結

今天完整的介紹了，在kong的設定上使用了Azure DevOps來進行Iac的完整變更管理流程。這種做法有幾個很顯然的優點：

1. 變更管理的橫向通知與審查： 在Azure DevOps中透過pull request的方式進行變更管理，可以讓團隊成員互相確認變更內容外，也橫向的讓團隊成員知道有要變更這一件事情。這在事故發生當下，讓團隊可以直覺的聯想到有某件事情似乎發生，且可以被追溯非常的重要。不然又要透過感知能力，這也太不科學。
2. 自動化的檢核： 團隊成員用眼睛檢查yaml格式這件事情太不人性了，更不用提除了檢查格式外，還需要符合kong的專屬定義。但在pull request階段就可以自動的檢出並攔下有問題的設定檔，對變更的成功率將大幅提升。
3. 快速的變更與還原機制： 老師傅固然有其厲害的手藝，可以讓任何工作快速且順利的進行。但我們追求的不是不犯錯的完美師傅(就算老師傅手可能也會抖一下)，而是追求不斷可以改進的變更與檢查自動化流程。在持續改善的目標下，最終流程會被鑲入團隊的靈魂中，讓變更自然而順利地發生。

接下來，明天回到Hmac的設定，來說明如何使用不同的認證方式，來共同存取同一個service。相信在這麼優秀的變更管理設計流程下，一定可以順利完成任務。

明天見~