什么是 CI/CD? (持续集成/持续交付)
在軟件開發(fā)中經(jīng)常會(huì)提到持續(xù)集成Continuous Integration(CI)和持續(xù)交付Continuous Delivery(CD)這幾個(gè)術(shù)語(yǔ)。但它們真正的意思是什么呢?
在談?wù)撥浖_發(fā)時(shí),經(jīng)常會(huì)提到持續(xù)集成Continuous Integration(CI)和持續(xù)交付Continuous Delivery(CD)這幾個(gè)術(shù)語(yǔ)。但它們真正的意思是什么呢?在本文中,我將解釋這些和相關(guān)術(shù)語(yǔ)背后的含義和意義,例如持續(xù)測(cè)試Continuous Testing和持續(xù)部署Continuous Deployment。
概覽
工廠里的裝配線以快速、自動(dòng)化、可重復(fù)的方式從原材料生產(chǎn)出消費(fèi)品。同樣,軟件交付管道以快速、自動(dòng)化和可重復(fù)的方式從源代碼生成發(fā)布版本。如何完成這項(xiàng)工作的總體設(shè)計(jì)稱為“持續(xù)交付”(CD)。啟動(dòng)裝配線的過(guò)程稱為“持續(xù)集成”(CI)。確保質(zhì)量的過(guò)程稱為“持續(xù)測(cè)試”,將最終產(chǎn)品提供給用戶的過(guò)程稱為“持續(xù)部署”。一些專家讓這一切簡(jiǎn)單、順暢、高效地運(yùn)行,這些人被稱為運(yùn)維開發(fā)DevOps踐行者。
“持續(xù)”是什么意思?
“持續(xù)”用于描述遵循我在此提到的許多不同流程實(shí)踐。這并不意味著“一直在運(yùn)行”,而是“隨時(shí)可運(yùn)行”。在軟件開發(fā)領(lǐng)域,它還包括幾個(gè)核心概念/最佳實(shí)踐。這些是:
- 頻繁發(fā)布:持續(xù)實(shí)踐背后的目標(biāo)是能夠頻繁地交付高質(zhì)量的軟件。此處的交付頻率是可變的,可由開發(fā)團(tuán)隊(duì)或公司定義。對(duì)于某些產(chǎn)品,一季度、一個(gè)月、一周或一天交付一次可能已經(jīng)足夠頻繁了。對(duì)于另一些來(lái)說(shuō),一天可能需要多次交付也是可行的。所謂持續(xù)也有“偶爾、按需”的方面。最終目標(biāo)是相同的:在可重復(fù)、可靠的過(guò)程中為最終用戶提供高質(zhì)量的軟件更新。通常,這可以通過(guò)很少甚至無(wú)需用戶的交互或掌握的知識(shí)來(lái)完成(想想設(shè)備更新)。
- 自動(dòng)化流程:實(shí)現(xiàn)此頻率的關(guān)鍵是用自動(dòng)化流程來(lái)處理軟件生產(chǎn)中的方方面面。這包括構(gòu)建、測(cè)試、分析、版本控制,以及在某些情況下的部署。
- 可重復(fù):如果我們使用的自動(dòng)化流程在給定相同輸入的情況下始終具有相同的行為,則這個(gè)過(guò)程應(yīng)該是可重復(fù)的。也就是說(shuō),如果我們把某個(gè)歷史版本的代碼作為輸入,我們應(yīng)該得到對(duì)應(yīng)相同的可交付產(chǎn)出。這也假設(shè)我們有相同版本的外部依賴項(xiàng)(即我們不創(chuàng)建該版本代碼使用的其它交付物)。理想情況下,這也意味著可以對(duì)管道中的流程進(jìn)行版本控制和重建(請(qǐng)參閱稍后的 DevOps 討論)。
- 快速迭代:“快速”在這里是個(gè)相對(duì)術(shù)語(yǔ),但無(wú)論軟件更新/發(fā)布的頻率如何,預(yù)期的持續(xù)過(guò)程都會(huì)以高效的方式將源代碼轉(zhuǎn)換為交付物。自動(dòng)化負(fù)責(zé)大部分工作,但自動(dòng)化處理的過(guò)程可能仍然很慢。例如,對(duì)于每天需要多次發(fā)布候選版更新的產(chǎn)品來(lái)說(shuō),一輪集成測(cè)試integrated testing下來(lái)耗時(shí)就要大半天可能就太慢了。
什么是“持續(xù)交付管道”?
將源代碼轉(zhuǎn)換為可發(fā)布產(chǎn)品的多個(gè)不同的任務(wù)task和作業(yè)job通常串聯(lián)成一個(gè)軟件“管道”,一個(gè)自動(dòng)流程成功完成后會(huì)啟動(dòng)管道中的下一個(gè)流程。這些管道有許多不同的叫法,例如持續(xù)交付管道、部署管道和軟件開發(fā)管道。大體上講,程序管理者在管道執(zhí)行時(shí)管理管道各部分的定義、運(yùn)行、監(jiān)控和報(bào)告。
持續(xù)交付管道是如何工作的?
軟件交付管道的實(shí)際實(shí)現(xiàn)可以有很大不同。有許多程序可用在管道中,用于源代碼跟蹤、構(gòu)建、測(cè)試、指標(biāo)采集,版本管理等各個(gè)方面。但整體工作流程通常是相同的。單個(gè)業(yè)務(wù)流程/工作流應(yīng)用程序管理整個(gè)管道,每個(gè)流程作為獨(dú)立的作業(yè)運(yùn)行或由該應(yīng)用程序進(jìn)行階段管理。通常,在業(yè)務(wù)流程中,這些獨(dú)立作業(yè)是以應(yīng)用程序可理解并可作為工作流程管理的語(yǔ)法和結(jié)構(gòu)定義的。
這些作業(yè)被用于一個(gè)或多個(gè)功能(構(gòu)建、測(cè)試、部署等)。每個(gè)作業(yè)可能使用不同的技術(shù)或多種技術(shù)。關(guān)鍵是作業(yè)是自動(dòng)化的、高效的,并且可重復(fù)的。如果作業(yè)成功,則工作流管理器將觸發(fā)管道中的下一個(gè)作業(yè)。如果作業(yè)失敗,工作流管理器會(huì)向開發(fā)人員、測(cè)試人員和其他人發(fā)出警報(bào),以便他們盡快糾正問(wèn)題。這個(gè)過(guò)程是自動(dòng)化的,所以比手動(dòng)運(yùn)行一組過(guò)程可更快地找到錯(cuò)誤。這種快速排錯(cuò)稱為快速失敗fail fast,并且在抵達(dá)管道端點(diǎn)方面同樣有價(jià)值。
“快速失敗”是什么意思?
管道的工作之一就是快速處理變更。另一個(gè)是監(jiān)視創(chuàng)建發(fā)布的不同任務(wù)/作業(yè)。由于編譯失敗或測(cè)試未通過(guò)的代碼可以阻止管道繼續(xù)運(yùn)行,因此快速通知用戶此類情況非常重要。快速失敗指的是在管道流程中盡快發(fā)現(xiàn)問(wèn)題并快速通知用戶的方式,這樣可以及時(shí)修正問(wèn)題并重新提交代碼以便使管道再次運(yùn)行。通常在管道流程中可通過(guò)查看歷史記錄來(lái)確定是誰(shuí)做了那次修改并通知此人及其團(tuán)隊(duì)。
所有持續(xù)交付管道都應(yīng)該被自動(dòng)化嗎?
管道的幾乎所有部分都是應(yīng)該自動(dòng)化的。對(duì)于某些部分,有一些人為干預(yù)/互動(dòng)的地方可能是有意義的。一個(gè)例子可能是用戶驗(yàn)收測(cè)試user-acceptance testing(讓最終用戶試用軟件并確保它能達(dá)到他們想要/期望的水平)。另一種情況可能是部署到生產(chǎn)環(huán)境時(shí)用戶希望擁有更多的人為控制。當(dāng)然,如果代碼不正確或不能運(yùn)行,則需要人工干預(yù)。
有了對(duì)“持續(xù)”含義理解的背景,讓我們看看不同類型的持續(xù)流程以及它們?cè)谲浖艿郎舷挛闹械暮x。
什么是“持續(xù)集成”?
持續(xù)集成(CI)是在源代碼變更后自動(dòng)檢測(cè)、拉取、構(gòu)建和(在大多數(shù)情況下)進(jìn)行單元測(cè)試的過(guò)程。持續(xù)集成是啟動(dòng)管道的環(huán)節(jié)(盡管某些預(yù)驗(yàn)證 —— 通常稱為上線前檢查pre-flight checks?—— 有時(shí)會(huì)被歸在持續(xù)集成之前)。
持續(xù)集成的目標(biāo)是快速確保開發(fā)人員新提交的變更是好的,并且適合在代碼庫(kù)中進(jìn)一步使用。
持續(xù)集成是如何工作的?
持續(xù)集成的基本思想是讓一個(gè)自動(dòng)化過(guò)程監(jiān)測(cè)一個(gè)或多個(gè)源代碼倉(cāng)庫(kù)是否有變更。當(dāng)變更被推送到倉(cāng)庫(kù)時(shí),它會(huì)監(jiān)測(cè)到更改、下載副本、構(gòu)建并運(yùn)行任何相關(guān)的單元測(cè)試。
持續(xù)集成如何監(jiān)測(cè)變更?
目前,監(jiān)測(cè)程序通常是像?Jenkins?這樣的應(yīng)用程序,它還協(xié)調(diào)管道中運(yùn)行的所有(或大多數(shù))進(jìn)程,監(jiān)視變更是其功能之一。監(jiān)測(cè)程序可以以幾種不同方式監(jiān)測(cè)變更。這些包括:
- 輪詢:監(jiān)測(cè)程序反復(fù)詢問(wèn)代碼管理系統(tǒng),“代碼倉(cāng)庫(kù)里有什么我感興趣的新東西嗎?”當(dāng)代碼管理系統(tǒng)有新的變更時(shí),監(jiān)測(cè)程序會(huì)“喚醒”并完成其工作以獲取新代碼并構(gòu)建/測(cè)試它。
- 定期:監(jiān)測(cè)程序配置為定期啟動(dòng)構(gòu)建,無(wú)論源碼是否有變更。理想情況下,如果沒有變更,則不會(huì)構(gòu)建任何新內(nèi)容,因此這不會(huì)增加額外的成本。
- 推送:這與用于代碼管理系統(tǒng)檢查的監(jiān)測(cè)程序相反。在這種情況下,代碼管理系統(tǒng)被配置為提交變更到倉(cāng)庫(kù)時(shí)將“推送”一個(gè)通知到監(jiān)測(cè)程序。最常見的是,這可以以 webhook 的形式完成 —— 在新代碼被推送時(shí)一個(gè)掛勾hook的程序通過(guò)互聯(lián)網(wǎng)向監(jiān)測(cè)程序發(fā)送通知。為此,監(jiān)測(cè)程序必須具有可以通過(guò)網(wǎng)絡(luò)接收 webhook 信息的開放端口。
什么是“預(yù)檢查”(又稱“上線前檢查”)?
在將代碼引入倉(cāng)庫(kù)并觸發(fā)持續(xù)集成之前,可以進(jìn)行其它驗(yàn)證。這遵循了最佳實(shí)踐,例如測(cè)試構(gòu)建test build和代碼審查code review。它們通常在代碼引入管道之前構(gòu)建到開發(fā)過(guò)程中。但是一些管道也可能將它們作為其監(jiān)控流程或工作流的一部分。
例如,一個(gè)名為?Gerrit?的工具允許在開發(fā)人員推送代碼之后但在允許進(jìn)入(Git?遠(yuǎn)程)倉(cāng)庫(kù)之前進(jìn)行正式的代碼審查、驗(yàn)證和測(cè)試構(gòu)建。Gerrit 位于開發(fā)人員的工作區(qū)和 Git 遠(yuǎn)程倉(cāng)庫(kù)之間。它會(huì)“接收”來(lái)自開發(fā)人員的推送,并且可以執(zhí)行通過(guò)/失敗驗(yàn)證以確保它們?cè)诒辉试S進(jìn)入倉(cāng)庫(kù)之前的檢查是通過(guò)的。這可以包括檢測(cè)新變更并啟動(dòng)構(gòu)建測(cè)試(CI 的一種形式)。它還允許開發(fā)者在那時(shí)進(jìn)行正式的代碼審查。這種方式有一種額外的可信度評(píng)估機(jī)制,即當(dāng)變更的代碼被合并到代碼庫(kù)中時(shí)不會(huì)破壞任何內(nèi)容。
什么是“單元測(cè)試”?
單元測(cè)試(也稱為“提交測(cè)試”),是由開發(fā)人員編寫的小型的專項(xiàng)測(cè)試,以確保新代碼獨(dú)立工作。“獨(dú)立”這里意味著不依賴或調(diào)用其它不可直接訪問(wèn)的代碼,也不依賴外部數(shù)據(jù)源或其它模塊。如果運(yùn)行代碼需要這樣的依賴關(guān)系,那么這些資源可以用模擬mock來(lái)表示。模擬是指使用看起來(lái)像資源的代碼存根code stub,可以返回值,但不實(shí)現(xiàn)任何功能。
在大多數(shù)組織中,開發(fā)人員負(fù)責(zé)創(chuàng)建單元測(cè)試以證明其代碼正確。事實(shí)上,一種稱為測(cè)試驅(qū)動(dòng)開發(fā)test-driven develop(TDD)的模型要求將首先設(shè)計(jì)單元測(cè)試作為清楚地驗(yàn)證代碼功能的基礎(chǔ)。因?yàn)檫@樣的代碼可以更改速度快且改動(dòng)量大,所以它們也必須執(zhí)行很快。
由于這與持續(xù)集成工作流有關(guān),因此開發(fā)人員在本地工作環(huán)境中編寫或更新代碼,并通單元測(cè)試來(lái)確保新開發(fā)的功能或方法正確。通常,這些測(cè)試采用斷言形式,即函數(shù)或方法的給定輸入集產(chǎn)生給定的輸出集。它們通常進(jìn)行測(cè)試以確保正確標(biāo)記和處理出錯(cuò)條件。有很多單元測(cè)試框架都很有用,例如用于 Java 開發(fā)的?JUnit。
什么是“持續(xù)測(cè)試”?
持續(xù)測(cè)試是指在代碼通過(guò)持續(xù)交付管道時(shí)運(yùn)行擴(kuò)展范圍的自動(dòng)化測(cè)試的實(shí)踐。單元測(cè)試通常與構(gòu)建過(guò)程集成,作為持續(xù)集成階段的一部分,并專注于和其它與之交互的代碼隔離的測(cè)試。
除此之外,可以有或者應(yīng)該有各種形式的測(cè)試。這些可包括:
- 集成測(cè)試?驗(yàn)證組件和服務(wù)組合在一起是否正常。
- 功能測(cè)試?驗(yàn)證產(chǎn)品中執(zhí)行功能的結(jié)果是否符合預(yù)期。
- 驗(yàn)收測(cè)試?根據(jù)可接受的標(biāo)準(zhǔn)驗(yàn)證產(chǎn)品的某些特征。如性能、可伸縮性、抗壓能力和容量。
所有這些可能不存在于自動(dòng)化的管道中,并且一些不同類型的測(cè)試分類界限也不是很清晰。但是,在交付管道中持續(xù)測(cè)試的目標(biāo)始終是相同的:通過(guò)持續(xù)的測(cè)試級(jí)別證明代碼的質(zhì)量可以在正在進(jìn)行的發(fā)布中使用。在持續(xù)集成快速的原則基礎(chǔ)上,第二個(gè)目標(biāo)是快速發(fā)現(xiàn)問(wèn)題并提醒開發(fā)團(tuán)隊(duì)。這通常被稱為快速失敗。
除了測(cè)試之外,還可以對(duì)管道中的代碼進(jìn)行哪些其它類型的驗(yàn)證?
除了測(cè)試是否通過(guò)之外,還有一些應(yīng)用程序可以告訴我們測(cè)試用例執(zhí)行(覆蓋)的源代碼行數(shù)。這是一個(gè)可以衡量代碼量指標(biāo)的例子。這個(gè)指標(biāo)稱為代碼覆蓋率code-coverage,可以通過(guò)工具(例如用于 Java 的?JaCoCo)進(jìn)行統(tǒng)計(jì)。
還有很多其它類型的指標(biāo)統(tǒng)計(jì),例如代碼行數(shù)、復(fù)雜度以及代碼結(jié)構(gòu)對(duì)比分析等。諸如?SonarQube?之類的工具可以檢查源代碼并計(jì)算這些指標(biāo)。此外,用戶還可以為他們可接受的“合格”范圍的指標(biāo)設(shè)置閾值。然后可以在管道中針對(duì)這些閾值設(shè)置一個(gè)檢查,如果結(jié)果不在可接受范圍內(nèi),則流程終端上。SonarQube 等應(yīng)用程序具有很高的可配置性,可以設(shè)置僅檢查團(tuán)隊(duì)感興趣的內(nèi)容。
什么是“持續(xù)交付”?
持續(xù)交付(CD)通常是指整個(gè)流程鏈(管道),它自動(dòng)監(jiān)測(cè)源代碼變更并通過(guò)構(gòu)建、測(cè)試、打包和相關(guān)操作運(yùn)行它們以生成可部署的版本,基本上沒有任何人為干預(yù)。
持續(xù)交付在軟件開發(fā)過(guò)程中的目標(biāo)是自動(dòng)化、效率、可靠性、可重復(fù)性和質(zhì)量保障(通過(guò)持續(xù)測(cè)試)。
持續(xù)交付包含持續(xù)集成(自動(dòng)檢測(cè)源代碼變更、執(zhí)行構(gòu)建過(guò)程、運(yùn)行單元測(cè)試以驗(yàn)證變更),持續(xù)測(cè)試(對(duì)代碼運(yùn)行各種測(cè)試以保障代碼質(zhì)量),和(可選)持續(xù)部署(通過(guò)管道發(fā)布版本自動(dòng)提供給用戶)。
如何在管道中識(shí)別/跟蹤多個(gè)版本?
版本控制是持續(xù)交付和管道的關(guān)鍵概念。持續(xù)意味著能夠經(jīng)常集成新代碼并提供更新版本。但這并不意味著每個(gè)人都想要“最新、最好的”。對(duì)于想要開發(fā)或測(cè)試已知的穩(wěn)定版本的內(nèi)部團(tuán)隊(duì)來(lái)說(shuō)尤其如此。因此,管道創(chuàng)建并輕松存儲(chǔ)和訪問(wèn)的這些版本化對(duì)象非常重要。
在管道中從源代碼創(chuàng)建的對(duì)象通常可以稱為工件artifact。工件在構(gòu)建時(shí)應(yīng)該有應(yīng)用于它們的版本。將版本號(hào)分配給工件的推薦策略稱為語(yǔ)義化版本控制semantic versioning。(這也適用于從外部源引入的依賴工件的版本。)
語(yǔ)義版本號(hào)有三個(gè)部分:主要版本major、次要版本minor?和?補(bǔ)丁版本patch。(例如,1.4.3 反映了主要版本 1,次要版本 4 和補(bǔ)丁版本 3。)這個(gè)想法是,其中一個(gè)部分的更改表示工件中的更新級(jí)別。主要版本僅針對(duì)不兼容的 API 更改而遞增。當(dāng)以向后兼容backward-compatible的方式添加功能時(shí),次要版本會(huì)增加。當(dāng)進(jìn)行向后兼容的版本 bug 修復(fù)時(shí),補(bǔ)丁版本會(huì)增加。這些是建議的指導(dǎo)方針,但只要團(tuán)隊(duì)在整個(gè)組織內(nèi)以一致且易于理解的方式這樣做,團(tuán)隊(duì)就可以自由地改變這種方法。例如,每次為發(fā)布完成構(gòu)建時(shí)增加的數(shù)字可以放在補(bǔ)丁字段中。
如何“分銷”工件?
團(tuán)隊(duì)可以為工件分配分銷promotion級(jí)別以指示適用于測(cè)試、生產(chǎn)等環(huán)境或用途。有很多方法。可以用 Jenkins 或?Artifactory?等應(yīng)用程序進(jìn)行分銷。或者一個(gè)簡(jiǎn)單的方案可以在版本號(hào)字符串的末尾添加標(biāo)簽。例如,-snapshot?可以指示用于構(gòu)建工件的代碼的最新版本(快照)。可以使用各種分銷策略或工具將工件“提升”到其它級(jí)別,例如?-milestone?或?-production,作為工件穩(wěn)定性和完備性版本的標(biāo)記。
如何存儲(chǔ)和訪問(wèn)多個(gè)工件版本?
從源代碼構(gòu)建的版本化工件可以通過(guò)管理工件倉(cāng)庫(kù)artifact repository的應(yīng)用程序進(jìn)行存儲(chǔ)。工件倉(cāng)庫(kù)就像構(gòu)建工件的版本控制工具一樣。像 Artifactory 或?Nexus?這類應(yīng)用可以接受版本化工件,存儲(chǔ)和跟蹤它們,并提供檢索的方法。
管道用戶可以指定他們想要使用的版本,并在這些版本中使用管道。
什么是“持續(xù)部署”?
持續(xù)部署(CD)是指能夠自動(dòng)提供持續(xù)交付管道中發(fā)布版本給最終用戶使用的想法。根據(jù)用戶的安裝方式,可能是在云環(huán)境中自動(dòng)部署、app 升級(jí)(如手機(jī)上的應(yīng)用程序)、更新網(wǎng)站或只更新可用版本列表。
這里的一個(gè)重點(diǎn)是,僅僅因?yàn)榭梢赃M(jìn)行持續(xù)部署并不意味著始終部署來(lái)自管道的每組可交付成果。它實(shí)際上指,通過(guò)管道每套可交付成果都被證明是“可部署的”。這在很大程度上是由持續(xù)測(cè)試的連續(xù)級(jí)別完成的(參見本文中的持續(xù)測(cè)試部分)。
管道構(gòu)建的發(fā)布成果是否被部署可以通過(guò)人工決策,或利用在完全部署之前“試用”發(fā)布的各種方法來(lái)進(jìn)行控制。
在完全部署到所有用戶之前,有哪些方法可以測(cè)試部署?
由于必須回滾/撤消對(duì)所有用戶的部署可能是一種代價(jià)高昂的情況(無(wú)論是技術(shù)上還是用戶的感知),已經(jīng)有許多技術(shù)允許“嘗試”部署新功能并在發(fā)現(xiàn)問(wèn)題時(shí)輕松“撤消”它們。這些包括:
藍(lán)/綠測(cè)試/部署
在這種部署軟件的方法中,維護(hù)了兩個(gè)相同的主機(jī)環(huán)境 —— 一個(gè)“藍(lán)色” 和一個(gè)“綠色”。(顏色并不重要,僅作為標(biāo)識(shí)。)對(duì)應(yīng)來(lái)說(shuō),其中一個(gè)是“生產(chǎn)環(huán)境”,另一個(gè)是“預(yù)發(fā)布環(huán)境”。
在這些實(shí)例的前面是調(diào)度系統(tǒng),它們充當(dāng)產(chǎn)品或應(yīng)用程序的客戶“網(wǎng)關(guān)”。通過(guò)將調(diào)度系統(tǒng)指向藍(lán)色或綠色實(shí)例,可以將客戶流量引流到期望的部署環(huán)境。通過(guò)這種方式,切換指向哪個(gè)部署實(shí)例(藍(lán)色或綠色)對(duì)用戶來(lái)說(shuō)是快速,簡(jiǎn)單和透明的。
當(dāng)新版本準(zhǔn)備好進(jìn)行測(cè)試時(shí),可以將其部署到非生產(chǎn)環(huán)境中。在經(jīng)過(guò)測(cè)試和批準(zhǔn)后,可以更改調(diào)度系統(tǒng)設(shè)置以將傳入的線上流量指向它(因此它將成為新的生產(chǎn)站點(diǎn))。現(xiàn)在,曾作為生產(chǎn)環(huán)境實(shí)例可供下一次候選發(fā)布使用。
同理,如果在最新部署中發(fā)現(xiàn)問(wèn)題并且之前的生產(chǎn)實(shí)例仍然可用,則簡(jiǎn)單的更改可以將客戶流量引流回到之前的生產(chǎn)實(shí)例 —— 有效地將問(wèn)題實(shí)例“下線”并且回滾到以前的版本。然后有問(wèn)題的新實(shí)例可以在其它區(qū)域中修復(fù)。
金絲雀測(cè)試/部署
在某些情況下,通過(guò)藍(lán)/綠發(fā)布切換整個(gè)部署可能不可行或不是期望的那樣。另一種方法是為金絲雀canary測(cè)試/部署。在這種模型中,一部分客戶流量被重新引流到新的版本部署中。例如,新版本的搜索服務(wù)可以與當(dāng)前服務(wù)的生產(chǎn)版本一起部署。然后,可以將 10% 的搜索查詢引流到新版本,以在生產(chǎn)環(huán)境中對(duì)其進(jìn)行測(cè)試。
如果服務(wù)那些流量的新版本沒問(wèn)題,那么可能會(huì)有更多的流量會(huì)被逐漸引流過(guò)去。如果仍然沒有問(wèn)題出現(xiàn),那么隨著時(shí)間的推移,可以對(duì)新版本增量部署,直到 100% 的流量都調(diào)度到新版本。這有效地“更替”了以前版本的服務(wù),并讓新版本對(duì)所有客戶生效。
功能開關(guān)
對(duì)于可能需要輕松關(guān)掉的新功能(如果發(fā)現(xiàn)問(wèn)題),開發(fā)人員可以添加功能開關(guān)feature toggles。這是代碼中的?if-then?軟件功能開關(guān),僅在設(shè)置數(shù)據(jù)值時(shí)才激活新代碼。此數(shù)據(jù)值可以是全局可訪問(wèn)的位置,部署的應(yīng)用程序?qū)z查該位置是否應(yīng)執(zhí)行新代碼。如果設(shè)置了數(shù)據(jù)值,則執(zhí)行代碼;如果沒有,則不執(zhí)行。
這為開發(fā)人員提供了一個(gè)遠(yuǎn)程“終止開關(guān)”,以便在部署到生產(chǎn)環(huán)境后發(fā)現(xiàn)問(wèn)題時(shí)關(guān)閉新功能。
暗箱發(fā)布
在暗箱發(fā)布dark launch中,代碼被逐步測(cè)試/部署到生產(chǎn)環(huán)境中,但是用戶不會(huì)看到更改(因此名稱中有暗箱dark一詞)。例如,在生產(chǎn)版本中,網(wǎng)頁(yè)查詢的某些部分可能會(huì)重定向到查詢新數(shù)據(jù)源的服務(wù)。開發(fā)人員可收集此信息進(jìn)行分析,而不會(huì)將有關(guān)接口,事務(wù)或結(jié)果的任何信息暴露給用戶。
這個(gè)想法是想獲取候選版本在生產(chǎn)環(huán)境負(fù)載下如何執(zhí)行的真實(shí)信息,而不會(huì)影響用戶或改變他們的經(jīng)驗(yàn)。隨著時(shí)間的推移,可以調(diào)度更多負(fù)載,直到遇到問(wèn)題或認(rèn)為新功能已準(zhǔn)備好供所有人使用。實(shí)際上功能開關(guān)標(biāo)志可用于這種暗箱發(fā)布機(jī)制。
什么是“運(yùn)維開發(fā)”?
運(yùn)維開發(fā)DevOps?是關(guān)于如何使開發(fā)和運(yùn)維團(tuán)隊(duì)更容易合作開發(fā)和發(fā)布軟件的一系列想法和推薦的實(shí)踐。從歷史上看,開發(fā)團(tuán)隊(duì)研發(fā)了產(chǎn)品,但沒有像客戶那樣以常規(guī)、可重復(fù)的方式安裝/部署它們。在整個(gè)周期中,這組安裝/部署任務(wù)(以及其它支持任務(wù))留給運(yùn)維團(tuán)隊(duì)負(fù)責(zé)。這經(jīng)常導(dǎo)致很多混亂和問(wèn)題,因?yàn)檫\(yùn)維團(tuán)隊(duì)在后期才開始介入,并且必須在短時(shí)間內(nèi)完成他們的工作。同樣,開發(fā)團(tuán)隊(duì)經(jīng)常處于不利地位 —— 因?yàn)樗麄儧]有充分測(cè)試產(chǎn)品的安裝/部署功能,他們可能會(huì)對(duì)該過(guò)程中出現(xiàn)的問(wèn)題感到驚訝。
這往往導(dǎo)致開發(fā)和運(yùn)維團(tuán)隊(duì)之間嚴(yán)重脫節(jié)和缺乏合作。DevOps 理念主張是貫穿整個(gè)開發(fā)周期的開發(fā)和運(yùn)維綜合協(xié)作的工作方式,就像持續(xù)交付那樣。
持續(xù)交付如何與運(yùn)維開發(fā)相交?
持續(xù)交付管道是幾個(gè) DevOps 理念的實(shí)現(xiàn)。產(chǎn)品開發(fā)的后期階段(如打包和部署)始終可以在管道的每次運(yùn)行中完成,而不是等待產(chǎn)品開發(fā)周期中的特定時(shí)間。同樣,從開發(fā)到部署過(guò)程中,開發(fā)和運(yùn)維都可以清楚地看到事情何時(shí)起作用,何時(shí)不起作用。要使持續(xù)交付管道循環(huán)成功,不僅要通過(guò)與開發(fā)相關(guān)的流程,還要通過(guò)與運(yùn)維相關(guān)的流程。
說(shuō)得更遠(yuǎn)一些,DevOps 建議實(shí)現(xiàn)管道的基礎(chǔ)架構(gòu)也會(huì)被視為代碼。也就是說(shuō),它應(yīng)該自動(dòng)配置、可跟蹤、易于修改,并在管道發(fā)生變化時(shí)觸發(fā)新一輪運(yùn)行。這可以通過(guò)將管道實(shí)現(xiàn)為代碼來(lái)完成。
什么是“管道即代碼”?
管道即代碼pipeline-as-code是通過(guò)編寫代碼創(chuàng)建管道作業(yè)/任務(wù)的通用術(shù)語(yǔ),就像開發(fā)人員編寫代碼一樣。它的目標(biāo)是將管道實(shí)現(xiàn)表示為代碼,以便它可以與代碼一起存儲(chǔ)、評(píng)審、跟蹤,如果出現(xiàn)問(wèn)題并且必須終止管道,則可以輕松地重建。有幾個(gè)工具允許這樣做,如?Jenkins 2。
DevOps 如何影響生產(chǎn)軟件的基礎(chǔ)設(shè)施?
傳統(tǒng)意義上,管道中使用的各個(gè)硬件系統(tǒng)都有配套的軟件(操作系統(tǒng)、應(yīng)用程序、開發(fā)工具等)。在極端情況下,每個(gè)系統(tǒng)都是手工設(shè)置來(lái)定制的。這意味著當(dāng)系統(tǒng)出現(xiàn)問(wèn)題或需要更新時(shí),這通常也是一項(xiàng)自定義任務(wù)。這種方法違背了持續(xù)交付的基本理念,即具有易于重現(xiàn)和可跟蹤的環(huán)境。
多年來(lái),很多應(yīng)用被開發(fā)用于標(biāo)準(zhǔn)化交付(安裝和配置)系統(tǒng)。同樣,虛擬機(jī)virtual machine被開發(fā)為模擬在其它計(jì)算機(jī)之上運(yùn)行的計(jì)算機(jī)程序。這些 VM 要有管理程序才能在底層主機(jī)系統(tǒng)上運(yùn)行,并且它們需要自己的操作系統(tǒng)副本才能運(yùn)行。
后來(lái)有了容器container。容器雖然在概念上與 VM 類似,但工作方式不同。它們只需使用一些現(xiàn)有的操作系統(tǒng)結(jié)構(gòu)來(lái)劃分隔離空間,而不需要運(yùn)行單獨(dú)的程序和操作系統(tǒng)的副本。因此,它們的行為類似于 VM 以提供隔離但不需要過(guò)多的開銷。
VM 和容器是根據(jù)配置定義創(chuàng)建的,因此可以輕易地銷毀和重建,而不會(huì)影響運(yùn)行它們的主機(jī)系統(tǒng)。這允許運(yùn)行管道的系統(tǒng)也可重建。此外,對(duì)于容器,我們可以跟蹤其構(gòu)建定義文件的更改 —— 就像對(duì)源代碼一樣。
因此,如果遇到 VM 或容器中的問(wèn)題,我們可以更容易、更快速地銷毀和重建它們,而不是在當(dāng)前環(huán)境嘗試調(diào)試和修復(fù)。
這也意味著對(duì)管道代碼的任何更改都可以觸發(fā)管道新一輪運(yùn)行(通過(guò) CI),就像對(duì)代碼的更改一樣。這是 DevOps 關(guān)于基礎(chǔ)架構(gòu)的核心理念之一。
總結(jié)
以上是生活随笔為你收集整理的什么是 CI/CD? (持续集成/持续交付)的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 雷神1
- 下一篇: 求一个带小仙女的游戏名字!