持續整合認證

持續整合 是軟體開發中一種廣為人知的技術。在許多研討會中，開發人員會分享他們如何使用持續整合，而持續整合工具在多數開發組織中也很常見。但我們都知道，任何一個好的技術都需要一個認證計畫，而很幸運地，持續整合認證計畫已經存在。持續整合認證計畫是由持續交付與 DevOps 領域中首屈一指的專家所開發，以其管理速度極快、結果極具洞見而聞名。儘管持續整合認證計畫已經相當成熟，但知名度卻不如預期，因此身為持續整合技術的愛好者，我認為與我的讀者分享這個認證計畫非常重要。你準備好取得持續整合認證了嗎？你將如何面對測驗結果揭露的驚人真相？

到目前為止，我的忠實讀者一定很好奇他們是否誤闖了一篇戲仿文章 [1]，沒錯，我在開頭的預告中開了一個小玩笑。但就像任何一個好笑話一樣，其中都隱藏著重要的真理。Jez Humble 建立了一個非常棒的適當持續整合測驗，而他絕對是 持續交付 領域的領先專家。這也是一個快速測驗，他經常在演講中對聽眾進行測驗。唯一的問題是我從未聽過他將此測驗稱為認證測驗，這只顯示出他缺乏賺錢計畫的遠見。

他通常會先請聽眾舉手表示他們是否執行持續整合，作為認證程序的開場。通常大部分的聽眾都會舉手。

然後他請他們如果團隊中的每個人都承諾並至少每天推送到共享主線（通常是 git 中的共享 master）的話，就舉手。

超過一半的人放下手。

然後他請他們如果每次這樣的提交都會導致自動建置和測試的話，就舉手。剩餘的人中有一半放下手。

最後，他詢問如果建置失敗，通常會在 10 分鐘內恢復正常嗎？[2]

在最後一個問題中，只有少數人舉手。這些人通過了他的認證考試。

這是一組簡單的問題，但它觸及了持續整合的核心。整個想法是沒有人會處理與其他人有顯著差異的程式碼庫。持續整合意味著團隊知道程式碼的當前狀態，我們避免大型風險合併，而且人們可以根據需要進行重構。

一開始這麼多人舉手的原因是普遍認為持續整合意味著針對其功能分支執行一些「持續整合伺服器」。但是持續整合——正如 Kent Beck 最初描述並命名為 極限編程 的一部分——與工具無關。一開始它是一個人工工作流程，而 Jim Shore 提出了極佳的論點，認為它應該是這樣。針對原始碼存放庫執行守護程序進程的想法是後來才出現的，雖然它很有幫助，但只有在每天都有人提交的共享主線上執行時，它才是持續整合。在其他情況下執行這樣的進程，例如在每個 功能分支 上執行，就是 CI 戲院，它貶低了這個名稱[3]，產生了一個無法為您提供讓所有事情都值得付出的好處的工作流程。