每個開發團隊或是產品都有對於開發跟自動化的策略不盡相同，但不變的是開發週期會不斷地循環。

專注在開發的 Android 工程師不斷地循環，先示意前一天我們討論一般常見的開發流程是：

1. 需求開發 > (2. 檢視程式碼) > 3. 發佈測試版本 > 4. 修正問題 > 5. 發佈正式版本 > 6. 線上維運

若加入 CI/CD 流程之後，會在 2. 檢視程式碼、3. 發佈測試版本，以及 5. 發佈正式版本有所不同。

• 程式碼掃描：異動的程式碼分支推回遠端之後，開始進行靜態程式碼掃描及 Unit Test 測試或 UI Testnig 確保在提交 Pull Request 之前，確保程式碼品質
• 檢視程式碼：在程式碼掃碼通過驗證或掃描之後，才由人工的方式進行驗證。減少人工所查看的成本，及隱藏的問題們。
• 發佈測試版本：以開發團隊制定好的觸發腳本規則進行發版，不需再花費工程師本機的資源，發佈給需要的團隊成員進行驗證。
• 發佈正式版本：在驗證測試版本無誤之，可依時間或是版本號，直接上傳至 Google Play 進行送審。不需由工程師進行手動操作，降低操作行為的不確定性。

總合先前的開發流程之後，加入 CI/CD 會變成：

1. 需求開發 > 2. 程式碼掃描 > (3. 檢視程式碼) > 4. 發佈測試版本 > 5. 修正問題 > 6. 發佈正式版本 > 7. 線上維運

可能大家在想加入 CI/CD 怎麼流程變長了，那是否真的會減少時間呢？舉發佈測試版本來說，Android 進行包版需要花 3 分鐘、找出打包完的檔案 30 秒，接著把打包完的檔案花 3 分鐘的時間上傳至 Firebase App Distribution。如果這些事情全部放在自動化流程當中，首先工程師自己就可以多 6 分鐘的時間，可以專注在當下的程式碼當中，而人工找出檔案這件事，當指定在流程當中，不用擔心人工會上傳錯誤的檔案，減少錯誤率。

6 分鐘，說多不多說少不少。以我自己的團隊來說，當發佈測試版本全面改成自動化之後，對工程師最大的幫助就是完全不用等待每個包版步驟，尤其是時間很久，想說去做其他的事情，回到發版當下有些時候也忘了做到哪一個步驟了。當時我們有粗略估計算，做這件事情帶來的成效是每個月都可以讓工程師還有一個工作天的時間。

不要小看時間的積沙成塔啊。