Scrum 中的持續整合 vs 持續交付 vs 持續部署

常見使用的術語——「持續整合」、「持續交付」和「持續部署」——被視為敏捷軟體開發這些實踐共享「持續」這個前綴,表示並支援逐步整合(可交付的軟體)以及結果的同時部署,避免了傳統順序式開發中通常會出現的延遲。在現代敏捷環境中,這些術語代表透過管道交付已完成的增量,允許自動部署作為升級。
持續交付的核心原則是在短週期內逐步交付可運作的軟體。換句話說,持續交付是一種短週期的實作方式,其中程式碼會頻繁地開發、建置、提交、自動測試並部署。
Continuous Delivery
持續交付
注意:
它並不需要短的發行週期——僅需具備在任何時刻都能允許新程式碼提交的能力。如此一來,開發人員可以每天多次更新產品,持續為使用者提供價值。這透過高水準的測試與部署自動化來實現。

Scrum 中的持續交付

Scrum,固定長度的Sprints為 1 至 4 週,以測試、示範、Sprint Review,最終簽核與發行結束。現在,我們希望更頻繁地發行——持續交付。
持續整合指的是要求開發人員每天多次將程式碼整合至中央儲存庫的軟體開發實務。除了並行且自動化的更新外,透過驗證不同的提交時間,也能輕易地偵測問題。
持續交付能以可持續的方式,安全且快速地將各種變更(包括新功能、設定變更、錯誤修復與實驗)交付至生產環境或最終使用者。
持續部署進一步延伸持續整合的方法,透過縮短編碼與部署之間的時間間隔。
Continuous Delivery in Scrum
Scrum 中的持續交付

持續交付的好處

人們常認為更頻繁地發行軟體意味著接受系統穩定性和可靠性較低。然而,許多研究顯示並非如此。事實上,一次只發行一個功能,能顯著降低每次部署的風險。你的團隊能更快地將功能交付給客戶,從而獲得更快的回饋。持續交付管道為團隊、企業和使用者帶來許多好處:
  • 縮短上市時間
  • 降低成本
  • 更快的回饋
  • 更滿意的客戶
  • 降低風險的發行
根據2014年的調查Xebia實驗室調查報告,持續交付領先,敏捷緊隨其後。根據下圖所示,2014年有36.4%的受訪者將DevOps列為關鍵計畫。
Software Project Initiative Application (2014)
軟體專案計畫應用(2014年)

總結

如果這聽起來好得不像真的,請記住:持續交付並非魔法。軟體發行需要極大的紀律。在Scrum中,透過更頻繁地發布較小的變更,持續交付實現每日持續改進,幫助所有人適應穩定且可預測的節奏,並為應對變動留出空間。最重要的是,成功的發行成為共同的成功——所有人都可以一起慶祝的事。

Leave a Reply