為了讓它更加明確，讓我們看看當一個具體的變更傳到系統時，將會發生什么事。舉個例子：

開發團隊接到任務，要給企業的系統做一個變更。這個變更的主要內容是給鑒權系統增加一個新角色。這個看似簡單的任務其實沒那么容易，因為這個變更將會影響許多其他不同的系統。

為了更加順利地開發，大家決定將這個變更拆分成幾個小變更，這樣它們就可以被以回歸測試為主的自動化測試分開驗證。

開發人員在自己的電腦上開發并且在本地盡力測試了第一個變更——新增角色。

為了真正地了解它是否可用，開發人員需要他／女也本地環境以外的系統權限。在這里指的是一個里面有用戶和角色等信息的LDAP服務器。

如果使用測試驅動開發，在寫實際代碼之前會先編寫一個通不過的測試。在這個測試寫完之后，才編寫能讓這個測試通過的新代碼。

開發人員將代碼提交到企業內部的Git版本控制系統上。

構建服務器獲取到了這個變更并初始化構建流程。單元測試之后，這個變更被認為可以被發布到Nexus的二進制庫里。

配置管理系統Puppet發現鑒權組件有了一個新的版本。由于集成測試服務器被配置為總是使用最新的版本，于是Puppet勇往直前安裝了最新的組件。

新組件的安裝觸發了自動化回歸測試。在這些測試成功結束之后，質量保證團隊就開始做人工測試。

質量保證團隊給這個變更蓋上“已通過”的章。變更轉向預發布服務器，在這里開始了最后的驗收測試。

當驗收測試完成后，預發布服務器被切換成了生產環境，而生產環境轉變成了新的預發布環境。企業的負載均衡服務器管理著最后的這一步。

這個流程按需一遍遍地重復著。就像你看到的那樣，有一大堆的事情呢。