建站
咨詢
售后
建站咨詢
新聞中心
將您的開發(fā)團隊轉變?yōu)槌掷m(xù)交付模式是一項比較艱巨工作。正如自動化持續(xù)交付過程本身那樣，您應該分階段進行，而不要一次性更改所有的方面。同時您要有回滾方案，以備各種突發(fā)問題的出現(xiàn)。雖然此過程***挑戰(zhàn)性，但一旦成功實現(xiàn)，則會使您能夠更快地響應客戶的各種需求，并能使您的產(chǎn)品最終在市場上更具競爭力。
在輪臺等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供網(wǎng)站設計、成都網(wǎng)站建設 網(wǎng)站設計制作按需設計網(wǎng)站,公司網(wǎng)站建設,企業(yè)網(wǎng)站建設,品牌網(wǎng)站建設,全網(wǎng)整合營銷推廣,外貿(mào)網(wǎng)站建設,輪臺網(wǎng)站建設費用合理。
自動化的好處
自動化的諸多好處包括：
- 將上市的時間從按周計算和按月計算，縮短為按天或小時計算。
- 更少的軟件錯誤意味著降低了市場的風險。
- 更少的時間花費在運維上，也減少了軟件開發(fā)的成本。
- 更強大的開發(fā)團隊。
一旦成功構建了自動化的pipeline，那么在將整個開發(fā)環(huán)境進行切換之前，您就可以使用此處所羅列的一些***實踐來微調(diào)自己的pipeline。
我們在此將***實踐分為三大類：
- 軟件架構 – 各種服務和產(chǎn)品的整體架構，為您構建pipeline的模式和團隊與之交互的方式定下基調(diào)。
- 自動化模式 - 自動化和各種測試的策略。
- 公司文化 - 團隊組織、透明度和責任。
1.軟件架構
采用微服務
為了實現(xiàn)真正的敏捷和自動化pipeline，我們建議您將產(chǎn)品構建為各種微服務。
如果您對為何需要微服務還存有疑問的話，請參閱：《什么是微服務？》，和《從AWS角度介紹微服務》。
除非您是從頭開始創(chuàng)建一個應用程序，否則重新構建整個應用程序?qū)⑹且豁椃浅ＦD巨的任務。如果您手頭已有現(xiàn)成的系統(tǒng)，那么***是逐步地切換到微服務之中。例如，您可以采用由Martin Fowler開發(fā)strangler模式。該模式保證了將單一的體系結構提升至微服務的過程中，您仍可使用并存的現(xiàn)有業(yè)務系統(tǒng)。
在這種模式下，您的關鍵任務系統(tǒng)不但能夠得以維持，并且新的架構也會圍繞著它被構建出來。隨著時間的推移，舊系統(tǒng)會逐漸地被新架構所取代，而非一次性全部轉換過去。
2.自動化模式
實施GitOps
為了優(yōu)化平均恢復時間（MTTR，Mean Time to Recovery），您應該實施GitOps。
GitOps的運行依靠將Git（譯者注：Git是一個開源的分布式版本控制系統(tǒng)）作為聲明式基礎架構和應用程序的“數(shù)據(jù)源（source of truth）”。當對于Git的更改發(fā)生時，自動化交付的pipeline會將變更部署到您的基礎架構之中。
您的基礎架構和應用程序代碼不僅具有了數(shù)據(jù)源，而且在發(fā)生災難時，您的開發(fā)團隊還能夠從Git中快速地恢復基礎架構，從而將MTTR從小時級別降低到分鐘級別。
有關GitOps的更多信息，請參閱《用拉式請求的各種操作》和《GitOps：Kubernetes實現(xiàn)高速持續(xù)集成與持續(xù)交付（CI/CD）》。
注重安全的自動化
在與大型團隊協(xié)作和將各種自動化pipeline連到Kubernetes的時候，您需要重點考慮自己集群里的各種安全憑證。為了能將更新部署到群集之中，您必須將證書保存在某處。在理想情況下，這些證書應該保存在集群的內(nèi)部。但是如果需要被放在外面的話，它們至少應該被保存在諸如Vault這樣的庫中。
推/拉式模式
由于您的持續(xù)集成能從持續(xù)交付中分離出來，因此拉式自動化pipeline提供了更好的安全性。如今大多數(shù)CI/CD工具都使用的是推送模式。基于推式意味著代碼從CI系統(tǒng)開始經(jīng)過pipeline，然后需要通過一系列編碼腳本，或手動使用'kubectl'將變更推送到Kubernetes群集之中?？傮w而言，如果不小心使用的話，CI反而會成為您系統(tǒng)的一個入口。
像Weave Cloud的拉模式就依賴于兩個關鍵的組件：一個是用于監(jiān)控鏡像注冊表的部署性自動化器（Deploy Automator），另一個是位于群集之中，以維護其狀態(tài)的部署性同步器（Deploy Synchronizer）。
由于Weave Cloud部署針對的是如下方面，因此拉式方法更為安全：
- 基于角色訪問控制（RBAC）的相關策略與安全性，僅執(zhí)行Kubernetes所允許的操作。信任關系由群集所共享，并非被單獨地掌握。
- 本地綁定所有Kubernetes對象，并獲悉操作是否已完成或需要重試。
不必每次都從頭開始重建鏡像
在通過pipeline去運行各種更新時，為了節(jié)省寶貴的時間，您不必每次都去重建鏡像。您只需一次性構建容器的鏡像，然后通過每個測試序列/環(huán)境將其“推廣”出去。如果您使用的是GitOps，那么就可以在Git中對各種聲明性配置文件進行更改，或者直接使用Weave Cloud部署的各種操作。
對發(fā)布進行解耦部署
在將產(chǎn)品發(fā)布給客戶之前，請?zhí)砑右粋€部署的階段，以進行冒煙測試，甚至是一些更多類型的測試，如：藍綠部署、金絲雀測試、或A/B測試。
值得注意的是：我們應當在概念上理解“部署”與“發(fā)布”之間的區(qū)別。部署是指軟件已經(jīng)通過了測試并被安裝到了特定環(huán)境之中；而發(fā)布則是將這些更改最終真實地落實并推送到最終用戶的手中。
衡量pipeline的成功
請建立并跟蹤pipeline里的那些關鍵性的指標。您可以將開始自動化之前的情況和之后的結果做比較，主要包括如下方面：
- 部署頻率 - 每天完成的部署數(shù)量。
- 變更的交付周期 - 部署一次變更所需要的交付時間。
- 平均恢復時間（MTTR） - 在災難發(fā)生時，恢復應用所需要的時間。
- 變更失敗率 - 以正常運行時間的百分比來表示宕機的時間。
3.持續(xù)交付的企業(yè)文化
創(chuàng)建一種開放且不抱怨的文化
請圍繞著自動化過程增加企業(yè)透明度。通過允許開發(fā)人員犯錯，從而激勵他們勇于解決和糾正各種過程中所產(chǎn)生的偏差。一旦自動化被建立起來，開發(fā)人員需要對pipeline擁有完全的所有權，以便在測試失敗發(fā)生時，代碼變更能夠被及時地進行回滾。
每個人都為構建承擔責任
在完全的自動化pipeline模式下，任何人都應該能夠去診斷并解決構建中出現(xiàn)的問題。這不僅能夠產(chǎn)生更多自創(chuàng)的軟件開發(fā)流程，還會促進整個組織內(nèi)產(chǎn)生更好的團隊協(xié)作。
***的建議
眾所周知，易于出錯的手動式部署往往會增加軟件發(fā)布的風險和成本，同時也會降低公司在其業(yè)務領域的競爭力。因此，雖然實施自動化的持續(xù)交付pipeline會是一項艱巨的任務，但它最終將被證明是企業(yè)值得付出的“陣痛”。
分享名稱：開發(fā)團隊實現(xiàn)持續(xù)交付的三類實踐
鏈接地址：http://www.5511xx.com/article/dpjehji.html
