微服務(wù)的部署與發(fā)布：持續(xù)交付與持續(xù)部署微服務(wù)
持續(xù)交付與持續(xù)部署微服務(wù)
持續(xù)集成(Continuous Integration）與持續(xù)交付(Continuous Delivery )、持續(xù)部署（ContinuousDeployment）作為敏捷開發(fā)實(shí)踐，可以及早發(fā)現(xiàn)、解決問題，從而更早地將產(chǎn)品交付給客戶。及早地從客戶那里得到反饋，就可以及早地對產(chǎn)品進(jìn)行修復(fù)和完善，交付更加完美的產(chǎn)品給客戶，最終形成了良好的可以持續(xù)的閉環(huán)。
什么是持續(xù)交付與持續(xù)部署
持續(xù)集成是持續(xù)交付和持續(xù)部署的基礎(chǔ)。持續(xù)集成使得整個開發(fā)團(tuán)隊(duì)保持一致，消除了集成所引起的問題的延期。雖然持續(xù)集成使得代碼可以快速合并到主干中，但此時軟件仍然是未在生成環(huán)境中進(jìn)行實(shí)際使用過的。軟件的功能是否正常，功能是否符合用戶的需求，這在持續(xù)集成階段仍然是未知的。只有將軟件部署到了生成環(huán)境，交付給用戶使用之后，才能檢驗(yàn)出軟件真正的價值。而持續(xù)交付與持續(xù)部署的實(shí)踐，正是從持續(xù)集成到“最后一公里”的保障。
所謂交付，就是將最終的產(chǎn)品發(fā)布到線上環(huán)境，提供給用戶使用。對于一個微服務(wù)架構(gòu)系統(tǒng)來說，將一個應(yīng)用拆分成多個獨(dú)立的服務(wù)，每個服務(wù)都具有業(yè)務(wù)屬性，并且能獨(dú)立地被開發(fā)、測試、構(gòu)建、部署。換言之，每個服務(wù)都是一個可交付的產(chǎn)品。那么在這種細(xì)粒度的情況下，如何有效保障每個服務(wù)的交付效率，快速實(shí)現(xiàn)其業(yè)務(wù)價值，是擺在微服務(wù)面前的一個難題。
而持續(xù)交付是一系列的開發(fā)實(shí)踐方法，用來確保代碼能夠快速、安全地部署到產(chǎn)品環(huán)境中，它通過將每一次改動都提交到一個模擬產(chǎn)品環(huán)境中，使用嚴(yán)格的自動化測試，確保業(yè)務(wù)應(yīng)用和服務(wù)能符合預(yù)期。因?yàn)槭褂猛耆淖詣踊^程來把每個變更自動提交到測試環(huán)境中，所以當(dāng)業(yè)務(wù)開發(fā)完成時，你有信心只需要按一次按鈕，就能將應(yīng)用安全地部署到生產(chǎn)環(huán)境中。
而持續(xù)部署是持續(xù)交付的更高一級的階段。即當(dāng)所有代碼所有的改動都通過了自動化測試之后，都能夠自動地部署到生產(chǎn)環(huán)境里。持續(xù)發(fā)布與持續(xù)部署一個重要的差別在于，持續(xù)發(fā)布需要人工來將應(yīng)用部署到生成環(huán)境中（即部署前，應(yīng)用需要人工來校驗(yàn)一遍），而持續(xù)部署則是所有的流程都是自動化的，包括部署到生產(chǎn)環(huán)境的流程。圖11-1很好地描述了持續(xù)發(fā)布與持續(xù)部署之間的差異。
讓我們來探討下一個完整軟件的交付過程。假設(shè)現(xiàn)在需求已經(jīng)明確，并且已經(jīng)被劃分為小的單元模塊，如劃分成用戶故事，讓我們觀察下從開發(fā)人員拿到用戶故事，到這些用戶故事被實(shí)際部署到生產(chǎn)環(huán)境上的這個過程。對于這個過程來說，實(shí)際上時間越短越好，特別是對于那些急需獲得用戶反饋的敏捷開發(fā)方式的軟件產(chǎn)品。如果我們做的每一個用戶故事，甚至是每一次代碼的提交，都能夠被自動地部署到生產(chǎn)環(huán)境中去，那么這種頻繁近乎持續(xù)的部署，對于很多敏捷軟件開發(fā)團(tuán)隊(duì)來說，就成了非常值得追求的目標(biāo)了。
當(dāng)然實(shí)施持續(xù)部署并非沒有投入和成本，如果產(chǎn)品的基礎(chǔ)和特點(diǎn)不同，那么獲得這種狀態(tài)所需要的投入就越大。對于那些缺乏自動化測試覆蓋的遺留系統(tǒng)，以及對安全性要求特別高的產(chǎn)品，它們要實(shí)現(xiàn)持續(xù)部署，甚至是頻繁部署，都需要巨大的投入。但是如果產(chǎn)品所處的市場環(huán)境要求它必須能夠及時做出相應(yīng)的變化，不斷改進(jìn)軟件服務(wù)的話，那么這種持續(xù)部署的能力就成了值得投入的目標(biāo)。
持續(xù)部署，依賴于整個團(tuán)隊(duì)對所寫代碼的自信。這種自信，不僅是開發(fā)人員對自己寫的代碼的自信，更多的是團(tuán)隊(duì)或組織所有成員都抱有的基于客觀事實(shí)的自信。只有建立起這種自信，才能夠讓任何新的修改都能夠迅速地、有信心地部署到生產(chǎn)環(huán)境中。
在自信的基礎(chǔ)上，團(tuán)隊(duì)要實(shí)現(xiàn)產(chǎn)品的持續(xù)部署，還需要建立自動化交付流水線（Pipeline)。
以自動化生產(chǎn)線進(jìn)行對比，自動化測試只是其中一道質(zhì)量保證的工序，而要將產(chǎn)品從需求轉(zhuǎn)變?yōu)樽罱K交付給客戶的產(chǎn)品，自動化生產(chǎn)線是整個開發(fā)過程中極其重要的存在。特別是對于微服務(wù)這種多服務(wù)的產(chǎn)品而言，多個服務(wù)產(chǎn)品往往要集成在一起，才能為客戶提供完整的服務(wù)。多個產(chǎn)品的自動化交付流水線的設(shè)計(jì)也就成了一個很重要的問題。
產(chǎn)品在從需求到部署的過程中，會經(jīng)歷若干種不同的環(huán)境，如QA環(huán)境、各種自動化測試運(yùn)行環(huán)境、生產(chǎn)環(huán)境等。這些環(huán)境的搭建、配置、管理，產(chǎn)品在不同環(huán)境中的具體部署，都需要完善的工具支持。缺乏這些工具，生產(chǎn)流水線就不可能做到完全自動化和高效。與之配套的軟件有Team-City、Jenkins、GoCD等。
持續(xù)交付與持續(xù)部署的意義
總的來說，持續(xù)交付與持續(xù)部署在敏捷開發(fā)過程中，實(shí)現(xiàn)速度、效率、質(zhì)量的軟件開發(fā)實(shí)踐，可以持續(xù)為用戶交付可用的軟件產(chǎn)品。其中包括:
頻繁的交付周期帶來了更迅速的對軟件的反饋。
可以迅速對產(chǎn)品進(jìn)行改進(jìn)，更好地適應(yīng)用戶的需求和市場的變化。
需求分析、產(chǎn)品的用戶體驗(yàn)和交互設(shè)計(jì)、開發(fā)、測試、運(yùn)維等角色密切協(xié)作，相比于傳統(tǒng)的瀑布式軟件團(tuán)隊(duì)，減少了浪費(fèi)。
有力形成了“需求→開發(fā)→集成→測試→部署”的可持續(xù)的反饋閉環(huán)。
什么是持續(xù)交付流水線
在持續(xù)交付中，持續(xù)集成服務(wù)器將把開發(fā)到部署過程中的各個環(huán)節(jié)銜接起來，組成一個自動化的持續(xù)交付流水線，作為整個交付過程的協(xié)調(diào)中樞。依靠持續(xù)集成服務(wù)器，對軟件的修改能夠快速地、自動化地經(jīng)過測試和驗(yàn)證，最后部署到生產(chǎn)環(huán)境中去。在自動化測試和環(huán)境都具備的情況下，集成服務(wù)器可以減少開發(fā)人員大部分的手工工作。流水線應(yīng)向團(tuán)隊(duì)提供反饋，對每個人所參與的錯誤操作進(jìn)行提示。
典型的持續(xù)交付流水線中，大致會經(jīng)歷構(gòu)建自動化和持續(xù)集成、測試自動化和部署自動化等階段。
1.自動化構(gòu)建和持續(xù)集成
開發(fā)人員將實(shí)現(xiàn)的新功能集成到中央代碼庫中，并以此為基礎(chǔ)進(jìn)行持續(xù)的構(gòu)建和單元測試。這是最直接的反饋循環(huán)，持續(xù)交付流水線會通知開發(fā)團(tuán)隊(duì)他們的應(yīng)用程序代碼的健康情況。
2.自動化測試
在這個階段，新版本的應(yīng)用程序?qū)⒔?jīng)過嚴(yán)格測試，以確保它滿足所有期望的系統(tǒng)質(zhì)量。這包括軟件的所有相關(guān)方面，包括功能、安全性、性能等，這些都會由流水線來進(jìn)行驗(yàn)證。該階段可以涉及不同類型的自動或手動活動。
3.自動化部署
每次將應(yīng)用程序安裝在測試環(huán)境前都需要重新部署，但自動化部署最為關(guān)鍵的是自動化部署的時機(jī)。由于前面的階段已經(jīng)驗(yàn)證了系統(tǒng)的整體質(zhì)量，這是一個低風(fēng)險的步驟。部署可以分階段進(jìn)行，新版本最初可以先發(fā)布到生產(chǎn)環(huán)境的子集中，并在進(jìn)行完整測試之后，推廣到所有生產(chǎn)環(huán)境中。這極大降低了新版本發(fā)布的風(fēng)險。部署是自動的，這樣只需要花費(fèi)幾分鐘就能向用戶提供可靠的新功能。
持續(xù)交付流水線的最佳實(shí)踐
下面總結(jié)了在構(gòu)建持續(xù)交付流水線時一些好的實(shí)踐經(jīng)驗(yàn)。
1.做好配置管理
持續(xù)交付流水線需要有平臺配置和系統(tǒng)配置的支持，這樣就能允許團(tuán)隊(duì)自動或手動按下按鈕來創(chuàng)建、維護(hù)和拆除一個完整的環(huán)境。
自動平臺配置可確保您的候選應(yīng)用程序能夠部署到正確配置的且可重現(xiàn)的環(huán)境中去，然后進(jìn)行測試。它還促進(jìn)了橫向擴(kuò)展性，并允許企業(yè)在沙箱環(huán)境中隨時嘗試新產(chǎn)品。
2.合理編排流水線
持續(xù)交付流水線中的多個階段涉及不同的人員團(tuán)隊(duì)協(xié)作，并且所有人員都需要監(jiān)測新版本的應(yīng)用程序的發(fā)布。持續(xù)交付流水線的編排提供了整個流水線的頂層視圖，允許您自行定義和控制每個階段的具體動作，這樣就能細(xì)化整個軟件交付過程。
3.不要添加新的功能，直到通過質(zhì)量測試
持續(xù)交付使您的組織能夠一個接一個地快速可靠地將新功能帶入生產(chǎn)環(huán)境中。這意味著每個單獨(dú)的功能需要在展開之前進(jìn)行測試，確保該功能滿足整個系統(tǒng)的質(zhì)量要求。
在傳統(tǒng)開發(fā)環(huán)境中，開發(fā)團(tuán)隊(duì)通常試圖一次性實(shí)現(xiàn)一個完整的新版本，僅在項(xiàng)目接近完成時來解決軟件質(zhì)量屬性（如魯棒性、可擴(kuò)展性、可維護(hù)性等）。然而，隨著最終工期的臨近，以及迫于
預(yù)算的壓力，質(zhì)量往往會首先被舍棄。
可以通過在獲得質(zhì)量權(quán)之前不添加新功能的原則來避免不良的系統(tǒng)質(zhì)量。在實(shí)踐中，您應(yīng)該始
終首先滿足并保持質(zhì)量水平，然后才考慮逐步向系統(tǒng)添加功能。使用持續(xù)交付，每個新功能都需要
從一開始就滿足整個系統(tǒng)所期望的質(zhì)量水平。只有在達(dá)到此質(zhì)量水平后，才能將該功能移至生產(chǎn)
環(huán)境。
配置管理
1.什么是配置管理
配置管理是指一個過程，通過該過程，將所有與項(xiàng)目相關(guān)的產(chǎn)物，以及它們之間的關(guān)系都被唯一定義、修改、存儲和檢索。這里的項(xiàng)目相關(guān)的產(chǎn)物可以是源代碼、需求文檔、設(shè)計(jì)文檔、測試文檔等，也包括了項(xiàng)目配置、庫文件、發(fā)布包、編譯工具等。
配置管理是軟件開發(fā)過程中極其重要的一部分，持續(xù)集成、部署流水線、自動化測試等若想真正發(fā)揮好作用，都必須做好配置管理工作。
2.如何進(jìn)行配置管理
《持續(xù)交付》一書對配置管理做了重要的論述，并通過版本控制、依賴管理、軟件配置管理和環(huán)境管理四部分來分別分析了配置管理的重要性。以下是所總結(jié)的配置管理的實(shí)踐經(jīng)驗(yàn)。
版本控制:在版本控制方面，我們提倡將所有東西都提交到版本控制庫中，包括操作系統(tǒng)的配置信息。使用版本控制庫的好處是顯而易見，你可以放心地變更或刪除任何文件，版本控制庫可以幫你來回溯歷史。常用的版本控制庫有很多，包括Bazaar、Mercurial、Git、SVN等。這里的建議是，除非是歷史原因?qū)е伦兏姹究刂茙燔浖容^困難，否則，采用Git等分布式版本控制庫軟件可以極大提高團(tuán)隊(duì)協(xié)作的效率。對于提交變更而言，一個好的實(shí)踐是頻繁提交變更到主干，因?yàn)楫?dāng)你匯聚的更改越多，變更間隔的時間越長，合并到主干時發(fā)現(xiàn)的問題就會越多。頻繁提交代碼，就是一個頻繁集成代碼的過程。
依賴管理:對于一個頗具規(guī)模的軟件而言，很難不依賴第三方的軟件或第三方的庫文件的實(shí)現(xiàn)。當(dāng)項(xiàng)目中依賴變多時，依賴關(guān)系將變得錯綜復(fù)雜，特別是某些軟件存在兼容性方面的問題，各個版本之間的接口還不能通用，這樣，通過手工等方式進(jìn)行依賴的管理將變得極其困難。在實(shí)際開發(fā)中，我們傾向于使用依賴管理工具來幫助解決這些依賴管理，對于Java開發(fā)者而言，Maven或 Gradle是個不錯的選擇。建議在本地保存一份外部庫的副本，這樣可以加快開發(fā)的啟動速度。另外，將依賴庫的版本在團(tuán)隊(duì)中進(jìn)行統(tǒng)一，可以有效防止不同版本之間出現(xiàn)的奇怪問題。
軟件配置管理:幾乎所有的軟件都有配置文件，這使得軟件可以在不做修改的前提下，僅需要調(diào)整配置文件的內(nèi)容，就實(shí)現(xiàn)軟件的差異化。不同的軟件部署到不同的生產(chǎn)環(huán)境中，其所使用的配置文件也是不同的。將軟件配置進(jìn)行統(tǒng)一管理，這樣在軟件升級時，仍然能夠恢復(fù)用戶最初的軟件設(shè)置。一個好的事件是把配置信息當(dāng)成源代碼看待，并對它進(jìn)行測試。
環(huán)境配置管理:沒有哪個應(yīng)用程序是孤島。每個應(yīng)用程序都依賴于硬件、軟件、基本設(shè)施及外部系統(tǒng)才能正常工作。所以在提倡自動化方式管理環(huán)境時，還需要考慮環(huán)境配置信息，例如:
*應(yīng)用程序所采用的各種操作系統(tǒng)或中間件，包括其版本、補(bǔ)丁級別及配置設(shè)置;
*應(yīng)用程序所依賴的需要安裝到環(huán)境中的軟件包，以及這些軟件包的具體版本和配置;
*應(yīng)用程序正常工作所必需的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu);
*應(yīng)用程序所依賴的所有外部服務(wù)，以及這些服務(wù)的版本和配置信息。
本書后續(xù)章節(jié)，也會探討微服務(wù)的集中化配置的問題。
持續(xù)交付與DevOps
對于交付成功的軟件來說，開發(fā)和運(yùn)維是兩個必不可少的過程。在傳統(tǒng)的組織架構(gòu)中，開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)往往是分屬于不同的部門，各自部門的職責(zé)可能會引人相互抵觸的目標(biāo):對于開發(fā)人員來說，開發(fā)人員的職責(zé)是負(fù)責(zé)交付新特性及對變更承擔(dān)責(zé)任;而運(yùn)維人員則試圖保持所有功能能夠平穩(wěn)運(yùn)行，對他們來說，避免變更正是降低運(yùn)行風(fēng)險的一種最有力的手段。在這種互相沖突的目標(biāo)面前，最終導(dǎo)致產(chǎn)品不能得到很好的更新，也就無法持續(xù)給用戶創(chuàng)造價值。
DevOps 正是為了打破開發(fā)團(tuán)隊(duì)與運(yùn)維團(tuán)隊(duì)之間的壁壘而進(jìn)行的一次嘗試。DevOps是Develop-ment與Operations的縮寫，DevOps推動了一套用于思考溝通和協(xié)作的過程和方法，用于促進(jìn)開發(fā)、技術(shù)運(yùn)營和質(zhì)保部門之間的溝通、協(xié)作與整合,其推崇的團(tuán)隊(duì)將會是一個結(jié)合開發(fā)、質(zhì)量保證( QA)、IT運(yùn)營等整個職責(zé)的跨職能團(tuán)隊(duì)，如圖11-2所示。這也正是Amazon所提倡的“You Build It，YouRun It（誰開發(fā)，誰運(yùn)維）”的開發(fā)模式。
持續(xù)交付和 DevOps在其意義上及目標(biāo)上是相似的（旨在快速交付產(chǎn)品），但它們是兩個不同的概念。
DevOps有更廣泛的范圍，圍繞:組織變革，具體來說，支持參與軟件交付的各類人員之間的更大的協(xié)作，包括開發(fā)、運(yùn)營、質(zhì)保、管理等;自動化軟件交付過程。
持續(xù)交付是一種自動化交付軟件的方法，并且側(cè)重于:結(jié)合不同的過程，包括開發(fā)、集成、測試、部署等;更快，更頻繁地執(zhí)行上述過程。
DevOps和持續(xù)交付有共同的最終目標(biāo)，它們經(jīng)常被聯(lián)合使用，并且在敏捷方法和精益思想中有著共同的遠(yuǎn)景:小而快的變化，以最終客戶的價值為重點(diǎn)。它們在內(nèi)部進(jìn)行良好的溝通和協(xié)作，從而實(shí)現(xiàn)快速交付產(chǎn)品，降低風(fēng)險。
在微服務(wù)架構(gòu)系統(tǒng)的開發(fā)中，我們傾向于采用DevOps的方式來組建全能型的團(tuán)隊(duì)。
本篇文章內(nèi)容給大家講解的是持續(xù)交付與持續(xù)部署微服務(wù)
下篇文章給大家講解基于容器的部署與發(fā)布微服務(wù)；
覺得文章不錯的朋友可以轉(zhuǎn)發(fā)此文關(guān)注小編；
感謝大家的支持！
本文就是愿天堂沒有BUG給大家分享的內(nèi)容，大家有收獲的話可以分享下，想學(xué)習(xí)更多的話可以到微信公眾號里找我，我等你哦。