進度條

程式自動上線與測試已經不夠潮了,你有跟上DevOps的潮流嗎?

「天下武功,唯快不破」- 一起秒懂快速發佈導向的DevOps吧!

作者: Vincent Ke 更新日期:

相信大家一定都有使用過Facebook的經驗,一定對他的快速改版私毫不陌生,可能早上醒來時發現「讚」的圖案突然從實心變從空心,或是開始多了一些繽紛酷炫的功能(像是直播、限時動態..等等)。

但你能想像一下嗎?在過去十年前,大部份軟體服務上的版本更新,都只能像是Office每年的一期一會來做推陳出新,但新的功能可能沒解決到用戶的痛處,反而增添了更多不必要的麻煩。所以在快速變遷的時代裡,這種快速、持續發佈新版本的特性,儼然成為了適性生存的不二法則。

 

 

 

你能想像Flicker每天至少會有10次以上的服務發佈嗎?如果在傳統的開發方式,一旦有新功能的釋出,如果使用者體驗不好需要改進就算了,但如果有BUG的話,卻需要等待一個月或一整年的時間才能解決,這樣的產品你還會想用嗎?

 

所以與傳統開發方法那種大規模的、低頻繁的發布,敏捷方法為基礎的DevOps,目的就是為了提升了發布頻率的速度與效率,從過去的「年」、「季」,提升到「月」、「週」,甚至是「日」。

 

但快速發佈的概念,並非是「開發團隊」的步調快速緊湊起來就可以達到的方式,因為每一個新版本的Release,除了靠開發團隊的努力外,也需要「維運團隊」、「測試團隊」的努力,才有辦法相輔相成,但通常在公司裡「開發」和「維運」都是隸屬於不同的部門的業務,開發目標是推陳出新,但維運部門在乎的是系統穩定性及可靠性,在這樣兩者恆相衝突的狀況下,又該如何透過整合來達到「快速」的目的呢? 

 

 

 

所以DevOps開發方法最主要改善的是開發團隊以及維運團隊的關係,並透過Agile「敏捷式開發」的概念,讓交付可以達到「透明化」、「持續化」以及「自動化」等目標。

 

先介紹一下DevOps吧,DevOps 是來自Development和Operations這2個英文字的縮寫組合,跟Agile一樣,他並非是使用特定的工具或技術來做為解決方案,而是一種具備文化、哲學、實務與工具於一身的概念結合,主要目的是提升組織快速交付應用程式和服務的能力,僅管相較於使用傳統軟體開發的「瀑布式」的管理程序,這種作法能更有效率的快速開發和改進產品。並提供更具競爭力的服務。

 

但,很多文章中會將DevOps翻成 「快速交付」 、「持續交付」,但這並非完全正確。

 

因為針對傳統端對端開發流程,每一個部門都有可獨立切割的功能,開發團隊專注軟體開發,維運團隊做軟體發佈(或軟體部屬),而測試團隊就是做上線前後的測試。是當功能被明顯切割後,僅管遵循公司開發流程,但團隊間訊息上的同步勢必會有所影響,例如當開發團隊遞交的軟體,不符合部署環境,或是因功能更改軟體規格時,維運團隊可能就因為資訊落差而退回交付;又或是開發團隊交付功能給測試團隊後,卻因為不甚熟悉造成測試漏洞,當然也有開發環節測試不過的可能性,但綜合以上的案例,就會拖累軟體交付速度。

 

 

 

所以DevOps最核心的概念就是為了解決跨部門與跨團隊間的衝突,透過透明度的提高以及一些機制的導入,來做有效率的整合,來完成提高上限速度的目的。他的核心概念可以用" CALMS "來做解釋。

 

"C"ulture-文化:因為DevOps並非是一種技能或是工具,而應該要三個部門一起對齊的文化,透過同理心的互惠,多位其他部門的人去思考,在著手開發,一來可以解決資訊上的同步問題,更可以解決因為部門落差造成時間成本損失。例如開發團隊應該要在程式的設定檔上,設計的更易管理..等。透過共識、理解和溝通,進而改善部門間的整合問題,才是"C"代表的真正意涵。

 

"A"utomation-自動化:A通常就是開發團隊最重視的問題,像是中間提到每一個容易造成Delay的環節,像測試及部屬等等,若是都可以透過自動化來做排程,不僅可以減少溝通落差造成的問題,更可以讓需求開發及整合上更為快速,想像如果使用自動化測試和自動化部屬,那開發完成後的需求,就可以一下進入上線準備,這不就是「持續交付」的真諦嗎? 

 


 

"L"ean-精實開發:因為DevOps也隸屬於敏捷式開發上的內容之一,所以也必須套用精實開發上的一些原則,像是消除浪費 (eliminate waste)、盡快交付 (deliver as faster as possible)等,來符合Agile的精神。

 

"M"easurement-數據分析:不斷的精進是需要依據,而M的重點就是在透過數據上的反應,來給團隊正向及改進的回饋,例如新功能上線後減少了多少客訴量、縮短多少作業時間等,甚至是每次上線後的BUG率及修復率等,都是可以被測量出來的基本指標,來反應出開發者的量與質是否正比。

 

"S"hare-分享:既然有了數據,就應該把成效分享給DevOps間的所有參與者,來做下次檢討、改進的目標,而分享不僅是文化的根,也是增加團隊透明度的好方法。

 

 

 

而DevOps的好處,就是透過CALMS的方式,來達到提高發佈速度及可靠性,而透過分享的回饋機制來改進,當這些觀念結合在一起之後,才有助於組織可以更有品質及效率的交付產品給客戶,而除了武功心法外,在實務概念上還有下列幾點:

 

1. 持續交付及持續整合:

持續整合是軟體開發實務,在自動化測試及自動化發佈的機制建立後,透過自動化流程來讓程式碼上到測試/正式環境,因此如果導入DevOps開發方法中的自動化部署,便可由開發團隊設定部署環境,由工具做自動化部署,減少手動以及傳遞的時間,且可以避免人為錯誤,改善軟體交付品質。除交付作業可以有效的「持續化」,並透過「持續整合」來更快速的發現及整合錯誤,進而改善交付品質。

 

 

2. 服務微型化:

一項產品若是架構過於巨大,不僅在更板上會綁手綁腳,更容易會有簽一髮而動全身的狀況發生,而若是採用DevOps概念的產品,爲了持續交付和整合,通常化把產品的分工切的更為細微,讓縱向的產品變成橫向發展,把產品服務從多功取向,變成個別單一的服務(或API),而每個服務的用途也盡可能的單一化。從過去大而久的發佈頻率,變成小而快,這就必須要依賴把服務微型化這個任務

了。

 


3. 基礎設施即程式碼:

基礎設施即程式碼是透過使用程式碼和軟體開發技術,來做部屬與管理基礎設施的實務,例如透過雲端服務或API的導入,讓開發人員和維運人員可以透過程式設計的方式,來和產品及基礎設施做互動,來取代過去手動設定的繁雜手續,進而實現持續整合的目標。而這樣的好處就是讓所有的定義都透過程式碼,來標準化作業模式完成快速部屬的目標。

 

而DevOps和傳統的開發方式,最大的差別就是在實務上是透過更細微的分工切割、更一致性的作業流程,以及更頻繁的發佈,來取代過去更版不易,耗時後久以及組織平行溝通的問題。透過小而頻繁的改進,才有機會讓產品更貼近使用者的意見和心聲,也可以有效率的讓產品進行成長。而自動化的導入更可以減少溝通落差造成的部署問題。

 

 

 

 

但記得,再多個概念和工具,都是為了彌平資訊流上的誤差,以及強化跨部門工作上的整合性,光只有導入機制還不夠,還必須透過定期的review和改進,才有辦法完成適合每一個組織或團隊自己的機制,這也才是符合敏捷式開發最重要的精神。

 

只有「快」還不夠,而是要讓整個生產機制的效率提高,才是提升團隊生產效率的不二法門。

 

補充說明:像AWS已經提供了企業客戶的DevOps雲端解決方案,大家有興趣可以去這裡看看唷!

https://aws.amazon.com/tw/devops/what-is-devops/

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧