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

推動軟件交付前行的 IT 人

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

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

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

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

不過在深入回答這兩個問題之前，不妨先看看我們在現(xiàn)實中究竟有哪些不恰當?shù)淖龇?#xff0c;從而又遇到了怎樣的交付問題。

軟件交付中的問題

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

懸于開發(fā)與運維團隊頭上的風(fēng)險之劍

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

而在實際的交付過程中，還有許許多多的交付行為也帶來了風(fēng)險，接下來讓我們來一一列舉一些常見的不恰當?shù)慕桓缎袨?#xff0c;具體看看它們帶來了怎樣的問題。

1.?手工部署軟件

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

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

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

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

2.?開發(fā)完成之后才向類生產(chǎn)環(huán)境部署

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

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

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

再比如，直到應(yīng)用程序部署到了試運行環(huán)境才發(fā)現(xiàn)新的缺陷，但是常常沒有時間修復(fù)所有問題。

此外開發(fā)團隊和真正執(zhí)行部署任務(wù)的人員之間的協(xié)作非常少，而且由于部署中問題之多，開發(fā)團隊與部署團隊之間的協(xié)作關(guān)系也受到了挑戰(zhàn)。

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

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

3.?生產(chǎn)環(huán)境的手工配置管理

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

其中的問題同樣出現(xiàn)在手工管理，太多的配置細節(jié)可能出錯，太多的修改未被記錄。而我們希望完全掌握生產(chǎn)環(huán)境中的任何配置信息，而且能夠重復(fù)地創(chuàng)建開發(fā)的應(yīng)用程序所依賴的每個基礎(chǔ)設(shè)施。

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。