持續(xù)集成（CI）和持續(xù)交付（CD）是軟件生產(chǎn)中非常常見的術(shù)語。但你知道他們的真正含義嗎？
圖片來源： opensource.com
在談?wù)撋a(chǎn)軟件時(shí)，持續(xù)集成（CI）和持續(xù)交付（CD）是非常常用的術(shù)語。但他們真正的意思是什么？在本文中，我將解釋這些和相關(guān)術(shù)語背后的含義和意義，例如連續(xù)測(cè)試和持續(xù)部署。
工廠中的裝配線以快速，自動(dòng)化，可重復(fù)的方式從原材料生產(chǎn)消費(fèi)品。同樣，軟件交付管道以快速，自動(dòng)化和可重現(xiàn)的方式從源代碼生成版本。如何完成這項(xiàng)工作的總體設(shè)計(jì)稱為“持續(xù)交付”。啟動(dòng)裝配線的過程稱為“持續(xù)集成”。確保質(zhì)量的過程稱為“持續(xù)測(cè)試”，使最終產(chǎn)品可供用戶使用的過程稱為“持續(xù)部署”。整體效率專家讓一切運(yùn)行順暢，每個(gè)人都被稱為“DevOps”從業(yè)者。
連續(xù)用于描述遵循我在此描述的實(shí)踐的許多不同過程。這并不意味著“永遠(yuǎn)在跑步”。它確實(shí)意味著“隨時(shí)可以運(yùn)行”。在創(chuàng)建軟件的環(huán)境中，它還包括幾個(gè)核心概念/最佳實(shí)踐。這些是：
頻繁發(fā)布：持續(xù)實(shí)踐背后的目標(biāo)是能夠頻繁地交付高質(zhì)量的軟件。此處的頻率是可變的，可由團(tuán)隊(duì)或公司定義。對(duì)于某些產(chǎn)品，每季度，每月，每周或每天一次可能足夠頻繁。對(duì)于其他人來說，一天可能需要多次并且可行。連續(xù)也可以采取“偶爾，按需”的方面。最終目標(biāo)是相同的：在可重復(fù)，可靠的過程中為最終用戶提供高質(zhì)量的軟件更新。通常，這可以通過很少甚至沒有交互或甚至用戶的知識(shí)來完成（想想設(shè)備更新）。
自動(dòng)化流程：實(shí)現(xiàn)這一頻率的關(guān)鍵部分是擁有自動(dòng)化流程來處理軟件生產(chǎn)的幾乎所有方面。這包括構(gòu)建，測(cè)試，分析，版本控制，以及在某些情況下的部署。
可重復(fù)：如果我們使用的自動(dòng)化流程在給定相同輸入的情況下始終具有相同的行為，則處理應(yīng)該是可重復(fù)的。也就是說，如果我們返回并輸入相同版本的代碼作為輸入，我們應(yīng)該得到相同的可交付成果集。這也假設(shè)我們有相同版本的外部依賴項(xiàng)（即我們不創(chuàng)建代碼使用的其他可交付項(xiàng)）。理想情況下，這也意味著可以對(duì)管道中的流程進(jìn)行版本控制和重新創(chuàng)建（請(qǐng)參閱稍后的DevOps討論）。
快速處理： “快速”是這里的相對(duì)術(shù)語，但無論軟件更新/發(fā)布的頻率如何，連續(xù)過程都需要以有效的方式處理從源代碼到可交付物的變更。自動(dòng)化負(fù)責(zé)大部分工作，但自動(dòng)化流程可能仍然很慢。例如，對(duì)于每天大部分時(shí)間都需要多次新候選發(fā)布的產(chǎn)品更新，對(duì)產(chǎn)品的所有方面進(jìn)行集成測(cè)試可能會(huì)太慢。
處理將源代碼轉(zhuǎn)換為可釋放產(chǎn)品的不同任務(wù)和作業(yè)通常串聯(lián)成一個(gè)軟件“管道”，其中一個(gè)自動(dòng)過程的成功完成啟動(dòng)序列中的下一個(gè)過程。這些管道有許多不同的名稱，例如持續(xù)交付管道，部署管道和軟件開發(fā)管道。整個(gè)管理程序應(yīng)用程序在管道執(zhí)行時(shí)管理不同管道部分的定義，運(yùn)行，監(jiān)視和報(bào)告。
軟件交付管道的實(shí)際實(shí)現(xiàn)可以有很大不同?？梢栽诠艿乐惺褂么罅亢投喾N應(yīng)用程序，用于源跟蹤，構(gòu)建，測(cè)試，收集指標(biāo)，管理版本等的各個(gè)方面。但是整個(gè)工作流程通常是相同的。單個(gè)業(yè)務(wù)流程/工作流應(yīng)用程序管理整個(gè)管道，每個(gè)流程作為單獨(dú)的作業(yè)運(yùn)行或由該應(yīng)用程序進(jìn)行階段管理。通常，單個(gè)“作業(yè)”是在業(yè)務(wù)流程應(yīng)用程序理解并可作為工作流程管理的語法和結(jié)構(gòu)中定義的。
創(chuàng)建作業(yè)以執(zhí)行一個(gè)或多個(gè)功能（構(gòu)建，測(cè)試，部署等）。每項(xiàng)工作可能使用不同的技術(shù)或多種技術(shù)。關(guān)鍵是作業(yè)是自動(dòng)化，高效和可重復(fù)的。如果作業(yè)成功，則工作流管理器應(yīng)用程序?qū)⒂|發(fā)管道中的下一個(gè)作業(yè)。如果作業(yè)失敗，工作流管理器會(huì)向開發(fā)人員，測(cè)試人員和其他人發(fā)出警報(bào)，以便他們盡快糾正問題。由于自動(dòng)化，可以比運(yùn)行一組手動(dòng)過程更快地找到錯(cuò)誤。這種快速識(shí)別錯(cuò)誤稱為“快速失敗”，并且在獲取管道端點(diǎn)方面同樣有價(jià)值。
管道工作之一就是快速處理變更。另一種方法是監(jiān)視創(chuàng)建發(fā)布的不同任務(wù)/作業(yè)。由于無法編譯或未通過測(cè)試的代碼可以阻止管道，因此快速通知用戶此類情況非常重要。快速失敗指的是管道處理盡快發(fā)現(xiàn)問題并快速通知用戶的想法，以便可以糾正問題并重新提交代碼以便通過管道進(jìn)行另一次運(yùn)行。通常，管道流程可以查看歷史記錄以確定誰進(jìn)行了更改并通知該人員及其團(tuán)隊(duì)。
管道的幾乎所有部分都應(yīng)該是自動(dòng)化的。對(duì)于某些部分，有一個(gè)人為干預(yù)/互動(dòng)的地方可能是有意義的。一個(gè)例子可能是用戶驗(yàn)收測(cè)試（讓最終用戶試用軟件并確保它能達(dá)到他們想要/期望的效果）。另一種情況可能是部署到生產(chǎn)環(huán)境，其中組希望擁有更多的人為控制。當(dāng)然，如果代碼不正確并且中斷，則需要人工干預(yù)。
有了連續(xù)含義的背景知識(shí)，讓我們看看不同類型的連續(xù)處理以及每個(gè)在軟件管道上下文中的含義。
持續(xù)集成（CI）是自動(dòng)檢測(cè)，拉取，構(gòu)建和（在大多數(shù)情況下）進(jìn)行單元測(cè)試的過程，因?yàn)楫a(chǎn)品的源代碼已更改。CI是啟動(dòng)管道的活動(dòng)（盡管某些預(yù)驗(yàn)證 - 通常稱為“飛行前檢查” - 有時(shí)會(huì)在CI之前合并）。
CI的目標(biāo)是快速確保開發(fā)人員的新變更“良好”并且適合在代碼庫中進(jìn)一步使用。
基本思想是讓自動(dòng)過程“觀察”一個(gè)或多個(gè)源代碼存儲(chǔ)庫以進(jìn)行更改。當(dāng)更改被推送到存儲(chǔ)庫時(shí)，觀察過程會(huì)檢測(cè)到更改，下載副本，構(gòu)建它并運(yùn)行任何相關(guān)的單元測(cè)試。
目前，觀看過程通常是像Jenkins這樣的應(yīng)用程序，它還協(xié)調(diào)管道中運(yùn)行的所有（或大多數(shù)）進(jìn)程，并監(jiān)視更改作為其功能之一。觀看應(yīng)用程序可以以幾種不同的方式監(jiān)視變化。這些包括：
輪詢：監(jiān)控程序反復(fù)詢問源管理系統(tǒng)，“您對(duì)我感興趣的存儲(chǔ)庫中有什么新東西嗎？” 當(dāng)源管理系統(tǒng)有新的更改時(shí)，監(jiān)視程序會(huì)“喚醒”并完成其工作以獲取新代碼并構(gòu)建/測(cè)試它。
定期：監(jiān)控程序配置為定期啟動(dòng)構(gòu)建，無論是否有更改。理想情況下，如果沒有更改，則不會(huì)構(gòu)建任何新內(nèi)容，因此這不會(huì)增加額外的成本。
推送：這與使用源管理系統(tǒng)檢查的監(jiān)視應(yīng)用程序相反。在這種情況下，源管理系統(tǒng)被配置為當(dāng)將更改提交到存儲(chǔ)庫時(shí)將通知“推出”到監(jiān)視應(yīng)用程序。最常見的是，這可以以“webhook”的形式完成 - 一個(gè)程序被“鉤住”以在推送新代碼時(shí)運(yùn)行并通過互聯(lián)網(wǎng)向監(jiān)控程序發(fā)送通知。為此，監(jiān)控程序必須具有可以通過Internet接收webhook信息的開放端口。
在將代碼引入源存儲(chǔ)庫并觸發(fā)持續(xù)集成之前，可以進(jìn)行其他驗(yàn)證。這些遵循最佳實(shí)踐，例如測(cè)試版本和代碼審查。它們通常在代碼引入管道之前構(gòu)建到開發(fā)過程中。但是一些管道也可能將它們作為其監(jiān)控流程或工作流程的一部分。
例如，一個(gè)名為Gerrit的工具允許在開發(fā)人員推送代碼之后但在允許進(jìn)入（Git遠(yuǎn)程）存儲(chǔ)庫之前進(jìn)行正式的代碼審查，驗(yàn)證和測(cè)試構(gòu)建。Gerrit位于開發(fā)人員工作區(qū)和Git遠(yuǎn)程存儲(chǔ)庫之間。它“抓住”來自開發(fā)人員的推送，并且可以執(zhí)行通過/失敗驗(yàn)證以確保它們?cè)诒辉试S進(jìn)入存儲(chǔ)庫之前通過。這可以包括檢測(cè)建議的更改并開始測(cè)試構(gòu)建（CI的形式）。它還允許組在那時(shí)進(jìn)行正式的代碼審查。通過這種方式，有一種額外的信心，即當(dāng)變量合并到代碼庫中時(shí)，變化不會(huì)破壞任何東西。
單元測(cè)試（也稱為“提交測(cè)試”）是由開發(fā)人員編寫的小型，集中測(cè)試，以確保新代碼獨(dú)立工作?！肮铝⒌亍边@里意味著不依賴于或調(diào)用其他不可直接訪問的代碼，也不依賴于外部數(shù)據(jù)源或其他模塊。如果運(yùn)行代碼需要這樣的依賴關(guān)系，那么這些資源可以用模擬來表示。模擬是指使用看起來像資源的代碼存根，可以返回值但不實(shí)現(xiàn)任何功能。
在大多數(shù)組織中，開發(fā)人員負(fù)責(zé)創(chuàng)建單元測(cè)試以證明其代碼有效。事實(shí)上，一個(gè)模型（稱為測(cè)試驅(qū)動(dòng)開發(fā) [TDD]）要求首先設(shè)計(jì)單元測(cè)試作為清楚地識(shí)別代碼應(yīng)該做什么的基礎(chǔ)。因?yàn)檫@樣的代碼更改速度快且數(shù)量眾多，所以它們也必須快速執(zhí)行。
由于它們與持續(xù)集成工作流有關(guān)，因此開發(fā)人員在其本地工作環(huán)境中創(chuàng)建或更新源，并使用單元測(cè)試來確保新開發(fā)的功能或方法有效。通常，這些測(cè)試采用斷言形式，即函數(shù)或方法的給定輸入集產(chǎn)生給定的輸出集。它們通常進(jìn)行測(cè)試以確保正確標(biāo)記和處理錯(cuò)誤條件。各種單元測(cè)試框架（例如JUnit for Java開發(fā)）可以提供幫助。
連續(xù)測(cè)試是指在代碼通過CD管道時(shí)運(yùn)行擴(kuò)展范圍的自動(dòng)化測(cè)試的實(shí)踐。單元測(cè)試通常與構(gòu)建過程集成，作為CI階段的一部分，并專注于與其他與之交互的代碼隔離測(cè)試代碼。
除此之外，還有各種形式的測(cè)試可以/應(yīng)該發(fā)生。這些可包括：
集成測(cè)試驗(yàn)證組件和服務(wù)組是否一起工作。
功能測(cè)試驗(yàn)證產(chǎn)品中執(zhí)行功能的結(jié)果是否符合預(yù)期。
驗(yàn)收測(cè)試根據(jù)可接受的標(biāo)準(zhǔn)測(cè)量系統(tǒng)的某些特征。示例包括性能，可伸縮性，壓力和容量。
所有這些可能不存在于自動(dòng)化管道中，并且一些不同類型之間的線可能模糊。但是，在交付管道中持續(xù)測(cè)試的目標(biāo)始終是相同的：通過連續(xù)的測(cè)試級(jí)別證明代碼具有可以在正在進(jìn)行的發(fā)布中使用的質(zhì)量?；诔掷m(xù)快速的原則，第二個(gè)目標(biāo)是快速發(fā)現(xiàn)問題并提醒開發(fā)團(tuán)隊(duì)。這通常被稱為快速失敗。
除了測(cè)試的通過/失敗方面之外，還存在一些應(yīng)用程序，它們還可以告訴我們測(cè)試用例執(zhí)行（覆蓋）的源代碼行數(shù)。這是可以跨源代碼計(jì)算的度量的示例。此度量標(biāo)準(zhǔn)稱為代碼覆蓋率，可以通過工具（例如JaCoCo for Java源代碼）進(jìn)行測(cè)量。
存在許多其他類型的度量，例如計(jì)算代碼行，測(cè)量復(fù)雜度，以及將編碼結(jié)構(gòu)與已知模式進(jìn)行比較。SonarQube等工具可以檢查源代碼并計(jì)算這些指標(biāo)。除此之外，用戶還可以設(shè)置他們?cè)敢饨邮艿姆秶拈撝?，作為這些指標(biāo)的“傳遞”。然后，可以設(shè)置流水線中的處理以針對(duì)閾值檢查計(jì)算值，并且如果值不在可接受范圍內(nèi)，則可以停止處理。SonarQube等應(yīng)用程序具有高度可配置性，可以進(jìn)行調(diào)整以僅檢查團(tuán)隊(duì)感興趣的內(nèi)容。
持續(xù)交付（CD）通常是指整個(gè)流程鏈（管道），它自動(dòng)獲取源代碼更改并通過構(gòu)建，測(cè)試，打包和相關(guān)操作運(yùn)行它們，以生成可部署的版本，基本上沒有任何人為干預(yù)。
CD在生成軟件版本中的目標(biāo)是自動(dòng)化，效率，可靠性，可重復(fù)性和質(zhì)量驗(yàn)證（通過連續(xù)測(cè)試）。
CD包含CI（自動(dòng)檢測(cè)源代碼更改，執(zhí)行更改的構(gòu)建過程，運(yùn)行單元測(cè)試以驗(yàn)證），連續(xù)測(cè)試（對(duì)代碼運(yùn)行各種測(cè)試以獲得對(duì)代碼質(zhì)量的連續(xù)可信度），和（可選）連續(xù)部署（從管道發(fā)布版本自動(dòng)為用戶提供）。
版本控制是處理CD和管道的關(guān)鍵概念。連續(xù)意味著能夠經(jīng)常集成新代碼并提供更新版本。但這并不意味著每個(gè)人都想要“最新，最偉大的”。對(duì)于想要開發(fā)或測(cè)試已知穩(wěn)定版本的內(nèi)部團(tuán)隊(duì)來說尤其如此。因此，管道版本對(duì)象創(chuàng)建并輕松存儲(chǔ)和訪問這些版本化對(duì)象非常重要。
從源代碼在流水線處理中創(chuàng)建的對(duì)象通常可以稱為工件。工件在構(gòu)建時(shí)應(yīng)該有應(yīng)用于它們的版本。將版本號(hào)分配給工件的建議策略稱為語義版本控制。（這也適用于從外部源引入的依賴工件的版本。）
語義版本號(hào)有三個(gè)部分：major，minor和patch。（例如，1.4.3反映了主要版本1，次要版本4和補(bǔ)丁版本3.）這個(gè)想法是，其中一個(gè)部分的更改表示工件中的更新級(jí)別。主要版本僅針對(duì)不兼容的API更改而遞增。當(dāng)以向后兼容的方式添加功能時(shí)，次要版本會(huì)增加。當(dāng)進(jìn)行向后兼容的錯(cuò)誤修復(fù)時(shí)，補(bǔ)丁版本會(huì)增加。這些是建議的指導(dǎo)原則，但只要團(tuán)隊(duì)在整個(gè)組織內(nèi)以一致且易于理解的方式這樣做，團(tuán)隊(duì)就可以自由地改變這種方法。例如，每次為發(fā)布完成構(gòu)建時(shí)增加的數(shù)字可以放在補(bǔ)丁字段中。
團(tuán)隊(duì)可以為工件分配促銷“級(jí)別”，以指示測(cè)試，生產(chǎn)等的適用性。有各種方法?？梢詥⒂肑enkins或Artifactory等應(yīng)用程序進(jìn)行促銷。或者一個(gè)簡單的方案可以是在版本字符串的末尾添加標(biāo)簽。例如，-snapshot可以指示用于構(gòu)建工件的代碼的最新版本（快照）?？梢允褂酶鞣N促銷策略或工具將工件“推廣”到其他級(jí)別，例如-milestone或-production，作為工件穩(wěn)定性和準(zhǔn)備釋放的指示。
從源構(gòu)建的版本化工件可以通過管理“工件存儲(chǔ)庫”的應(yīng)用程序進(jìn)行存儲(chǔ)。工件存儲(chǔ)庫就像構(gòu)建工件的源管理一樣。應(yīng)用程序（例如Artifactory或Nexus）可以接受版本化工件，存儲(chǔ)和跟蹤它們，并提供檢索它們的方法。
管道用戶可以指定他們想要使用的版本，并在這些版本中使用管道。
持續(xù)部署（CD）是指能夠自動(dòng)釋放CD管道中的代碼并使其可供最終用戶使用的想法。根據(jù)用戶“安裝”代碼的方式，這可能意味著在云中自動(dòng)部署內(nèi)容，使更新可用（例如手機(jī)上的應(yīng)用程序），更新網(wǎng)站或僅更新可用版本列表。
這里的一個(gè)重點(diǎn)是，僅僅因?yàn)榭梢赃M(jìn)行持續(xù)部署并不意味著總是部署來自管道的每組可交付成果。它確實(shí)意味著，通過管道，每組可交付成果都被證明是“可部署的”。這在很大程度上是通過連續(xù)測(cè)試的連續(xù)級(jí)別完成的（參見本文中的連續(xù)測(cè)試部分）。
是否部署了管道運(yùn)行的發(fā)布可以通過人工決策和用于在完全部署之前“試用”發(fā)布的各種方法來進(jìn)行門控。
由于必須回滾/撤消對(duì)所有用戶的部署可能是一種代價(jià)高昂的情況（無論是技術(shù)上還是用戶的感知），已經(jīng)開發(fā)了許多技術(shù)來允許“嘗試”部署新功能并在問題時(shí)輕松“撤消”它們被發(fā)現(xiàn)。這些包括：
在這種部署軟件的方法中，維護(hù)了兩個(gè)相同的托管環(huán)境 - 藍(lán)色環(huán)境和綠色環(huán)境。（顏色并不重要，僅作為標(biāo)識(shí)符。）在任何給定點(diǎn)，其中一個(gè)是生產(chǎn)部署，另一個(gè)是候選部署。
在這些實(shí)例的前面是路由器或其他系統(tǒng)，它們充當(dāng)產(chǎn)品或應(yīng)用程序的客戶“網(wǎng)關(guān)”。通過將路由器指向所需的藍(lán)色或綠色實(shí)例，可以將客戶流量定向到所需的部署。通過這種方式，交換出指向哪個(gè)部署實(shí)例（藍(lán)色或綠色）對(duì)用戶來說是快速，簡單和透明的。
當(dāng)新版本準(zhǔn)備好進(jìn)行測(cè)試時(shí)，可以將其部署到非生產(chǎn)環(huán)境中。在經(jīng)過測(cè)試和批準(zhǔn)后，可以更改路由器以將傳入的生產(chǎn)流量指向它（因此它將成為新的生產(chǎn)站點(diǎn)）?，F(xiàn)在，生產(chǎn)的托管環(huán)境可供下一個(gè)候選人使用。
同樣，如果在最新部署中發(fā)現(xiàn)問題并且之前的生產(chǎn)實(shí)例仍然部署在其他環(huán)境中，則簡單的更改可以將客戶流量指回到先前的生產(chǎn)實(shí)例 - 有效地將問題實(shí)例“脫機(jī)”并且回滾到以前的版本。然后可以在其他區(qū)域中修復(fù)具有該問題的新部署。
在某些情況下，通過藍(lán)色/綠色環(huán)境交換整個(gè)部署可能不可行或不可取。另一種方法稱為金絲雀測(cè)試/部署。在此模型中，一部分客戶流量被重新路由到產(chǎn)品的新部分。例如，產(chǎn)品中的新版本的搜索服務(wù)可以與服務(wù)的當(dāng)前生產(chǎn)版本一起部署。然后，可以將10％的搜索查詢路由到新版本，以在生產(chǎn)環(huán)境中對(duì)其進(jìn)行測(cè)試。
如果新服務(wù)處理有限的流量而沒有問題，那么隨著時(shí)間的推移可能會(huì)有更多的流量路由到它。如果沒有出現(xiàn)問題，那么隨著時(shí)間的推移，可以增加路由到新服務(wù)的流量，直到100％的流量流向它。這有效地“退休”了以前版本的服務(wù)，并使新版本對(duì)所有客戶生效。
對(duì)于可能需要輕松退出的新功能（如果發(fā)現(xiàn)問題），開發(fā)人員可以添加功能切換。這是代碼中的軟件if-then開關(guān)，僅在設(shè)置數(shù)據(jù)值時(shí)才激活代碼。此數(shù)據(jù)值可以是全局可訪問的位置，部署的應(yīng)用程序?qū)z查該位置是否應(yīng)執(zhí)行新代碼。如果設(shè)置了數(shù)據(jù)值，則執(zhí)行代碼; 如果沒有，它沒有。
這為開發(fā)人員提供了一個(gè)遠(yuǎn)程“終止開關(guān)”，以便在部署到生產(chǎn)后發(fā)現(xiàn)問題時(shí)關(guān)閉新功能。
在這種實(shí)踐中，代碼被逐步測(cè)試/部署到生產(chǎn)中，但是用戶不會(huì)看到更改（因此稱為“黑暗”名稱）。例如，在生產(chǎn)版本中，Web查詢的某些部分可能會(huì)重定向到查詢新數(shù)據(jù)源的服務(wù)?？梢酝ㄟ^開發(fā)收集此信息以進(jìn)行分析，而無需向用戶公開有關(guān)接口，事務(wù)或結(jié)果的任何信息。
這里的想法是獲得有關(guān)候選變更如何在生產(chǎn)負(fù)載下執(zhí)行而不影響用戶或改變其體驗(yàn)的真實(shí)信息。隨著時(shí)間的推移，可以重定向更多負(fù)載，直到找到問題或認(rèn)為新功能已準(zhǔn)備好供所有人使用。功能標(biāo)志實(shí)際上可用于處理暗發(fā)射的機(jī)制。
DevOps的是一組關(guān)于如何使開發(fā)和運(yùn)營團(tuán)隊(duì)更容易合作開發(fā)和發(fā)布軟件的想法和推薦實(shí)踐。從歷史上看，開發(fā)團(tuán)隊(duì)創(chuàng)建了產(chǎn)品，但沒有像客戶那樣以常規(guī)，可重復(fù)的方式安裝/部署它們。這組安裝/部署任務(wù)（以及其他支持任務(wù)）留給運(yùn)營團(tuán)隊(duì)在整個(gè)周期中進(jìn)行整理。這經(jīng)常導(dǎo)致很多混亂和問題，因?yàn)檫\(yùn)營團(tuán)隊(duì)在周期的后期進(jìn)入循環(huán)，并且必須在短時(shí)間內(nèi)完成他們的工作。同樣，開發(fā)團(tuán)隊(duì)經(jīng)常處于不利地位 - 因?yàn)樗麄儧]有充分測(cè)試產(chǎn)品的安裝/部署功能，他們可能會(huì)對(duì)該過程中出現(xiàn)的問題感到驚訝。
這往往導(dǎo)致發(fā)展和運(yùn)營團(tuán)隊(duì)之間嚴(yán)重脫節(jié)和缺乏合作。DevOps理想主張從開發(fā)周期到結(jié)束時(shí)涉及開發(fā)和操作人員的工作方式，例如CD。
CD管道是幾個(gè)DevOps理想的實(shí)現(xiàn)。產(chǎn)品的后期階段（如打包和部署）始終可以在管道的每次運(yùn)行中完成，而不是等待產(chǎn)品開發(fā)周期中的特定點(diǎn)。同樣，開發(fā)人員和操作人員都可以清楚地看到事情何時(shí)起作用，何時(shí)起作用，從開發(fā)到部署。要使CD管道的循環(huán)成功，它必須不僅要通過與開發(fā)相關(guān)的過程，還要經(jīng)過與操作相關(guān)的過程。
進(jìn)入下一個(gè)級(jí)別，DevOps表明即使是實(shí)現(xiàn)管道的基礎(chǔ)架構(gòu)也會(huì)被視為代碼。也就是說，它應(yīng)該自動(dòng)配置，可跟蹤，易于更改，并在管道發(fā)生變化時(shí)產(chǎn)生新的管道運(yùn)行。這可以通過將管道實(shí)現(xiàn)為代碼來完成。
Pipeline-as-code是通過編程代碼創(chuàng)建管道作業(yè)/任務(wù)的通用術(shù)語，就像開發(fā)人員使用產(chǎn)品的源代碼一樣。目標(biāo)是將管道實(shí)現(xiàn)表示為代碼，以便它可以與代碼一起存儲(chǔ)，審查，跟蹤一段時(shí)間，如果出現(xiàn)問題并且必須停止管道，則可以輕松地再次啟動(dòng)。有幾個(gè)工具允許這樣做，包括Jenkins 2。
傳統(tǒng)上，管道中使用的各個(gè)硬件系統(tǒng)一次一個(gè)地配置有軟件（操作系統(tǒng)，應(yīng)用程序，開發(fā)工具等）。在極端情況下，每個(gè)系統(tǒng)都是一個(gè)定制的手工設(shè)置。這意味著當(dāng)系統(tǒng)出現(xiàn)問題或需要更新時(shí)，這通常也是一項(xiàng)自定義任務(wù)。這種方法違背了基本的CD理想，即具有易于重現(xiàn)和可跟蹤的環(huán)境。
多年來，已經(jīng)開發(fā)了應(yīng)用程序來標(biāo)準(zhǔn)化供應(yīng)（安裝和配置）系統(tǒng)。同樣，虛擬機(jī)被開發(fā)為模擬在其他計(jì)算機(jī)之上運(yùn)行的計(jì)算機(jī)的程序。這些VM需要監(jiān)控程序才能在底層主機(jī)系統(tǒng)上運(yùn)行它們。并且他們需要自己的操作系統(tǒng)副本才能運(yùn)行。
接下來是容器。容器雖然在概念上與VM類似，但工作方式不同。他們只需使用一些現(xiàn)有的操作系統(tǒng)結(jié)構(gòu)來劃分操作系統(tǒng)中的隔離空間，而不需要單獨(dú)的程序和操作系統(tǒng)的副本來運(yùn)行。因此，它們的行為類似于VM以提供隔離但不需要開銷。
由于VM和容器是根據(jù)存儲(chǔ)的定義創(chuàng)建的，因此可以輕松地銷毀和重新創(chuàng)建它們，而不會(huì)影響它們運(yùn)行的主機(jī)系統(tǒng)。這允許可重新創(chuàng)建的系統(tǒng)運(yùn)行管道。此外，對(duì)于容器，我們可以跟蹤對(duì)它們構(gòu)建的定義文件的更改 - 就像我們對(duì)源代碼一樣。
因此，如果我們遇到VM或容器中的問題，可能更容易和更快地銷毀和重新創(chuàng)建它，而不是嘗試調(diào)試并修復(fù)現(xiàn)有的。
這也意味著對(duì)管道代碼的任何更改都可以觸發(fā)管道的新運(yùn)行（通過CI），就像對(duì)代碼的更改一樣。這是DevOps關(guān)于基礎(chǔ)架構(gòu)的核心理念之一。
聯(lián)系客服
