將您的開(kāi)發(fā)團(tuán)隊(duì)轉(zhuǎn)變?yōu)槌掷m(xù)交付模式是一項(xiàng)比較艱巨工作。正如自動(dòng)化持續(xù)交付過(guò)程本身那樣，您應(yīng)該分階段進(jìn)行，而不要一次性更改所有的方面。同時(shí)您要有回滾方案，以備各種突發(fā)問(wèn)題的出現(xiàn)。雖然此過(guò)程***挑戰(zhàn)性，但一旦成功實(shí)現(xiàn)，則會(huì)使您能夠更快地響應(yīng)客戶的各種需求，并能使您的產(chǎn)品最終在市場(chǎng)上更具競(jìng)爭(zhēng)力。

在輪臺(tái)等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專(zhuān)注、極致的服務(wù)理念，為客戶提供網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè) 網(wǎng)站設(shè)計(jì)制作按需設(shè)計(jì)網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),全網(wǎng)整合營(yíng)銷(xiāo)推廣,外貿(mào)網(wǎng)站建設(shè),輪臺(tái)網(wǎng)站建設(shè)費(fèi)用合理。

自動(dòng)化的好處

自動(dòng)化的諸多好處包括：

• 將上市的時(shí)間從按周計(jì)算和按月計(jì)算，縮短為按天或小時(shí)計(jì)算。
• 更少的軟件錯(cuò)誤意味著降低了市場(chǎng)的風(fēng)險(xiǎn)。
• 更少的時(shí)間花費(fèi)在運(yùn)維上，也減少了軟件開(kāi)發(fā)的成本。
• 更強(qiáng)大的開(kāi)發(fā)團(tuán)隊(duì)。

一旦成功構(gòu)建了自動(dòng)化的pipeline，那么在將整個(gè)開(kāi)發(fā)環(huán)境進(jìn)行切換之前，您就可以使用此處所羅列的一些***實(shí)踐來(lái)微調(diào)自己的pipeline。

我們?cè)诖藢?**實(shí)踐分為三大類(lèi)：

1. 軟件架構(gòu) – 各種服務(wù)和產(chǎn)品的整體架構(gòu)，為您構(gòu)建pipeline的模式和團(tuán)隊(duì)與之交互的方式定下基調(diào)。
2. 自動(dòng)化模式 - 自動(dòng)化和各種測(cè)試的策略。
3. 公司文化 - 團(tuán)隊(duì)組織、透明度和責(zé)任。

1.軟件架構(gòu)

采用微服務(wù) 

為了實(shí)現(xiàn)真正的敏捷和自動(dòng)化pipeline，我們建議您將產(chǎn)品構(gòu)建為各種微服務(wù)。

如果您對(duì)為何需要微服務(wù)還存有疑問(wèn)的話，請(qǐng)參閱：《什么是微服務(wù)？》，和《從AWS角度介紹微服務(wù)》。

除非您是從頭開(kāi)始創(chuàng)建一個(gè)應(yīng)用程序，否則重新構(gòu)建整個(gè)應(yīng)用程序?qū)⑹且豁?xiàng)非常艱巨的任務(wù)。如果您手頭已有現(xiàn)成的系統(tǒng)，那么***是逐步地切換到微服務(wù)之中。例如，您可以采用由Martin Fowler開(kāi)發(fā)strangler模式。該模式保證了將單一的體系結(jié)構(gòu)提升至微服務(wù)的過(guò)程中，您仍可使用并存的現(xiàn)有業(yè)務(wù)系統(tǒng)。

在這種模式下，您的關(guān)鍵任務(wù)系統(tǒng)不但能夠得以維持，并且新的架構(gòu)也會(huì)圍繞著它被構(gòu)建出來(lái)。隨著時(shí)間的推移，舊系統(tǒng)會(huì)逐漸地被新架構(gòu)所取代，而非一次性全部轉(zhuǎn)換過(guò)去。

2.自動(dòng)化模式

實(shí)施GitOps

為了優(yōu)化平均恢復(fù)時(shí)間（MTTR，Mean Time to Recovery），您應(yīng)該實(shí)施GitOps。

GitOps的運(yùn)行依靠將Git（譯者注：Git是一個(gè)開(kāi)源的分布式版本控制系統(tǒng)）作為聲明式基礎(chǔ)架構(gòu)和應(yīng)用程序的“數(shù)據(jù)源（source of truth）”。當(dāng)對(duì)于Git的更改發(fā)生時(shí)，自動(dòng)化交付的pipeline會(huì)將變更部署到您的基礎(chǔ)架構(gòu)之中。

您的基礎(chǔ)架構(gòu)和應(yīng)用程序代碼不僅具有了數(shù)據(jù)源，而且在發(fā)生災(zāi)難時(shí)，您的開(kāi)發(fā)團(tuán)隊(duì)還能夠從Git中快速地恢復(fù)基礎(chǔ)架構(gòu)，從而將MTTR從小時(shí)級(jí)別降低到分鐘級(jí)別。

有關(guān)GitOps的更多信息，請(qǐng)參閱《用拉式請(qǐng)求的各種操作》和《GitOps：Kubernetes實(shí)現(xiàn)高速持續(xù)集成與持續(xù)交付（CI/CD）》。

注重安全的自動(dòng)化

在與大型團(tuán)隊(duì)協(xié)作和將各種自動(dòng)化pipeline連到Kubernetes的時(shí)候，您需要重點(diǎn)考慮自己集群里的各種安全憑證。為了能將更新部署到群集之中，您必須將證書(shū)保存在某處。在理想情況下，這些證書(shū)應(yīng)該保存在集群的內(nèi)部。但是如果需要被放在外面的話，它們至少應(yīng)該被保存在諸如Vault這樣的庫(kù)中。

推/拉式模式

由于您的持續(xù)集成能從持續(xù)交付中分離出來(lái)，因此拉式自動(dòng)化pipeline提供了更好的安全性。如今大多數(shù)CI/CD工具都使用的是推送模式。基于推式意味著代碼從CI系統(tǒng)開(kāi)始經(jīng)過(guò)pipeline，然后需要通過(guò)一系列編碼腳本，或手動(dòng)使用'kubectl'將變更推送到Kubernetes群集之中?？傮w而言，如果不小心使用的話，CI反而會(huì)成為您系統(tǒng)的一個(gè)入口。

像Weave Cloud的拉模式就依賴(lài)于兩個(gè)關(guān)鍵的組件：一個(gè)是用于監(jiān)控鏡像注冊(cè)表的部署性自動(dòng)化器（Deploy Automator），另一個(gè)是位于群集之中，以維護(hù)其狀態(tài)的部署性同步器（Deploy Synchronizer）。

由于Weave Cloud部署針對(duì)的是如下方面，因此拉式方法更為安全：

• 基于角色訪問(wèn)控制（RBAC）的相關(guān)策略與安全性，僅執(zhí)行Kubernetes所允許的操作。信任關(guān)系由群集所共享，并非被單獨(dú)地掌握。
• 本地綁定所有Kubernetes對(duì)象，并獲悉操作是否已完成或需要重試。

不必每次都從頭開(kāi)始重建鏡像

在通過(guò)pipeline去運(yùn)行各種更新時(shí)，為了節(jié)省寶貴的時(shí)間，您不必每次都去重建鏡像。您只需一次性構(gòu)建容器的鏡像，然后通過(guò)每個(gè)測(cè)試序列/環(huán)境將其“推廣”出去。如果您使用的是GitOps，那么就可以在Git中對(duì)各種聲明性配置文件進(jìn)行更改，或者直接使用Weave Cloud部署的各種操作。

對(duì)發(fā)布進(jìn)行解耦部署

在將產(chǎn)品發(fā)布給客戶之前，請(qǐng)?zhí)砑右粋€(gè)部署的階段，以進(jìn)行冒煙測(cè)試，甚至是一些更多類(lèi)型的測(cè)試，如：藍(lán)綠部署、金絲雀測(cè)試、或A/B測(cè)試。

值得注意的是：我們應(yīng)當(dāng)在概念上理解“部署”與“發(fā)布”之間的區(qū)別。部署是指軟件已經(jīng)通過(guò)了測(cè)試并被安裝到了特定環(huán)境之中；而發(fā)布則是將這些更改最終真實(shí)地落實(shí)并推送到最終用戶的手中。

衡量pipeline的成功

請(qǐng)建立并跟蹤pipeline里的那些關(guān)鍵性的指標(biāo)。您可以將開(kāi)始自動(dòng)化之前的情況和之后的結(jié)果做比較，主要包括如下方面：

• 部署頻率 - 每天完成的部署數(shù)量。
• 變更的交付周期 - 部署一次變更所需要的交付時(shí)間。
• 平均恢復(fù)時(shí)間（MTTR） - 在災(zāi)難發(fā)生時(shí)，恢復(fù)應(yīng)用所需要的時(shí)間。
• 變更失敗率 - 以正常運(yùn)行時(shí)間的百分比來(lái)表示宕機(jī)的時(shí)間。

3.持續(xù)交付的企業(yè)文化

創(chuàng)建一種開(kāi)放且不抱怨的文化

請(qǐng)圍繞著自動(dòng)化過(guò)程增加企業(yè)透明度。通過(guò)允許開(kāi)發(fā)人員犯錯(cuò)，從而激勵(lì)他們勇于解決和糾正各種過(guò)程中所產(chǎn)生的偏差。一旦自動(dòng)化被建立起來(lái)，開(kāi)發(fā)人員需要對(duì)pipeline擁有完全的所有權(quán)，以便在測(cè)試失敗發(fā)生時(shí)，代碼變更能夠被及時(shí)地進(jìn)行回滾。

每個(gè)人都為構(gòu)建承擔(dān)責(zé)任

在完全的自動(dòng)化pipeline模式下，任何人都應(yīng)該能夠去診斷并解決構(gòu)建中出現(xiàn)的問(wèn)題。這不僅能夠產(chǎn)生更多自創(chuàng)的軟件開(kāi)發(fā)流程，還會(huì)促進(jìn)整個(gè)組織內(nèi)產(chǎn)生更好的團(tuán)隊(duì)協(xié)作。

***的建議

眾所周知，易于出錯(cuò)的手動(dòng)式部署往往會(huì)增加軟件發(fā)布的風(fēng)險(xiǎn)和成本，同時(shí)也會(huì)降低公司在其業(yè)務(wù)領(lǐng)域的競(jìng)爭(zhēng)力。因此，雖然實(shí)施自動(dòng)化的持續(xù)交付pipeline會(huì)是一項(xiàng)艱巨的任務(wù)，但它最終將被證明是企業(yè)值得付出的“陣痛”。

網(wǎng)站欄目：開(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)持續(xù)交付的三類(lèi)實(shí)踐
當(dāng)前路徑：http://uogjgqi.cn/article/dpjehji.html