16:38 Bob: 我改了發版的腳本，把發送到 channel 的內容再加上最新的 commit message，可是我現看得的還是原本的
16:38 Carol: 你改的腳本是哪一個？
16:40 Bob: jenkinsfile_ci
16:44 Alice: 是 jenkinsfile_release 才是現在發版用的
16:46 Bob: 好……那我改在 jenkinsfile_release 檔案中 ?

故事當中有看到專案當中有兩個腳本，而兩個腳本在做的事情跟流程類似，自然而然想要異動腳本的時候，就會發生這種非預期的情況發生。每個開發團隊來說，也有自己自訂義的腳本們，但當腳本數過多的時候，在維護上也會難度會越來越高。

去年在處理 AAB 包版，因為專案當中 product flavor 切得維度很多，所以光是執行的 shell 檔，還對對應不同環境還有對應的 Jenkinsfile。後端有三個環境，就有三個 Jenkinsfile。然後各自的環境還有對應的 Shell 檔案，某個 product flavor 對應的到的版本，再加上我們還保留 AAB 和 APK 兩種檔案格式。但對工程師來說不一樣的地方，其實只有 product flavor 而已。下方先列出，當時三種環境的對應狀況：

整理下來之後，應該有看到幾個共同的內容，以 Job 來說，其實可以整合成兩種：正式機佈署和測試環境。

再來，雖然還是分成兩個 Job，其實整個發版來說只是依 product flavor 來決定發版檔案格式的。所以再將之合併之後，就只會有一個 Job 處理不同的 product flavor 的條件去進行發版，所以對後續維護來說，要改發版相關的，就只要關注在 ReleaseApp 這個 Job 就好了。而不用像一開始，有對應的三個環境，我們分別要分開去各別去做處理。