傳統的持續內建(ci)系統被設計成作業的流水線。你可以有一個同行評審，然後開始建構作業，然後是單元測試作業，然後是內建測試作業，然後是性能測試作業，諸如此類。
每個作業都是由前一個作業的成功完成事件觸發的，而第一個作業則是由版本控制系統中源代碼檔案的變更事件來觸發的。當然，如果你的目标是多個二進制平台，或者如果你正在建構的是一組元件，以此來測試整個的應用程式，那麼它還會更加的複雜。
那麼如果有任務失敗了會怎樣?jez humble 和 david farley 在持續傳遞中認為，你首先需要遵循這樣的原則："不要在失敗的 build 上送出代碼"。換句話說，不要由于新的送出導緻問題更嚴重。如果你違反了這個原則，你就沒法确認引起錯誤的真正原因。humble 和 farley 建議選擇下面兩種政策之一來處理 build 失敗的情況：
"當 build 失敗是，不要去做别的事情，" 意思是團隊中的所有人都要停下來去修複這個問題。
"時刻準備復原到上一版本。" 復原的政策可以避免打斷整個團隊的工作。
當然，也可以采用混合的政策：在可容忍的時間内嘗試修複，超過時間則進行復原。
還有一種方式可以稍微緩解問題，那就是使用內建分支，隻有內建分支是綠色的(所有測試通過)，才允許進行代碼的合并。這種政策下內建分支還是有同樣的問題，不過 master 分支可以保證總是可用的。
類似的方式适用于小團隊，你可以讓團隊的所有成員都暫停代碼的送出，不過即使是小團隊，ci 處于紅色狀态也有可能會持續比較長的時間。對于這種方式的 ci 實踐，你需要嚴格遵循完善的規定。不過你也可以嘗試一種新的實施 ci 的方式。
新一代的 ci
目前的 ci 是以 ci 伺服器為中心。ci 伺服器負責發現改動并觸發任務。
新一代的 ci 則是以代碼 review 系統為核心，這樣可以保證在改動合并到版本管理系統之前完成相應的操作。
是否加入團隊的代碼 review 的過程，這取決于你。我強烈建議通過代碼 review 來提高代碼的品質，但是這與 ci 系統本身是獨立的。我們需要強調的是，建構和測試這些行為是由代碼 review 系統的新送出來觸發的。當所有測試都通過後，代碼才會被合并到主幹上。如此一來，主幹的代碼總是可以保證是測試通過的，開發人員也可以并行的進行代碼送出。新的 ci 體系可以讓你的自動化變得流暢，因為不再有問題會阻塞流程。
openstack 的工作流程
ci上的新的方法已經在 openstack 項目中得到大規模的實作，一次來管理所有不同的子項目的ci過程。為了使你對它的規模有一個概念，可以看到每天 openstack 都要處理 1000 個送出的更新檔包，7500條送出的有關于gerrit的評論和投票， 催生出16,000 個測試環境，還有250次變更的合并(源代碼)。
為了實作下一代的ci系統，openstack項目使用下面這些元件：
gerrit, 代碼審查和git資源庫管理器。
zuul, git代碼庫控制系統。
jenkins, 持續內建伺服器。
nodepool, 部署在openstack雲上的智能的 jenkins 衍生工具。
這些工具通過使用随機推斷的合并政策來實作在同一個項目上的并行測試。如果同一時間在同一項目之上發生了多次評審，zuul就能夠以随機推斷的方式将它們放到一起來對它們進行測試。例如，加入評審被命名為a、b和c，那麼zuul将會并行的對 a、a+b以及a+b+c進行測試。如果他們都成功了，那麼就已經跟a經過了測試并進行了合并效果是一樣的了，然後b在分支(a)的基礎上經過了測試然後進行了合并，c在a+b的基礎之上也同此理。 這樣當你同一個項目有多個代碼貢獻者時，內建的過程會加速不少。
zuul 還能管理跨多個項目的依賴，允許資源庫間評審的合并。這在git中是個關鍵的東西，因為在git中你的元件存在于不同的git資源庫中。
試一試
對于大的團隊甚至是小的團隊來說，你都可以通過配置前述的元件來使項目受益于這一工作流程。puppet 子產品就能用來輕松的配置這些服務。
另外一種方法就是使用我們自己對這些服務的內建，叫做軟體工廠。你将會獲得下面這些功能特性：
對這些功能做了一個不錯內建的一個 web 菜單。
一個在所有這些服務間輕松進行單點登入的方案，還有在 ldap、github 或者登入面飯(cauth)上的外部認證方案。
一個bug跟蹤系統(redmine).
協作工具：
用于共享輸出或者代碼提取的 paste。
用于協作編輯的 etherpad。
以一種簡單的方式管理從之前版本的更新。
因為軟體工廠是自托管的(我們使用軟體工廠來開發軟體工廠), 你可以在 softwarefactory-project.io 上對它進行了解。
如果你想要測試驅動的軟體工廠，隻要按 softwarefactory-project.io/docs/deploy.html 上的文檔照做就行了。
你可以就使用這一新的方法進行 ci 的收獲同我們保持交流。
本文作者：佚名
來源：51cto