自動上線測試已經不潮了，你有跟上DevOps的潮流嗎？

相信你們必定都（沒）有使用過Facebook的經驗，必定對他的快速改版私絕不陌生，可能早上醒來時發現「贊」的圖案忽然從實心變從空心，或是開始多了一些繽紛酷炫的功能(像是直播、限時動態..等等)，但你能想像一下嗎?在過去十年前，大部份軟件服務上的版本更新，都只能像是Office每一年的一期一會來作推陳出新，但新的功能可能沒解決到用戶的痛處，反而增添了更多沒必要要的麻煩。

因此在快速變遷的時代裏，這種快速、持續發佈新版本的特性，儼然成爲了適性生存的不二法則。你能想像Flicker天天至少會有10次以上的服務發佈嗎?若是在傳統的開發方式，一旦有新功能的釋出，若是使用者體驗很差須要改進就算了，但若是有BUG的話，卻須要等待一個月或一全年的時間才能解決，這樣的產品你還會想用嗎?

因此與傳統開發方法那種大規模的、低頻繁的發佈，敏捷方法爲基礎的DevOps，目的就是爲了提高了發佈頻率的速度與效率，從過去的「年」、「季」，提高到「月」、「周」，甚至是「日」。

但快速發佈的概念，並不是是「開發團隊」的步調快速緊湊起來就能夠達到的方式，由於每個新版本的Release，除了靠開發團隊的努力外，也須要「維運團隊」、「測試團隊」的努力，纔有辦法相輔相成，但一般在公司裏「開發」和「維運」都是隸屬於不一樣的部門的業務，開發目標是推陳出新，但維運部門在意的是系統穩定性及可靠性，在這樣二者恆相沖突的情況下，又該如何透過整合來達到「快速」的目的呢?

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

關於DevOps

先介紹一下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的方式，來達到提升發佈速度及可靠性，而透過度享的回饋機制來改進，當這些觀念結合在一塊兒以後，纔有助於組織能夠更有品質及效率的交付產品給客戶，而除了武功心法外，在實務概念上還有下列幾點：

一、 持續交付及持續整合：

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

二、 服務微型化：

一項產品如果架構過於巨大，不只在更板上會綁手綁腳，更容易會有籤一發而動全身的情況發生，而如果採用DevOps概念的產品，爲了持續交付和整合，一般化把產品的分工切的更爲細微，讓縱向的產品變成橫向發展，把產品服務從多功取向，變成個別單一的服務(或API)，而每一個服務的用途也儘量的單一化。從過去大而久的發佈頻率，變成小而快，這就必需要依賴把服務微型化這個任務了。

三、 基礎設施即程式碼：

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

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

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

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

好雨雲xDevOps

好雨雲提供面向業務的DevOps工做流最佳實踐，遵循以應用爲中心的設計理念，利用容器技術、微服務架構和軟件定義系列技術解耦服務器和應用，清晰界定開發與運維之間職責，企業IT將能夠零負擔落地DevOps工做流，經過好雨雲獨有的「應用級」生產面板和「業務級」運維面板，專一於業務並以以自動或自助方式完成計算資源運維工做，達到降本提效的目的。

進一步瞭解好雨雲DevOps：https://www.goodrain.com/scene/devops