許多年來，一代又一代的 IT 人像西西弗斯一樣，孜孜不倦地追求著一個目標——用最快的速度將質量最好的軟件交付給用戶。極為幸運的是，我們并沒有遭遇西西弗斯式的悲劇，一次又一次在巨石就快到達山頂時前功盡棄，而是在這場看似無止境的攀爬中，到達了一個又一個令人興奮的里程碑，取得了一個又一個卓有成效的成果，比如敏捷開發、DevOps，以及本文將要介紹的 CI/CD。

推動軟件交付前行的 IT 人

敏捷開發、DevOps、CI/CD 這三塊里程碑從不同的角度通力合作，將軟件交付的效率與質量推到了一個新的高度。如果說敏捷開發關注加速軟件交付的開發流程，DevOps 關注的是開發與運維團隊緊密協作的文化，那么 CI/CD 則關注如何實現頻繁交付的自動化流水線工具。

三大里程碑：敏捷、CI/CD 、DevOps

敏捷與 DevOps 的概念我們在之前的文章中都已經有所了解，那么 CI/CD 又是什么？它是如何提高我們的交付能力的呢？

簡單來說 CI（Continuous Intergration ）—— 持續集成，指開發人員能夠頻繁將代碼集成到公共代碼倉庫的主分支中。而 CD（Continuous Deployment）——持續部署，以持續集成過程為其理論基石，其核心是部署一條流水線，實現應用程序從構建、部署、測試到發布這整個過程的自動化，從而提高軟件的交付能力。

不過在深入回答這兩個問題之前，不妨先看看我們在現實中究竟有哪些不恰當的做法，從而又遇到了怎樣的交付問題。

軟件交付中的問題

在以往的軟件交付中，風險似乎成為了永恒的主題，成為了一把懸在開發團隊與運維團隊頭上的利劍。

懸于開發與運維團隊頭上的風險之劍

這里風險一方面是因為許多的軟件交付需要太多的手工操作。正是因為手工操作，在這個過程中有太多步驟可能出錯。假如其中有一步沒有完美地執行，應用程序就無法正確地運行。一旦發生這種情況，我們很難一下子說清楚哪里出了錯，或到底是哪一步出了錯。

而在實際的交付過程中，還有許許多多的交付行為也帶來了風險，接下來讓我們來一一列舉一些常見的不恰當的交付行為，具體看看它們帶來了怎樣的問題。

1.?手工部署軟件

一種常見的交付方式就是手工部署軟件。很多團隊都使用手工的方式發布軟件，也就是說部署應用程序所需的步驟是獨立的原子性操作，由某個人或某個小組來分別執行。

但是由于現在的大多數應用程序，無論規模大小，其部署過程都比較復雜，而且包含很多非常靈活的部分。每個步驟里都有一些需要人為判斷的事情，因此很容易發生人為錯誤。即便不是這樣，這些步驟的執行順序和時機的不同也會導致結果的差異性，而這種差異性很可能給我們帶來不良后果。

具體而言，手工部署軟件的做法以及遇到的問題，往往是像下面列舉的這樣：

• 有一份非常詳盡的文檔，該文檔描述了執行步驟及每個步驟中易出錯的地方。
• 手工測試來確認該應用程序是否運行正確。
• 在發布當天開發團隊頻繁地接到電話，客戶要求解釋部署為何會出錯。
• 在發布時，常常會修正一些在發布過程中發現的問題。
• 如果是集群環境部署，常常發現在集群中各環境的配置都不相同，比如應用服務器的連接池設置不同或文件系統有不同的目錄結構等。
• 發布過程需要較長的時間（超過幾分鐘）。
• 發布結果不可預測，常常不得不回滾或遇到不可預見的問題。
• 發布后凌晨兩點還睡眼惺忪地坐在顯示器前，絞盡腦汁想著怎么讓剛剛部署。

2.?開發完成之后才向類生產環境部署

另一種常見的交付方式就是等到代碼開發完畢才部署到類生產環境（比如試運行環境），運維人員只有在產品被發布到生產環境時才第一次見到這個軟件。

這樣做的后果是部署工作中的很多步驟根本沒有在試運行環境上測試過，所以常常遇到問題。

比如直到最后部署才發現系統設計中存在對生產環境的錯誤假設。例如，部署的某個應用軟件是用文件系統做數據緩存的。這在開發環境中是沒有什么問題的，但在集群環境中可能就不行了。解決這類問題可能要花很長時間，而且在問題解決之前，根本無法完成應用程序的部署。

再比如，直到應用程序部署到了試運行環境才發現新的缺陷，但是常常沒有時間修復所有問題。

此外開發團隊和真正執行部署任務的人員之間的協作非常少，而且由于部署中問題之多，開發團隊與部署團隊之間的協作關系也受到了挑戰。

此外，當我們開發完成之后才向類生產環境部署時，下列一些事情會進一步惡化軟件的交付：

• 假如一個應用程序是全新開發的，那么第一次將它部署到試運行環境時，可能會非常棘手。
• 假如發布周期越長，開發團隊在部署前作出錯誤假設的時間就越長，修復這些問題的時間也就越長。
• 假如交付過程被劃分到開發、運維、測試等部門的那些大型組織中，各部門之間的協作成本可能會非常高。此時為了完成某個部署任務（更糟糕的情況是，為了解決部署過程中出現的問題），開發人員、測試人員和運維人員總是高舉著問題單（不斷地互發電子郵件）。
• 假如開發環境與生產環境差異性很大，開發過程中所做的那些假設與現實之間的差距也會很大。
• 如果應用程序是由用戶自行安裝的（你可能沒有太多權限來對用戶的環境進行操作），或者其中的某些組件不在企業控制范圍之內，此時可能需要很多額外的測試工作。

3.?生產環境的手工配置管理

在配置管理方面同樣也有著一個手工管理模式。很多組織通過專門的運維團隊來手工管理生產環境的配置。比如說修改數據庫的連接配置或者增加應用服務器線程池中的線程數時，那么運維團隊會登錄到生產服務器上進行手工修改。

其中的問題同樣出現在手工管理，太多的配置細節可能出錯，太多的修改未被記錄。而我們希望完全掌握生產環境中的任何配置信息，而且能夠重復地創建開發的應用程序所依賴的每個基礎設施。

具體而言，手工配置管理的做法以及遇到的問題，往往是像下面列舉的這樣：

• 多次部署到試運行環境都非常成功，但當部署到生產環境時就失敗。
• 集群中各節點的行為有所不同。例如，與其他節點相比，某個節點所承擔的負載少一些，或者處理請求的時間花得多一些。
• 運維團隊需要較長時間為每次發布準備環境。
• 系統無法回滾到之前部署的某個配置，這些配置包括操作系統、應用服務器、關系型數據庫管理系統、Web服務器或其他基礎設施設置。
• 不知道從什么時候起，集群中的某些服務器所用的操作系統、第三方基礎設施、依賴庫的版本或補丁級別就不同了。
• 直接改生產環境上的配置來改變系統配置。

以上便是在軟件交付中常見的一些問題，存在更好的解決方法嗎？CI/CD 給出了肯定的答案，那就是構建一條自動化的部署流水線，實現頻繁且自動化地發布軟件。本文是 CI/CD 系列的第一篇，深入了解具體 CI/CD 是什么、如何做的，請聽下回分解。

總結

以上是生活随笔為你收集整理的【云原生】什么是 CI/CD ？| 软件交付中常见的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。