0.19 to 0.29

這部分的跨越可能是面對更複雜的需求時，除了PM 的需求分析能力外，還要引入 Sprint 的概念，這階段 Board 工具換成了 [jira]，並且引入了衝刺的概念，加上功能分支之的執行。一張卡片應該對應一個功能分支，並且在 jira 卡片上是可以追蹤的。另外也需要把 jira 集成到 ChatOps 裡面。

這邊帶上 Sprint 的概念後，差不多也需要 1 個月的時間熟悉，這邊盡可能地要在引入週一的衝刺需求會議與週五的評審會議（以新手 Sprint 來說，我們的經驗是一週 1 個 Sprint 比較不容易走偏）

0.29 to 0.5

本質上就是部署管理、環境管理。

(img)
這階段最重要的是要把 CD 建置完成，其實能力與時間允許的話，可以跟 CI 的階段一起做，這邊都可以主推者來把這些基礎設施弄好，讓你的團隊成員只要專注在需求開發實作上。

這邊的例子會拿雲上的一些應用來當作範例，流程與概念都是不變的，但要根據不同的環境與架構來抽換工具與流程，同時也會建議讓應用容器化，對你的 CD 絕對是幫助的。這個階段會建議把整個系統從後端開始做 CD，因為後端可能來自不同前端的串接與資料處理，通常會是整個系統最核心的部分，也是最容易出錯的部分，所以要儘早把核心部分做好 CD，確認每次交付的軟體都是符合預期的。

以我們的例子來說，我們利用了 GCP 的 Cloud Build 幫我們把後端都建置在 kubernetes 的環境中，對於我們現階段來說是更適合不過了，自建與架設工具是現階段應該盡可能避免的，因為會造成額外的穩定與維護成本。

以我們後端的流程架構就會如下圖，當然個別應用中的開發建置是更複雜的，這時候開發方法論中也不能少，DDD 與 微服務 的設計，可以讓你在 CD 中更好的去交付軟體。
(img)

總結

今天跟大家分析與分享了 0.19 到 0.5 的 DevOps 之路，希望對你有幫助！