編譯自： https://opensource.com/article/18/8/what-cicd

作者： Brent Laster

譯者： pityonline

在軟件開發(fā)中經(jīng)常會提到 持續(xù)集成(Continuous Integration)（CI）和 持續(xù)交付(Continuous Delivery)（CD）這幾個術(shù)語。但它們真正的意思是什么呢？

在談?wù)撥浖_發(fā)時，經(jīng)常會提到 持續(xù)集成(Continuous Integration)（CI）和 持續(xù)交付(Continuous Delivery)（CD）這幾個術(shù)語。但它們真正的意思是什么呢？在本文中，我將解釋這些和相關(guān)術(shù)語背后的含義和意義，例如 持續(xù)測試(Continuous Testing)和 持續(xù)部署(Continuous Deployment)。

概覽

工廠里的裝配線以快速、自動化、可重復(fù)的方式從原材料生產(chǎn)出消費品。同樣，軟件交付管道以快速、自動化和可重復(fù)的方式從源代碼生成發(fā)布版本。如何完成這項工作的總體設(shè)計稱為“持續(xù)交付”（CD）。啟動裝配線的過程稱為“持續(xù)集成”（CI）。確保質(zhì)量的過程稱為“持續(xù)測試”，將最終產(chǎn)品提供給用戶的過程稱為“持續(xù)部署”。一些專家讓這一切簡單、順暢、高效地運行，這些人被稱為 運維開發(fā)(DevOps)踐行者。

“持續(xù)”是什么意思？

“持續(xù)”用于描述遵循我在此提到的許多不同流程實踐。這并不意味著“一直在運行”，而是“隨時可運行”。在軟件開發(fā)領(lǐng)域，它還包括幾個核心概念/最佳實踐。這些是：

• 頻繁發(fā)布：持續(xù)實踐背后的目標(biāo)是能夠頻繁地交付高質(zhì)量的軟件。此處的交付頻率是可變的，可由開發(fā)團(tuán)隊或公司定義。對于某些產(chǎn)品，一季度、一個月、一周或一天交付一次可能已經(jīng)足夠頻繁了。對于另一些來說，一天可能需要多次交付也是可行的。所謂持續(xù)也有“偶爾、按需”的方面。最終目標(biāo)是相同的：在可重復(fù)、可靠的過程中為最終用戶提供高質(zhì)量的軟件更新。通常，這可以通過很少甚至無需用戶的交互或掌握的知識來完成（想想設(shè)備更新）。
• 自動化流程：實現(xiàn)此頻率的關(guān)鍵是用自動化流程來處理軟件生產(chǎn)中的方方面面。這包括構(gòu)建、測試、分析、版本控制，以及在某些情況下的部署。
• 可重復(fù)：如果我們使用的自動化流程在給定相同輸入的情況下始終具有相同的行為，則這個過程應(yīng)該是可重復(fù)的。也就是說，如果我們把某個歷史版本的代碼作為輸入，我們應(yīng)該得到對應(yīng)相同的可交付產(chǎn)出。這也假設(shè)我們有相同版本的外部依賴項（即我們不創(chuàng)建該版本代碼使用的其它交付物）。理想情況下，這也意味著可以對管道中的流程進(jìn)行版本控制和重建（請參閱稍后的 DevOps 討論）。
• 快速迭代：“快速”在這里是個相對術(shù)語，但無論軟件更新/發(fā)布的頻率如何，預(yù)期的持續(xù)過程都會以高效的方式將源代碼轉(zhuǎn)換為交付物。自動化負(fù)責(zé)大部分工作，但自動化處理的過程可能仍然很慢。例如，對于每天需要多次發(fā)布候選版更新的產(chǎn)品來說，一輪 集成測試(integrated testing)下來耗時就要大半天可能就太慢了。

什么是“持續(xù)交付管道”？

將源代碼轉(zhuǎn)換為可發(fā)布產(chǎn)品的多個不同的 任務(wù)(task)和 作業(yè)(job)通常串聯(lián)成一個軟件“管道”，一個自動流程成功完成后會啟動管道中的下一個流程。這些管道有許多不同的叫法，例如持續(xù)交付管道、部署管道和軟件開發(fā)管道。大體上講，程序管理者在管道執(zhí)行時管理管道各部分的定義、運行、監(jiān)控和報告。

持續(xù)交付管道是如何工作的？

軟件交付管道的實際實現(xiàn)可以有很大不同。有許多程序可用在管道中，用于源代碼跟蹤、構(gòu)建、測試、指標(biāo)采集，版本管理等各個方面。但整體工作流程通常是相同的。單個業(yè)務(wù)流程/工作流應(yīng)用程序管理整個管道，每個流程作為獨立的作業(yè)運行或由該應(yīng)用程序進(jìn)行階段管理。通常，在業(yè)務(wù)流程中，這些獨立作業(yè)是以應(yīng)用程序可理解并可作為工作流程管理的語法和結(jié)構(gòu)定義的。

這些作業(yè)被用于一個或多個功能（構(gòu)建、測試、部署等）。每個作業(yè)可能使用不同的技術(shù)或多種技術(shù)。關(guān)鍵是作業(yè)是自動化的、高效的，并且可重復(fù)的。如果作業(yè)成功，則工作流管理器將觸發(fā)管道中的下一個作業(yè)。如果作業(yè)失敗，工作流管理器會向開發(fā)人員、測試人員和其他人發(fā)出警報，以便他們盡快糾正問題。這個過程是自動化的，所以比手動運行一組過程可更快地找到錯誤。這種快速排錯稱為 快速失敗(fail fast)，并且在抵達(dá)管道端點方面同樣有價值。

“快速失敗”是什么意思？

管道的工作之一就是快速處理變更。另一個是監(jiān)視創(chuàng)建發(fā)布的不同任務(wù)/作業(yè)。由于編譯失敗或測試未通過的代碼可以阻止管道繼續(xù)運行，因此快速通知用戶此類情況非常重要?？焖偈≈傅氖窃诠艿懒鞒讨斜M快發(fā)現(xiàn)問題并快速通知用戶的方式，這樣可以及時修正問題并重新提交代碼以便使管道再次運行。通常在管道流程中可通過查看歷史記錄來確定是誰做了那次修改并通知此人及其團(tuán)隊。

所有持續(xù)交付管道都應(yīng)該被自動化嗎？

管道的幾乎所有部分都是應(yīng)該自動化的。對于某些部分，有一些人為干預(yù)/互動的地方可能是有意義的。一個例子可能是 用戶驗收測試(user-acceptance testing)（讓最終用戶試用軟件并確保它能達(dá)到他們想要/期望的水平）。另一種情況可能是部署到生產(chǎn)環(huán)境時用戶希望擁有更多的人為控制。當(dāng)然，如果代碼不正確或不能運行，則需要人工干預(yù)。

有了對“持續(xù)”含義理解的背景，讓我們看看不同類型的持續(xù)流程以及它們在軟件管道上下文中的含義。

什么是“持續(xù)集成”？

持續(xù)集成（CI）是在源代碼變更后自動檢測、拉取、構(gòu)建和（在大多數(shù)情況下）進(jìn)行單元測試的過程。持續(xù)集成是啟動管道的環(huán)節(jié)（盡管某些預(yù)驗證 —— 通常稱為 上線前檢查(pre-flight checks) —— 有時會被歸在持續(xù)集成之前）。

持續(xù)集成的目標(biāo)是快速確保開發(fā)人員新提交的變更是好的，并且適合在代碼庫中進(jìn)一步使用。

持續(xù)集成是如何工作的？

持續(xù)集成的基本思想是讓一個自動化過程監(jiān)測一個或多個源代碼倉庫是否有變更。當(dāng)變更被推送到倉庫時，它會監(jiān)測到更改、下載副本、構(gòu)建并運行任何相關(guān)的單元測試。

持續(xù)集成如何監(jiān)測變更？

目前，監(jiān)測程序通常是像 Jenkins 這樣的應(yīng)用程序，它還協(xié)調(diào)管道中運行的所有（或大多數(shù)）進(jìn)程，監(jiān)視變更是其功能之一。監(jiān)測程序可以以幾種不同方式監(jiān)測變更。這些包括：

• 輪詢：監(jiān)測程序反復(fù)詢問代碼管理系統(tǒng)，“代碼倉庫里有什么我感興趣的新東西嗎？”當(dāng)代碼管理系統(tǒng)有新的變更時，監(jiān)測程序會“喚醒”并完成其工作以獲取新代碼并構(gòu)建/測試它。
• 定期：監(jiān)測程序配置為定期啟動構(gòu)建，無論源碼是否有變更。理想情況下，如果沒有變更，則不會構(gòu)建任何新內(nèi)容，因此這不會增加額外的成本。
• 推送：這與用于代碼管理系統(tǒng)檢查的監(jiān)測程序相反。在這種情況下，代碼管理系統(tǒng)被配置為提交變更到倉庫時將“推送”一個通知到監(jiān)測程序。最常見的是，這可以以 webhook 的形式完成 —— 在新代碼被推送時一個 掛勾(hook)的程序通過互聯(lián)網(wǎng)向監(jiān)測程序發(fā)送通知。為此，監(jiān)測程序必須具有可以通過網(wǎng)絡(luò)接收 webhook 信息的開放端口。

什么是“預(yù)檢查”（又稱“上線前檢查”）？

在將代碼引入倉庫并觸發(fā)持續(xù)集成之前，可以進(jìn)行其它驗證。這遵循了最佳實踐，例如 測試構(gòu)建(test build)和 代碼審查(code review)。它們通常在代碼引入管道之前構(gòu)建到開發(fā)過程中。但是一些管道也可能將它們作為其監(jiān)控流程或工作流的一部分。

例如，一個名為 Gerrit 的工具允許在開發(fā)人員推送代碼之后但在允許進(jìn)入（ Git 遠(yuǎn)程）倉庫之前進(jìn)行正式的代碼審查、驗證和測試構(gòu)建。Gerrit 位于開發(fā)人員的工作區(qū)和 Git 遠(yuǎn)程倉庫之間。它會“接收”來自開發(fā)人員的推送，并且可以執(zhí)行通過/失敗驗證以確保它們在被允許進(jìn)入倉庫之前的檢查是通過的。這可以包括檢測新變更并啟動構(gòu)建測試（CI 的一種形式）。它還允許開發(fā)者在那時進(jìn)行正式的代碼審查。這種方式有一種額外的可信度評估機(jī)制，即當(dāng)變更的代碼被合并到代碼庫中時不會破壞任何內(nèi)容。

什么是“單元測試”？

單元測試（也稱為“提交測試”），是由開發(fā)人員編寫的小型的專項測試，以確保新代碼獨立工作?！蔼毩ⅰ边@里意味著不依賴或調(diào)用其它不可直接訪問的代碼，也不依賴外部數(shù)據(jù)源或其它模塊。如果運行代碼需要這樣的依賴關(guān)系，那么這些資源可以用 模擬(mock)來表示。模擬是指使用看起來像資源的 代碼存根(code stub)，可以返回值，但不實現(xiàn)任何功能。

在大多數(shù)組織中，開發(fā)人員負(fù)責(zé)創(chuàng)建單元測試以證明其代碼正確。事實上，一種稱為 測試驅(qū)動開發(fā)(test-driven develop)（TDD）的模型要求將首先設(shè)計單元測試作為清楚地驗證代碼功能的基礎(chǔ)。因為這樣的代碼可以更改速度快且改動量大，所以它們也必須執(zhí)行很快。

由于這與持續(xù)集成工作流有關(guān)，因此開發(fā)人員在本地工作環(huán)境中編寫或更新代碼，并通單元測試來確保新開發(fā)的功能或方法正確。通常，這些測試采用斷言形式，即函數(shù)或方法的給定輸入集產(chǎn)生給定的輸出集。它們通常進(jìn)行測試以確保正確標(biāo)記和處理出錯條件。有很多單元測試框架都很有用，例如用于 Java 開發(fā)的 JUnit 。

什么是“持續(xù)測試”？

持續(xù)測試是指在代碼通過持續(xù)交付管道時運行擴(kuò)展范圍的自動化測試的實踐。單元測試通常與構(gòu)建過程集成，作為持續(xù)集成階段的一部分，并專注于和其它與之交互的代碼隔離的測試。

除此之外，可以有或者應(yīng)該有各種形式的測試。這些可包括：

• 集成測試 驗證組件和服務(wù)組合在一起是否正常。
• 功能測試 驗證產(chǎn)品中執(zhí)行功能的結(jié)果是否符合預(yù)期。
• 驗收測試 根據(jù)可接受的標(biāo)準(zhǔn)驗證產(chǎn)品的某些特征。如性能、可伸縮性、抗壓能力和容量。

所有這些可能不存在于自動化的管道中，并且一些不同類型的測試分類界限也不是很清晰。但是，在交付管道中持續(xù)測試的目標(biāo)始終是相同的：通過持續(xù)的測試級別證明代碼的質(zhì)量可以在正在進(jìn)行的發(fā)布中使用。在持續(xù)集成快速的原則基礎(chǔ)上，第二個目標(biāo)是快速發(fā)現(xiàn)問題并提醒開發(fā)團(tuán)隊。這通常被稱為快速失敗。

除了測試之外，還可以對管道中的代碼進(jìn)行哪些其它類型的驗證？

除了測試是否通過之外，還有一些應(yīng)用程序可以告訴我們測試用例執(zhí)行（覆蓋）的源代碼行數(shù)。這是一個可以衡量代碼量指標(biāo)的例子。這個指標(biāo)稱為 代碼覆蓋率(code-coverage)，可以通過工具（例如用于 Java 的 JaCoCo ）進(jìn)行統(tǒng)計。

還有很多其它類型的指標(biāo)統(tǒng)計，例如代碼行數(shù)、復(fù)雜度以及代碼結(jié)構(gòu)對比分析等。諸如 SonarQube 之類的工具可以檢查源代碼并計算這些指標(biāo)。此外，用戶還可以為他們可接受的“合格”范圍的指標(biāo)設(shè)置閾值。然后可以在管道中針對這些閾值設(shè)置一個檢查，如果結(jié)果不在可接受范圍內(nèi)，則流程終端上。SonarQube 等應(yīng)用程序具有很高的可配置性，可以設(shè)置僅檢查團(tuán)隊感興趣的內(nèi)容。

什么是“持續(xù)交付”？

持續(xù)交付（CD）通常是指整個流程鏈（管道），它自動監(jiān)測源代碼變更并通過構(gòu)建、測試、打包和相關(guān)操作運行它們以生成可部署的版本，基本上沒有任何人為干預(yù)。

持續(xù)交付在軟件開發(fā)過程中的目標(biāo)是自動化、效率、可靠性、可重復(fù)性和質(zhì)量保障（通過持續(xù)測試）。

持續(xù)交付包含持續(xù)集成（自動檢測源代碼變更、執(zhí)行構(gòu)建過程、運行單元測試以驗證變更），持續(xù)測試（對代碼運行各種測試以保障代碼質(zhì)量），和（可選）持續(xù)部署（通過管道發(fā)布版本自動提供給用戶）。

如何在管道中識別/跟蹤多個版本？

版本控制是持續(xù)交付和管道的關(guān)鍵概念。持續(xù)意味著能夠經(jīng)常集成新代碼并提供更新版本。但這并不意味著每個人都想要“最新、最好的”。對于想要開發(fā)或測試已知的穩(wěn)定版本的內(nèi)部團(tuán)隊來說尤其如此。因此，管道創(chuàng)建并輕松存儲和訪問的這些版本化對象非常重要。

在管道中從源代碼創(chuàng)建的對象通常可以稱為 工件(artifact)。工件在構(gòu)建時應(yīng)該有應(yīng)用于它們的版本。將版本號分配給工件的推薦策略稱為 語義化版本控制(semantic versioning)。（這也適用于從外部源引入的依賴工件的版本。）

語義版本號有三個部分： 主要版本(major)、 次要版本(minor) 和 補(bǔ)丁版本(patch)。（例如，1.4.3 反映了主要版本 1，次要版本 4 和補(bǔ)丁版本 3。）這個想法是，其中一個部分的更改表示工件中的更新級別。主要版本僅針對不兼容的 API 更改而遞增。當(dāng)以 向后兼容(backward-compatible)的方式添加功能時，次要版本會增加。當(dāng)進(jìn)行向后兼容的版本 bug 修復(fù)時，補(bǔ)丁版本會增加。這些是建議的指導(dǎo)方針，但只要團(tuán)隊在整個組織內(nèi)以一致且易于理解的方式這樣做，團(tuán)隊就可以自由地改變這種方法。例如，每次為發(fā)布完成構(gòu)建時增加的數(shù)字可以放在補(bǔ)丁字段中。

如何“分銷”工件？

團(tuán)隊可以為工件分配 分銷(promotion)級別以指示適用于測試、生產(chǎn)等環(huán)境或用途。有很多方法。可以用 Jenkins 或 Artifactory 等應(yīng)用程序進(jìn)行分銷?；蛘咭粋€簡單的方案可以在版本號字符串的末尾添加標(biāo)簽。例如，-snapshot 可以指示用于構(gòu)建工件的代碼的最新版本（快照）?？梢允褂酶鞣N分銷策略或工具將工件“提升”到其它級別，例如 -milestone 或 -production，作為工件穩(wěn)定性和完備性版本的標(biāo)記。

如何存儲和訪問多個工件版本？

從源代碼構(gòu)建的版本化工件可以通過管理 工件倉庫(artifact repository)的應(yīng)用程序進(jìn)行存儲。工件倉庫就像構(gòu)建工件的版本控制工具一樣。像 Artifactory 或 Nexus 這類應(yīng)用可以接受版本化工件，存儲和跟蹤它們，并提供檢索的方法。

管道用戶可以指定他們想要使用的版本，并在這些版本中使用管道。

什么是“持續(xù)部署”？

持續(xù)部署（CD）是指能夠自動提供持續(xù)交付管道中發(fā)布版本給最終用戶使用的想法。根據(jù)用戶的安裝方式，可能是在云環(huán)境中自動部署、app 升級（如手機(jī)上的應(yīng)用程序）、更新網(wǎng)站或只更新可用版本列表。

這里的一個重點是，僅僅因為可以進(jìn)行持續(xù)部署并不意味著始終部署來自管道的每組可交付成果。它實際上指，通過管道每套可交付成果都被證明是“可部署的”。這在很大程度上是由持續(xù)測試的連續(xù)級別完成的（參見本文中的持續(xù)測試部分）。

管道構(gòu)建的發(fā)布成果是否被部署可以通過人工決策，或利用在完全部署之前“試用”發(fā)布的各種方法來進(jìn)行控制。

在完全部署到所有用戶之前，有哪些方法可以測試部署？

由于必須回滾/撤消對所有用戶的部署可能是一種代價高昂的情況（無論是技術(shù)上還是用戶的感知），已經(jīng)有許多技術(shù)允許“嘗試”部署新功能并在發(fā)現(xiàn)問題時輕松“撤消”它們。這些包括：

藍(lán)/綠測試/部署

在這種部署軟件的方法中，維護(hù)了兩個相同的主機(jī)環(huán)境 —— 一個“藍(lán)色” 和一個“綠色”。（顏色并不重要，僅作為標(biāo)識。）對應(yīng)來說，其中一個是“生產(chǎn)環(huán)境”，另一個是“預(yù)發(fā)布環(huán)境”。

在這些實例的前面是調(diào)度系統(tǒng)，它們充當(dāng)產(chǎn)品或應(yīng)用程序的客戶“網(wǎng)關(guān)”。通過將調(diào)度系統(tǒng)指向藍(lán)色或綠色實例，可以將客戶流量引流到期望的部署環(huán)境。通過這種方式，切換指向哪個部署實例（藍(lán)色或綠色）對用戶來說是快速，簡單和透明的。

當(dāng)新版本準(zhǔn)備好進(jìn)行測試時，可以將其部署到非生產(chǎn)環(huán)境中。在經(jīng)過測試和批準(zhǔn)后，可以更改調(diào)度系統(tǒng)設(shè)置以將傳入的線上流量指向它（因此它將成為新的生產(chǎn)站點）。現(xiàn)在，曾作為生產(chǎn)環(huán)境實例可供下一次候選發(fā)布使用。

同理，如果在最新部署中發(fā)現(xiàn)問題并且之前的生產(chǎn)實例仍然可用，則簡單的更改可以將客戶流量引流回到之前的生產(chǎn)實例 —— 有效地將問題實例“下線”并且回滾到以前的版本。然后有問題的新實例可以在其它區(qū)域中修復(fù)。

金絲雀測試/部署

在某些情況下，通過藍(lán)/綠發(fā)布切換整個部署可能不可行或不是期望的那樣。另一種方法是為 金絲雀(canary)測試/部署。在這種模型中，一部分客戶流量被重新引流到新的版本部署中。例如，新版本的搜索服務(wù)可以與當(dāng)前服務(wù)的生產(chǎn)版本一起部署。然后，可以將 10％ 的搜索查詢引流到新版本，以在生產(chǎn)環(huán)境中對其進(jìn)行測試。

如果服務(wù)那些流量的新版本沒問題，那么可能會有更多的流量會被逐漸引流過去。如果仍然沒有問題出現(xiàn)，那么隨著時間的推移，可以對新版本增量部署，直到 100％ 的流量都調(diào)度到新版本。這有效地“更替”了以前版本的服務(wù)，并讓新版本對所有客戶生效。

功能開關(guān)

對于可能需要輕松關(guān)掉的新功能（如果發(fā)現(xiàn)問題），開發(fā)人員可以添加 功能開關(guān)(feature toggles)。這是代碼中的 if-then 軟件功能開關(guān)，僅在設(shè)置數(shù)據(jù)值時才激活新代碼。此數(shù)據(jù)值可以是全局可訪問的位置，部署的應(yīng)用程序?qū)z查該位置是否應(yīng)執(zhí)行新代碼。如果設(shè)置了數(shù)據(jù)值，則執(zhí)行代碼；如果沒有，則不執(zhí)行。

這為開發(fā)人員提供了一個遠(yuǎn)程“終止開關(guān)”，以便在部署到生產(chǎn)環(huán)境后發(fā)現(xiàn)問題時關(guān)閉新功能。

暗箱發(fā)布

在 暗箱發(fā)布(dark launch)中，代碼被逐步測試/部署到生產(chǎn)環(huán)境中，但是用戶不會看到更改（因此名稱中有 暗箱(dark)一詞）。例如，在生產(chǎn)版本中，網(wǎng)頁查詢的某些部分可能會重定向到查詢新數(shù)據(jù)源的服務(wù)。開發(fā)人員可收集此信息進(jìn)行分析，而不會將有關(guān)接口，事務(wù)或結(jié)果的任何信息暴露給用戶。

這個想法是想獲取候選版本在生產(chǎn)環(huán)境負(fù)載下如何執(zhí)行的真實信息，而不會影響用戶或改變他們的經(jīng)驗。隨著時間的推移，可以調(diào)度更多負(fù)載，直到遇到問題或認(rèn)為新功能已準(zhǔn)備好供所有人使用。實際上功能開關(guān)標(biāo)志可用于這種暗箱發(fā)布機(jī)制。

什么是“運維開發(fā)”？

運維開發(fā) (DevOps) 是關(guān)于如何使開發(fā)和運維團(tuán)隊更容易合作開發(fā)和發(fā)布軟件的一系列想法和推薦的實踐。從歷史上看，開發(fā)團(tuán)隊研發(fā)了產(chǎn)品，但沒有像客戶那樣以常規(guī)、可重復(fù)的方式安裝/部署它們。在整個周期中，這組安裝/部署任務(wù)（以及其它支持任務(wù)）留給運維團(tuán)隊負(fù)責(zé)。這經(jīng)常導(dǎo)致很多混亂和問題，因為運維團(tuán)隊在后期才開始介入，并且必須在短時間內(nèi)完成他們的工作。同樣，開發(fā)團(tuán)隊經(jīng)常處于不利地位 —— 因為他們沒有充分測試產(chǎn)品的安裝/部署功能，他們可能會對該過程中出現(xiàn)的問題感到驚訝。

這往往導(dǎo)致開發(fā)和運維團(tuán)隊之間嚴(yán)重脫節(jié)和缺乏合作。DevOps 理念主張是貫穿整個開發(fā)周期的開發(fā)和運維綜合協(xié)作的工作方式，就像持續(xù)交付那樣。

持續(xù)交付如何與運維開發(fā)相交？

持續(xù)交付管道是幾個 DevOps 理念的實現(xiàn)。產(chǎn)品開發(fā)的后期階段（如打包和部署）始終可以在管道的每次運行中完成，而不是等待產(chǎn)品開發(fā)周期中的特定時間。同樣，從開發(fā)到部署過程中，開發(fā)和運維都可以清楚地看到事情何時起作用，何時不起作用。要使持續(xù)交付管道循環(huán)成功，不僅要通過與開發(fā)相關(guān)的流程，還要通過與運維相關(guān)的流程。

說得更遠(yuǎn)一些，DevOps 建議實現(xiàn)管道的基礎(chǔ)架構(gòu)也會被視為代碼。也就是說，它應(yīng)該自動配置、可跟蹤、易于修改，并在管道發(fā)生變化時觸發(fā)新一輪運行。這可以通過將管道實現(xiàn)為代碼來完成。

什么是“管道即代碼”？

管道即代碼(pipeline-as-code)是通過編寫代碼創(chuàng)建管道作業(yè)/任務(wù)的通用術(shù)語，就像開發(fā)人員編寫代碼一樣。它的目標(biāo)是將管道實現(xiàn)表示為代碼，以便它可以與代碼一起存儲、評審、跟蹤，如果出現(xiàn)問題并且必須終止管道，則可以輕松地重建。有幾個工具允許這樣做，如 Jenkins 2 。

DevOps 如何影響生產(chǎn)軟件的基礎(chǔ)設(shè)施？

傳統(tǒng)意義上，管道中使用的各個硬件系統(tǒng)都有配套的軟件（操作系統(tǒng)、應(yīng)用程序、開發(fā)工具等）。在極端情況下，每個系統(tǒng)都是手工設(shè)置來定制的。這意味著當(dāng)系統(tǒng)出現(xiàn)問題或需要更新時，這通常也是一項自定義任務(wù)。這種方法違背了持續(xù)交付的基本理念，即具有易于重現(xiàn)和可跟蹤的環(huán)境。

多年來，很多應(yīng)用被開發(fā)用于標(biāo)準(zhǔn)化交付（安裝和配置）系統(tǒng)。同樣， 虛擬機(jī)(virtual machine)被開發(fā)為模擬在其它計算機(jī)之上運行的計算機(jī)程序。這些 VM 要有管理程序才能在底層主機(jī)系統(tǒng)上運行，并且它們需要自己的操作系統(tǒng)副本才能運行。

后來有了 容器(container)。容器雖然在概念上與 VM 類似，但工作方式不同。它們只需使用一些現(xiàn)有的操作系統(tǒng)結(jié)構(gòu)來劃分隔離空間，而不需要運行單獨的程序和操作系統(tǒng)的副本。因此，它們的行為類似于 VM 以提供隔離但不需要過多的開銷。

VM 和容器是根據(jù)配置定義創(chuàng)建的，因此可以輕易地銷毀和重建，而不會影響運行它們的主機(jī)系統(tǒng)。這允許運行管道的系統(tǒng)也可重建。此外，對于容器，我們可以跟蹤其構(gòu)建定義文件的更改 —— 就像對源代碼一樣。

因此，如果遇到 VM 或容器中的問題，我們可以更容易、更快速地銷毀和重建它們，而不是在當(dāng)前環(huán)境嘗試調(diào)試和修復(fù)。

這也意味著對管道代碼的任何更改都可以觸發(fā)管道新一輪運行（通過 CI），就像對代碼的更改一樣。這是 DevOps 關(guān)于基礎(chǔ)架構(gòu)的核心理念之一。

via: https://opensource.com/article/18/8/what-cicd