在 DevOps 的發展趨勢中,將新功能儘快自動交付給使用者是其中重要的一環。但觀看相關的文章,會看到幾個好像相關但應該又有點不同概念的名詞:「持續整合(continuous integration)」、「持續部署(continuous deployment)」、與「持續交付(continuous delivery)」, 到底他們之間有什麼差異?山姆鍋也來分享一下自己的想法。

按照精實生產 (Lean Production) 精神,新開發出來的軟體特性 (feature) 在交付到最終使用者手中之前所花的時間都算是一種「浪費」,而消除浪費是精實生產的重要指導方針之一。本文所提到的「持續整合」、「持續部署」與「持續交付」都是為了要消除這樣的浪費而存在,但它們之間卻有存在一些差異,底下就針對這些名詞,提供山姆鍋自己的定義。

持續整合(continuous integration)

「持續整合」目的在儘快讓新功能的程式碼整合到現存的基礎程式庫 (codebase) 中來進行測試。如此,才能儘快找出整合上未預想到問題以及解決衝突的程式碼 (conflict codes)。有團隊開發經驗的人應該會同意:整合不同人的程式碼的困難度跟要整合的程式碼多少成級數正比。也就是說:越將整合的時間點往後拖,造成整合難度與失敗的機率越高。「持續整合」通常會涵蓋單元測試(unit tests) 與煙霧測試 (smoke tests),可以儘快找出回歸錯誤(regression error) 的發生。因此,就算是只有一個人在開發,「持續整合」仍有其價值。

持續部署(continous deployment)

不管軟體專案大小,一定會有部署軟體的需要,不管是為了測試、驗收或上線。部署軟體會根據部署環境或多或少有些差別,「持續部署」的目的就是要讓軟體可以快速自動部署到不同的環境,至於有多少環境需要部署則會根據不同公司的持續交付管線 (pipeline) 的設計而定,常見的有:「整合測試環境(Integration Tests Environment)」、「測試環境(QA Environment)」、「用戶驗收測試環境(UAT Environment)」、「 上架環境(Pre-production/Staging Environment)」、以及「生產環境(Production Environment)」。

為了確保部署軟體的功能一致,「持續部署」必須採用同一個包裝好的套件 (package),不管是 Jar, DEB, RPM 或者其他形式。除了一方面可以簡化組態管理(configuration management) 外,一方面也減少部署所需的時間。另一個達到「持續部署」的重要手段是要針對軟體可以客制化的功能,將其組態 / 設定外部化 (configuraiton externalization),簡單點講:就是不要將設定(settings) 寫死 (hard-coded) 在程式碼裡面。

持續交付(continous delivery)

「持續交付」是將新的特性儘快交付到最終使用者 (end-user) 的手中。也就是說:最終使用者可以真正享受到該新特性所帶來的價值(或者折磨 :-))。所以說,「持續交付」才是最終想要達到的目標,「持續整合」跟「持續部署」只是中間必須的過程,但三者缺一不可。沒有「持續部署」的機制,「持續交付」便不可能實現; 而「持續整合」是開發團隊確保軟體品質在「持續部署」的前提下可以達到要求的必要手段。

小結

達到持續交付的目標是山姆鍋在軟體開發上想要完成的挑戰之一,要挑戰自然要瞭解目標是什麼。藉由名詞概念的說明,至少在往後的文章中,可以理解山姆鍋對「持續整合」、「持續部署」與「持續交付」的定義,進而減少誤解的發生。雖然這三者有所差異,但是都同樣要求「持續」,而要達到「持續」的目的,「自動化」可說是理所當然的手段。因此,可以說:自動化程度的高低與持續交付的能力息息相關。