持續(xù)交付和持續(xù)集成遠遠不只是流行語或新興趨勢。自動化的發(fā)展勢不可擋，特別是在DevOps領(lǐng)域。但是，來年CI / CD將如何發(fā)展？為什么持續(xù)交付軟件如此重要？對于2020年的大型持續(xù)交付專家檢查，我們就這些主題和其他主題向該領(lǐng)域的7名受尊敬的專家進行了詢問。在我們的專家檢查的第一部分中，查看哪些最佳實踐可以幫助確保安全性，以及我們的專家更喜歡哪種部署類型-藍色/綠色部署或滾動部署？

JAXenter：持續(xù)交付是每個DevOps努力的關(guān)鍵組成部分。您為什么認為它起著如此重要的作用？

特雷西·米蘭達（Tracy Miranda）：最近有一位朋友分享說，他正在更換銀行，因為他過去常常很難通過銀行進行網(wǎng)上轉(zhuǎn)賬。對我來說，這是一個生動的例子，說明軟件已成為大多數(shù)行業(yè)的主要差異化因素。如今，大多數(shù)企業(yè)都需要弄清楚如何更快地交付新功能，同時又要確保服務(wù)的牢固性和安全性-這就是持續(xù)交付的意義所在，以及為什么今天如此重要。

Priyanka Sharma：現(xiàn)在每個公司都是一家軟件公司。技術(shù)贏家和輸家的最重要決定因素是軟件交付和迭代的速度。通過利用連續(xù)交付，工程團隊可以準備要生產(chǎn)的功能，然后通過隱喻性地單擊按鈕即可將其投入使用。根據(jù)我與GitLab客戶交談的經(jīng)驗以及GitLab自己的工程實踐，人們可以從幾周或幾個月一次部署到每天持續(xù)交付。

Clark Boylan：持續(xù)交付可確保您的軟件始終可發(fā)布。這使您可以制作許多易于使用的小型發(fā)行版，而不是需要大量部署的大型發(fā)行版。這樣可以更輕松地發(fā)現(xiàn)發(fā)生故障的地方以及在必要時的位置。最終結(jié)果是可靠性和一致性。

Baruch Sadogursky：有一個簡單的答案，一個更有趣的答案。簡單的答案是，當(dāng)我們談?wù)撓系K并改善團隊內(nèi)部的整合時，消除孤島意味著更快地行動。加快速度的關(guān)鍵方面之一是消除手工工作并使所有工作自動化。持續(xù)交付是動員軟件交付的關(guān)鍵組成部分。我會說，更有趣的方面是，它以幫助提供價值的方式為DevOps做出了貢獻。DevOps的最終業(yè)務(wù)目標(biāo)是提供價值，持續(xù)交付可以改善價值的兩個方面。

首先，它有助于專注于價值本身，新工作以及對客戶重要的事情。消除了手工和繁瑣的工作，最大程度地減少了錯誤，提高了質(zhì)量。最終，人們在沒有價值的工作上花費的時間更少。持續(xù)交付的另一個觀點是，它可以快速提供價值。今天，在我們這個非?？量痰氖袌鲋?，提供價值比競爭對手更快的組織贏得了勝利。這就是為什么連續(xù)交付有助于提供更好的結(jié)果的原因。

這對于提高安全性也很重要，因為緩解安全漏洞的步驟之一就是將補丁交付到系統(tǒng)的速度。再說一次，誰能更快地交付這些補丁，誰就會比其他人更好，更快地生產(chǎn)。

JoonasLehtim?ki：如今，公司要想在業(yè)務(wù)上取得成功就必須快速高效。我認為，舊數(shù)據(jù)中心/系統(tǒng)管理員的手動工作已經(jīng)結(jié)束。公司需要一種方法可以在任何地方（一天可能多次）可靠地交付軟件，而CD在其中起著重要的作用。

尼爾·科倫（Nir Koren）：我認為當(dāng)今的開發(fā)人員真的不希望花費大量時間手動部署到所有環(huán)境，而是希望在云上即時開發(fā)并觀察成果。從公司的角度來看，這絕對是交付速度（包括功能和錯誤修復(fù)）。

Christian Uhl：持續(xù)交付的自動化方面使團隊擺脫了以前存在的許多運營負擔(dān)。這使我們能夠?qū)⒋罅繒r間重新投入到更有價值的活動中。但這只是冰山一角-成功實施連續(xù)交付將為企業(yè)帶來純凈且可衡量的競爭優(yōu)勢。降低風(fēng)險和縮短上市時間是每個組織都應(yīng)在這方面努力變得更好的原因。

JAXenter：持續(xù)交付是談?wù)摮掷m(xù)提供軟件時最常用的術(shù)語，但是也存在持續(xù)部署和持續(xù)集成的問題。你最喜歡什么風(fēng)格？為什么？

特雷西·米蘭達（Tracy Miranda）：可以肯定的是，有關(guān)條款一直存在困惑。在理想的情況下，持續(xù)集成和持續(xù)部署是軟件交付生命周期中的全自動部分。完全自動化很難實現(xiàn)或受到法規(guī)要求等限制。對于連續(xù)交付，重點是工程方法，團隊可以在短時間內(nèi)生產(chǎn)軟件，以確?？梢噪S時可靠地發(fā)布軟件。重點似乎發(fā)生了微妙的變化，但實際上卻有所不同，因為重點現(xiàn)在已經(jīng)很容易地包含了人為因素和團隊在軟件交付中的關(guān)鍵作用。

Priyanka Sharma：持續(xù)集成，交付和部署都是同一過程的一部分，以加快軟件生命周期。讓我們定義每個以確保我們理解這些術(shù)語。

持續(xù)集成：這是開發(fā)人員每天定期且有規(guī)律地將代碼合并到master分支中，而不用等待“發(fā)布日”。為了成功做到這一點，大多數(shù)組織利用持續(xù)集成管道，通過創(chuàng)建構(gòu)建并針對該構(gòu)建運行自動化測試來驗證開發(fā)人員的更改。盡管運行自動化測試不是持續(xù)集成管道的前提條件，但這是最佳實踐。GitLab是持續(xù)集成管道的狂熱用戶（和提供者）。

連續(xù)交付：組織運行連續(xù)集成后，他們還可以自動化其發(fā)布過程，從而只需單擊一下按鈕即可進行部署。對于希望快速敏捷的公司，但由于法規(guī)或業(yè)務(wù)原因而無法進行連續(xù)部署的公司，連續(xù)交付是一個不錯的選擇。GitLab屬于這一類，因為我們需要手動部署（每天進行一次）以滿足合規(guī)性要求。

持續(xù)部署：當(dāng)組織具有持續(xù)集成和交付的功能時，他們可以通過部署來自動化整個過程，而無需人工干預(yù)。持續(xù)部署是軟件開發(fā)人員的必殺技，因為推送到生產(chǎn)的提交不會上線的唯一原因是測試失敗。對于許多公司而言，由于合規(guī)性原因，完全自動化是不可行的，對于他們而言，連續(xù)交付是次之。

克拉克·博伊蘭（Clark Boylan）：這三個因素共同作用，并且是運轉(zhuǎn)良好的機器的必要組件。持續(xù)集成是您的第一道防線。在這里，您要盡早發(fā)現(xiàn)問題，最好是在合并代碼提交之前在更改合并之前發(fā)現(xiàn)問題。假設(shè)提交了CI Gates代碼，則您的軟件分支應(yīng)始終處于接近可釋放的狀態(tài)。這有助于持續(xù)交付，因為使發(fā)布所需的工作量最小化，從而實現(xiàn)了發(fā)布過程的自動化。最后，您的持續(xù)部署自動化可以消耗您持續(xù)集成和交付工具的輸出，直接進入生產(chǎn)。每層以非?；パa的方式饋入下一層。

Baruch Sadogursky：在這里我要說的是，它們并不是同一事物的不同風(fēng)格。它們是連續(xù)管道的逐漸演變。連續(xù)集成是通過以非?？斓乃俣茸詣舆M行連續(xù)集成來消除手動，繁瑣和容易出錯的工作的一項。持續(xù)交付通過將發(fā)行版本交付給目標(biāo)服務(wù)器來自動化另一個繁瑣的過程。持續(xù)部署是向前發(fā)展的一步。現(xiàn)在，我們不僅可以持續(xù)制作發(fā)行版，并且能夠?qū)l(fā)行版交付給目標(biāo)服務(wù)器，而且實際上，我們每次都可以連續(xù)進行發(fā)行，從而省去了另一個手動步驟。

因此，很難回答這個問題。我最喜歡什么？它們顯然都有價值，它們都是必需的。有人可以說，持續(xù)部署應(yīng)該代替持續(xù)交付。我傾向于同意。手動步驟越少越好。但是持續(xù)集成絕對不是偏好問題。持續(xù)集成是強制性的；這是持續(xù)交付和持續(xù)部署的一部分。

現(xiàn)在，您在問題中沒有提到另一個連續(xù)的問題，但是我想提出：連續(xù)更新。這是連續(xù)部署后的下一步發(fā)展步驟。所不同的是，我們現(xiàn)在知道，不僅我們將新軟件部署到服務(wù)器上，而且實際上將對現(xiàn)有服務(wù)器的更新部署到任何邊緣設(shè)備上。那可能是您自己在Prem或云中控制的服務(wù)器，也可能是我們無法控制的邊緣設(shè)備，例如移動設(shè)備，IoT設(shè)備，基站塔中的計算代理。

所有這些都是需要更新的方面，并且顯然可以應(yīng)用通常的持續(xù)集成技術(shù)，但是您需要超越持續(xù)交付和持續(xù)部署的范圍，并實際實施持續(xù)更新。所有這些都是進化，并且大多數(shù)都包含在另一個之中。因此，這實際上不是個人喜好或風(fēng)格的問題。

JoonasLehtim?ki：是的，有很多術(shù)語，我經(jīng)常發(fā)現(xiàn)人們感到困惑。我通常喜歡使用整個CI / CD術(shù)語，因為如果我們僅談?wù)撨B續(xù)部署，那么它僅涵蓋軟件管道的部署階段。持續(xù)集成執(zhí)行自動化測試，構(gòu)建以及將軟件部署到生產(chǎn)之前所需的任何軟件。

Nir Koren：持續(xù)集成是所有人的基礎(chǔ)。沒有健壯和適當(dāng)?shù)腃I，您將沒有CD（交付/部署）。我最喜歡的方法是“連續(xù)部署”（在其中具有包括生產(chǎn)部署在內(nèi)的全自動化流程），因為它會迫使您提供更穩(wěn)定，更健壯的環(huán)境和測試框架，并使生產(chǎn)更加動態(tài)。持續(xù)部署使開發(fā)人員具有能力，并使他對整個過程負責(zé)。

克里斯蒂安·烏爾（Christian Uhl）：我不會稱其為不同的樣式，而是更多的概念相互依存–持續(xù)集成是持續(xù)交付的要求，這是持續(xù)部署的基礎(chǔ)。

JAXenter：就交付軟件而言，安全性也是一個非常重要的主題–我們的應(yīng)用程序不僅應(yīng)盡快可用，而且應(yīng)盡可能安全。關(guān)于如何在CI / CD管道中實施安全方面，是否有最佳實踐？

特雷西·米蘭達（Tracy Miranda）：指導(dǎo)原則是“在安全性上左移”，這在《加速》一書（軟件交付的圣經(jīng)）中得到了很好的總結(jié)，該書討論了將安全性集成到軟件開發(fā)的設(shè)計和測試階段。此外，還有許多安全原則可應(yīng)用于您的特定CI / CD管道和環(huán)境。例如，對于云原生CI / CD管道，Cosmin Cojocar進行了精彩的演講，概述了原理，例如建立安全默認值，最小化攻擊面–然后通過使用配置作為代碼，隔離集群，給出了使用Jenkins X的特定方法。等等。我強烈建議您先了解一下這些原理，然后研究如何將這些原理應(yīng)用到您的設(shè)置中。

普里揚卡·沙瑪（Priyanka Sharma）：絕對！如果我們回想一下新聞中最近發(fā)生的安全漏洞，在大多數(shù)情況下，它們并不是復(fù)雜攻擊的結(jié)果。相反，它們是團隊出于各種原因而無法遵循最佳實踐的情況。因此，至關(guān)重要的是將安全性納入CI / CD管道中，以便開發(fā)人員可以在常規(guī)部署中檢查問題。這使得安全問題與其他類型的失敗測試或錯誤相差無幾，因為它在提交和合并代碼時發(fā)生。

管道中可以包含安全測試和掃描的許多元素。這是一個清單：

1. SAST –靜態(tài)應(yīng)用程序安全測試–在部署之前掃描應(yīng)用程序源代碼和二進制文件以發(fā)現(xiàn)潛在漏洞

2. DAST –動態(tài)應(yīng)用程序安全測試–通過運行實時攻擊來分析運行中的Web應(yīng)用程序是否存在已知的運行時漏洞

3. IAST –交互式應(yīng)用程序安全性測試通過檢測代碼并檢查錯誤條件來檢查應(yīng)用程序的運行時行為

4. 依賴項掃描會分析外部依賴項（例如Ruby gems之類的庫），以了解每次代碼提交時的已知漏洞

5. 容器掃描檢查Docker映像中應(yīng)用程序環(huán)境中的已知漏洞

6. 許可證合規(guī)性根據(jù)代碼提交搜索項目依賴性，以檢查每個項目的自定義策略定義的已批準和列入黑名單的許可證

Clark Boylan： CI / CD管道中的安全性必須從CI / CD系統(tǒng)本身的安全性開始。我們看到像Zuul這樣的專用CI / CD工具假定開發(fā)人員不一定值得信任，并以此為基礎(chǔ)建立了安全模型。這有助于確保CI / CD系統(tǒng)不是安全威脅模型中的薄弱環(huán)節(jié)。除此之外，由受信任的人員執(zhí)行的代碼審查和自動化工具可以協(xié)同工作，以防止將不安全的更改合并到您的軟件中。

Baruch Sadogursky：保護應(yīng)用程序安全需要持續(xù)交付，持續(xù)部署和持續(xù)更新。將補丁發(fā)布到設(shè)備的速度越快，您的安全性就越高。另一方面是管道本身的安全性。我們已經(jīng)看到了很多供應(yīng)鏈的示例，這些示例是您連續(xù)不斷的管道中的一部分，受到了攻擊。我們行業(yè)中有一些公司可以保護您的管道和供應(yīng)鏈。您不能忘記這方面，因為它實際上是通過管道將可行的組件帶入產(chǎn)品中。因此，是的，您的供應(yīng)鏈安全是一個重要的方面，需要考慮，資助和實施。

JoonasLehtim?ki：從體系結(jié)構(gòu)規(guī)劃到生產(chǎn)，都應(yīng)考慮安全性。您可以在管道中快速使用每個可以快速運行和自動化的安全工具，例如，使用Clair掃描圖像，然后將其用于登臺/生產(chǎn)環(huán)境。

Nir Koren：除了顯而易見的手動代碼審查和安全檢查之外，我們使用WhiteSource之類的自動靜態(tài)代碼分析，并不斷尋求其他方法來保護我們的產(chǎn)品。

Christian Uhl：可以通過構(gòu)建SAST（靜態(tài)應(yīng)用程序安全測試）和DAST（動態(tài)應(yīng)用程序安全測試）來很好地抓住成果和明顯的錯誤。此外，我們可以（并且確實）包含將在發(fā)布更新后自動更新依賴項的服務(wù)。這為我們提供了一個盡可能最新的系統(tǒng)，并且我們不會錯過產(chǎn)品所有級別的安全補丁。每天部署10次時，更多的依賴關(guān)系更新部署將不再起作用。在代碼檢查過程中包括安全性最佳實踐也可以幫助我們發(fā)現(xiàn)問題。但是，老實說，我們?nèi)匀粫贑I / CD管道之外對系統(tǒng)/滲透測試進行手動安全審核，因為總是存在未知的問題。

JAXenter：藍色/綠色部署和滾動部署之間有什么區(qū)別？你更傾向哪個？

特雷西·米蘭達（Tracy Miranda）：我喜歡我的同事Viktor Farcic如何將藍色/綠色部署描述為“骯臟的”部署策略。在部署前的虛擬機，Docker和Kubernetes時代，這種策略很有意義，因此最好還是讓舊版本并行運行，以防萬一。借助現(xiàn)代應(yīng)用程序和Kubernetes等云原生平臺，滾動和Canary部署在成本效益，高可用性，響應(yīng)能力等方面更具意義。有關(guān)為您的用例選擇最佳部署策略的更多信息，我強烈建議您最近使用Viktor在FOSDEM上有關(guān)“選擇正確的部署策略”的演講。

普里揚卡·沙爾瑪（Priyanka Sharma）：藍色/綠色和滾動部署是組織將新功能發(fā)布到生產(chǎn)中的兩種方法。藍色/綠色部署意味著應(yīng)用程序有兩個環(huán)境，其中負載均衡器用于將流量從一個環(huán)境路由到另一個環(huán)境。藍色環(huán)境是代碼的原始版本，綠色是新版本。一旦綠色環(huán)境通過所有測試，負載均衡器便可以將流量從藍色重定向到綠色，并且如果存在任何錯誤或問題，則可以將流量重定向回藍色環(huán)境。滾動部署是指新版本的應(yīng)用程序以增量方式逐漸替換舊版本的應(yīng)用程序。新版本和舊版本共存而不影響功能或用戶體驗。通過此過程，可以更輕松地回滾與舊組件不兼容的任何新組件。

Clark Boylan：在我們的世界中，重點是項目門控。這意味著我們在合并之前檢查每個提交，以確保它不會引入回歸和錯誤。這個想法是為了避免生產(chǎn)中的問題?，F(xiàn)實是，仍有一些問題仍會解決，這在藍色/綠色或滾動部署可能會有所幫助。在藍/綠部署中，您將在新環(huán)境和舊環(huán)境之間部署第二個環(huán)境。一旦測試表明新環(huán)境正在運行，您就可以在生產(chǎn)環(huán)境中切換到新環(huán)境。

通過滾動部署，您可以一次更換系統(tǒng)的一小部分，從而可以及早發(fā)現(xiàn)任何錯誤，并在必要時進行回滾。在這里，策略的選擇通常取決于所部署的軟件。整體軟件通常更適合藍/綠色部署，因為它無法分解為較小的部分。基于微服務(wù)的可輕松替換的軟件使?jié)L動部署成為一個不錯的選擇。

Baruch Sadogursky：向這些平臺交付將為您帶來新的機會。當(dāng)我們談?wù)撊萜骱蜔o服務(wù)器時，我們所談?wù)摰氖禽p量級更新，這些更新可以替代以前使用的較重的服務(wù)器部署或虛擬機設(shè)置?，F(xiàn)在，當(dāng)我們需要替換或更新應(yīng)用程序的一部分時，我們實際上可以實現(xiàn)連續(xù)更新，而僅實現(xiàn)系統(tǒng)的一小部分。只有一個圖像會縮放到容器，只有一個lambda會縮放，這在我們的無服務(wù)器應(yīng)用程序中是微服務(wù)。交付較小的零件可以使我們更快地更新。這就是幫助更快地帶來價值并幫助應(yīng)用程序更安全的原因。容器，Kubernetes和無服務(wù)器是個好消息，因為它們使我們能夠從持續(xù)部署和持續(xù)交付整體組件到持續(xù)更新微服務(wù)的較小部分。

JoonasLehtim?ki：主要區(qū)別在于，藍色/綠色部署有兩種環(huán)境，而滾動部署只有一種。藍/綠被認為是一種較安全的實施選擇，但它有一些開銷。在藍/綠部署中，您將啟動一個較新版本的環(huán)境，然后開始緩慢地負載平衡該環(huán)境的流量。部署結(jié)束后，將保留或終止舊環(huán)境。然后，滾動部署將使用一種環(huán)境，并開始一個接一個地殺死和旋轉(zhuǎn)實例，直到所有實例都處于最新版本。對我來說，我更喜歡滾動更新，但這全部取決于軟件和SLA的需求。

克里斯蒂安·烏爾（Christian Uhl）：簡短而又不詳盡的解釋是：藍色/綠色表示并行運行部署的舊版本和新版本，使實例增加一倍。在某些時候，您需要將某些路由從舊路由切換到新路由。系統(tǒng)的使用者可以看到一個或另一個版本。對于滾動式部署，您需要具有多個部署實例，并且一次更改/更新一個實例–因此，在部署期間，消費者有時會看到舊版本，有時會看到新版本。

兩者都有優(yōu)點和缺點：對于有狀態(tài)服務(wù)（例如數(shù)據(jù)庫），我更喜歡藍色/綠色，以避免一致性問題。使用滾動部署可以更快地部署無狀態(tài)組件，并減少資源分配。這樣，當(dāng)新系統(tǒng)中發(fā)生太多錯誤而所有用戶都沒有受到影響時，就可以放棄部署。