logo头像

Edward.K Thinking

(學習DevOps系列 1) 重新認識DevOps

本系列單元,為重新認識與學習DevOps的筆記與歷程,過程使用的工具為VSTS

什麼是 DevOps


DevOps是集合人、流程和產品(工具)三個面向,並能持續交付價值給我們的終端客戶。DevOps本身並非是一個工具或是軟體,並無法直接安裝它。當然,DevOps不僅僅是自動化或是做到infrastructure as Code,DevOps是團隊可以遵循整個產品開發到交互的過程,最終,交付產品價值給我們的客戶


要推進DevOps到組織或是行為中,可以使用OODA模式,來清楚定義組織對於DevOps的基本架設。何謂OODA,OODA分別為觀察(observe)、定位(orient)、判斷(decide)和作為(act)。此概念緣起於一開始的設計是要讓戰鬥機飛行員不要被擊落,它也是思考如何領先競爭者的好方法。現在也常被用來闡述商業行為和學習過程。這種模式適合需要在人與人之間合作努力的地方,增加整體的敏捷性

快速交付循環


在DevOps其中一個核心思維,就是縮短發布產品到客戶的週期。下圖,為緩慢交付和快速交付的差異性


從緩慢地交付過程中,可以輕易的看出來,很多時候,我們必須等待很長的時間,才能進行開發,這時候要更改的程式碼或是佈署流程,會是相當多的,當每個周期都必須經過異動大量代碼或是流程,將容易造成錯誤的事情發生。大多數的公司和團隊,會認為只要把交付時間延長,或是延遲上線的時間,就可以為自己找到更多測試時間和更完整的整合性測試,並可以確保到100%都沒有問題,或是認為這樣才是更完整後,才進行交付,甚至,要到達需求穩定不在變化時候,才是最安全的交付時間


但事實並非如此,隨者交付時間的延長,要修復或是還原線上發生的錯誤,這將會是非常的困難,每個交付版本差異性過,將會導致難以找到問題發生的原因和位置。造成維運成本增加或是許多功能同時發生異常。讓我們認為我們要花大量時間進行全面測試和大量交付需求的同時,也會花更多時間在後續佈署和確保系統穩定的成本與時間


若是進行小批量的快速交付週期,在這個週期中,非常頻繁的佈署,但每次佈署版本間的差異是較小的,變化也是較小的,將可以確保對於線上系統的影響層面較小,且同時,可以做較明確的測試。藉由快速交付,快速得到反饋,才可以快速向我們的客戶學習

DevOps 循環週期


在過去十幾年來,Agile的軟體開發模式,在軟體開發的圈子中,快速的普及與被推廣。敏捷的過程加快了軟體開發的流程和讓佈署的節奏加快。然後,傳統IT中,維運團隊開始不斷加快發布的節奏,而原本為維運團隊的流程雖然是可靠的,但是還不夠敏捷。開發與維運團隊就開始會發生錯誤。也因此透過DevOps,從開始創建、交付到最後監控,團隊內都可以緊密合作,透過持續性的發布來提高整體的品質

DevOps 實踐和習慣


Sam Guckenheimer中提到了,要進行DevOps,團隊必須實踐下面七種流程

  • Configuration management
  • Release management
  • Continuous integration
  • Continuous deployment
  • Infrastructure as Code
  • Test automation
  • Application performance monitoring

後面也會針對這七個做簡單的描述,以及具備下面七個習慣

  • Team autonomy and enterprise alignment
  • Rigorous management of technical debt
  • Focus on flow of customer value
  • Hypothesis-driven development
  • Evidence gathered in production
  • Live-site culture
  • Manage infrastructure as a flexible resource

    Build 和 Release 的管道


概念上DevOps是需要建構自動化建置和發布。理論上,發布的管道是決定如何將軟體交付到用戶的流程,所以,把交付的流程具體化就是Release pipeline。而在這管道之間,會有發生許多種情境像是建置代碼、環境配置、交互測試以及到最後確認所有程式碼都是OK的。正常來說一個Release pipeline策略會需要涵蓋Service、DB、Web和行動裝置軟體,甚至包括下面這些流程

  • Binary package consumption
  • Continuous integration builds
  • Package publishing
  • Automated testing
  • Continuous delivery

行動化APP的佈署是會和一般軟體佈署是不相同的,且如何從Mobile App去取得客戶反饋資訊也會和一般應用系統有所不一樣

Binary package consumption

透過Package管理,管理那些可被重複使用且被信賴的元件。像是我們常常使用Nuget一樣,當使用這些Package時候,隨著它們不斷被更新,你也可以不斷讓自己應用程式持續更新,這些Package元件,不因該直接被儲存在你的版本控制中,而是要儲存在Package Managemnet裡面,藉由Feeds方式來取得

Continuous integration builds

持續整合建置,是程式碼被簽入到版控中就要被觸發建置。因該被快速完成建置,其中還必須包括自動化測試

Package publishing

對於Package的發布,要使用版本號,且是建置和發布相同,這些資訊因該是要被公開

Automated testing

測試盡可能包含單元測試、整合測試、UI測試、效能測試和負載平衡測試,這些測試要能在不被中斷情況下完成

Continuous delivery

當自動化建置完成後,就立即自動被觸發。這個過程中會取得要發布的應用程式,並將要發布過去的環境,優先配置好其目標環境的相關設定,並自動化部署到該環境中

上一篇