閱讀451 返回首頁    go 阿裏雲 go 技術社區[雲棲]


基於容器服務的持續集成與雲端交付(五)- 探究持續交付係統的本質

換個角度看持續交付

在《基於容器服務的持續集成與雲端交付》係列中,我們已經討論了持續集成與持續交付給軟件開發帶來的變革,介紹了如何從零搭建一個持續交付係統以及在阿裏雲上麵如何實現持續交付。

不過,在這篇文章中,我們會用一個不一樣的角度來思考持續交付,到底持續交付給我們帶來了什麼,在容器的持續交付的場景中還缺少什麼。回到本係列第一篇文章中的容器持續交付的流程圖:

f694553ec98973d343ca89d2af7006ab222f8bc7

這張圖中描述了一個基於容器的持續交付的流程,它定義了幾個階段,本地開發階段、持續集成階段、持續交付階段等等,規定了在每個階段中該做什麼事情,開發人員、運維人員應該應該承擔什麼樣的任務與責任。

從某種意義上來講,持續交付不隻隻是一個技術問題,更多的是探究自動化軟件標準化的交付流程的問題,通過技術的手段將軟件開發、測試、集成、交付過程中的每個步驟進行標準化,然後再用一個靈活的流水線將不同的步驟串起來。

軟件交付和汽車製造的原理是相似的,最早的汽車是純手工打造的,產量低可靠性差。隨著科技的發展,一輛汽車的零件可以由全球各地的公司製造,然後在一個可編程的流水線上快速的組裝出來,現在組裝一輛汽車隻需要幾分鍾的時間,而這都得益於模塊的標準化和可擴展的流水線。同樣持續集成效果的好壞取決於標準化的程度與流水線的擴展能力:標準化程度越高、流水線擴展性越好持續交付的能力就越強。下麵我們來討論如何實現或者選擇持續交付中的“標準化”與“流水線”

標準化與流水線

對於大多數的企業而言,通常情況下不會投入大量的精力來開發屬於自己的持續交付係統,一般會選擇開源的持續交付方案或者使用提供持續交付能力的SaaS服務,例如基於Jenkins的持續交付方案或者阿裏雲的CRP持續交付平台係統等等。

在Docker還沒有興起的時代,持續集成的方式通常是通過自動化配管工具來實現標準化的,比如Ansible的playbook、Chef的Cookbook等等,但是這些自動化配管工具更傾向於配置的管理與環境的初始化,換言之,自動化配管工具並不是麵向交付的標準化而是更傾向於配置管理流程的標準化。

而Docker的興起,給我們帶來了交付流程標準化的可能性。當所有交付流程都變得標準化後,流水線(pipeline)則可以將不同的交付流程穿起來,實現持續交付的流程。

如何演進持續交付係統

1.製定合適自己業務形態的標準與流程

持續交付要符合自己的業務場景與形態,我們經常可以在社區中看到不同的持續集成的方案,但是,最開始要做是根據自己的業務形態來執行流程與標準。有了業務場景再去選擇合適自己的持續集成方案。比如阿裏雲容器服務提供基於Hub的簡單的持續集成方案,提供基於Jenkins的開源的持續集成方案也提供基於CRP的持續集成的方案。他們分別麵向不同的場景、解決了不同的問題。先明確自己持續交付的場景與所需要的能力然後再選擇不同的持續集成的方案。

2.選擇一條合適的流水線或者流水線的默認實現

Docker已經幫我們解決了大部分交付流程中的標準化問題,那麼選擇一條適合的流水線則尤為重要,SaaS類的雲服務通常情況會提供標準的流水線(pipeline)實現,但是相比而言,基於DSL的Jenkins的流水線(pipeline)是更為強大的選擇。針對於不同的業務,開源的Jenkins流水線靈活的程度大於SaaS類的持續交付係統的流水線大於固定流程的流水線。

3.根據業務的需求不斷的豐富流水線上的流程

在使用持續集成的過程中,我們會根據業務的形態的變化,不斷的在流水線上添加或者刪減持續交付的流程。當持續交付的流程被大家認可並遵守的時候,持續交付的能力就會真正的展現出來。通過類似模塊化的插拔將不同的組件不同的流程融合在一起,不斷的演進,滿足不同維度的業務場景與方向。

尾聲

還有什麼是我們沒有討論的?其實Docker給我們帶來的不隻隻是標準化的部分,還有更多的是職責劃分的思考,從前從軟件的開發到測試之前的部分是開發負責的,而從測試、上線、後期的線上運維都是運維的人員負責的。

不過,軟件架構的變革例如微服務的興起等等會導致運維變得越來困難,從前一個企業隻有少量的“巨石”軟件係統,運維人員隻需要運維少量單一的技術框架的係統即可。但是,現在一個微服務係統可能有幾十個模塊,每個模塊的運行時環境、運維方式都不盡相同,這給運維帶來的難度是指數級增長的。

現在越來越多的人在討論DevOps或者SRE,其實這並不是一個新的職業,更多的是對於開發與運維邊界的重新定義。

個人覺得開發人員未來會更傾向於DevOps的方向發展,即開發人員中會有更細分的傾向,部分開發人員傾向於線上維護與組件調優而另一部分則側重軟件開發。

而運維人員會更傾向於平台化或者SRE化,運維人員會花費跟多的精力在自動化持續交付平台流程的建設與優化、基礎設施的建設(監控、日誌、擴容)等等。

持續集成與持續交付不僅是提速了交付的流程,更多的是優化了開發人員的職責劃分與交付的方式。

個人簡介

莫源,阿裏雲高級研發工程師。在加入阿裏巴巴之前,先後在北京天方地圓科技有限公司、微軟亞洲研究院任職。現主要負責阿裏雲容器服務產品的底層服務發現係統、集群管理係統的研發,從事容器的持續交付、持續集成的方案的設計與實現。在雲計算、分布式係統、圖像識別與虛擬現實方向有多年的開發經驗。

最後更新:2017-07-04 15:32:19

  上一篇:go  峰任策劃:提高ROI,這4個SEM推廣時段策略或許能幫助你!
  下一篇:go  基於容器服務的持續集成與雲端交付(四)- 多種發布方式