沒有CI/CD合在一起的東西！ - frankel

banq發表於2019-11-26

最近，我意識到一種趨勢已經持續了很長時間：將CI和CD合併為同一個片語：CI/CD。
當營銷人員完成此操作時，這與往常一樣，是流行語和炒作的混合，並大喊“看著我！”。但是，當專業軟體工程師重複此操作時，我開始擔心。而這正是現在正在發生的事情。這篇文章旨在概述我的想法，我可以推薦其他人以消除我認為與CI / CD有關的困惑。

為此，需要一些歷史記錄。最初，CI簡稱為持續整合。儘管過去CI並不是開發專案中的嚴格要求，但是當專案的人員總數升至一位以上水平時，CI是必要的：單個開發人員可以使用檔案系統進行開發，並使用簡單的線上儲存系統來儲存進度，是否自動。但是，只有一個額外的開發人員，一個人就有覆蓋另一個人所做的更改的風險。因此，發明了一種新型軟體：版本控制軟體。但是，這僅解決了覆蓋彼此的原始碼檔案的問題。
來自同一程式碼庫的多個開發人員還有另一個問題。可以引入不會覆蓋任何內容的更改，但是會引入編譯錯誤或更糟的錯誤-原始碼其他部分中的錯誤。例如，想象一下整個程式碼庫中使用的函式。任何人都可以刪除該功能，並防止程式碼被編譯。為防止這種情況，應確保沒有任何變化會產生這種不利的副作用。解決方案是CI，這是一種自動執行過程以確保沒有任何更改會破壞現有程式碼庫的方法。
構成CI流程的確切步驟取決於不同的因素。例如，諸如C或Java之類的編譯語言需要一個編譯步驟。CI流程中可能還有許多其他步驟：
  • 單元測試
  • 整合測試
  • 變異測試
  • 原始碼質量檢查，例如 SonarQube
  • 打包：根據技術堆疊，建立可執行檔案，JAR，ZIP存檔等
  • 將新建軟體包儲存在儲存庫中
  • 等等

CI是一種古老的做法。我認為我從事的前幾個專案都沒有CI，但是在那之後，他們都擁有了。真正的區別在於，隨著時間的流逝，越來越多的步驟（例如上面提到的步驟）逐漸出現。

現在，讓我們談談CD。首先，CD是基於CI構建的：如果沒有CI，就不會有CD。但是，CD本身可以指兩個相關但不同的事物：
1. 持續交付：
持續交付是準備要在CI鏈末尾部署的程式包的過程。這是在常規配置鏈中發生還是由其他工具觸發都無關緊要。重要的是，最終生產部署應該一鍵（或一個命令列）就可以了，這很容易。部署的最後一步仍然是商人的決定。
連續交付可以但不必包括部署到生產環境以外的其他環境，例如暫存。但是，一般來說，這樣做是出於測試目的：可能是為了整合測試，但更可能是為了效能測試和安全性測試，條件是登臺是生產的確切映象。

2.持續部署：
持續部署比持續交付進一步邁出了一步。那時，沒有涉及“手動”決策。提交會觸發整個流水線鏈，而鏈的最後一個里程碑是在生產中部署增值產品。由於在生產中引入錯誤的風險很高，因此需要採取一些安全措施：除了進行各種不同型別的測試外，部署本身通常還涉及一定程度的canary金絲雀釋出，因此新版本並非所有人都可以使用。使用者，但只佔其中的一小部分。監控可確保一切順利，這時從此新版本中受益的使用者百分比將逐漸增加，直到達到100％。

結論
持續整合，持續交付和持續部署密切相關：它們都依賴於自動化，而後者則依賴於前者。但是，相似之處到此為止。
一方面，我建議您不要為沒有CI的公司工作。如今，沒有充分的理由不使用CI。缺少它對於軟體工程文化是一個非常糟糕的訊號。
另一方面，截至目前，沒有多少公司實施持續部署。而且我不確定它會在不久的將來改變。持續部署需要在許多不同領域中具有高度的成熟度：自動化流程的成熟度，測試流程的成熟度，技術人員與業務人員之間信任的成熟度等。

我希望到現在為止，您已經確信CI和CD不應混為一談，並且可以隨意使用。

相關文章