logo头像

Edward.K Thinking

(學習DevOps系列 14) 建立持續交付和發布的流水線


持續交付流程是甚麼,就是讓我們從程式碼建置、測試、配置到佈署的連續性流程,在這流程中,會進行多項的測試或臨時建立環境產生我們要發布的管道,從自動創建運行基礎架構並且能佈署到正式環境。CD自動化,是讓我們發布流程中能一個流程接著一個流程持續下去,且在每個環節中都可以建立Check Point,讓審核者透過電子化方式進行檢核。藉由CD的流程,我們擁有交付過程的審核紀錄,這樣的檢核紀錄,可以滿足企業內的一些法規規定或是達到其他管理目標。在這些流程中,如果我們透過人工方式進行,依舊是可以完成佈署與發布動作,但是,沒有建立自動化的持續交付,會讓軟體發布週期會相對延遲,且手動過程將容易發生不可靠版本發布的錯誤,甚至拖長整體的發布時間,有時候,團隊必須在這發布週期中,再去解決其他臨時的問題。而自動化的好處,在於讓一系列過程是可以被控制,同時,它也是一種快速失敗的驗證方式。


而持續交付同時也算是一種精益精神的實踐,CD的精神在於透過版本控制,取得最新程式碼並且編譯封裝後,能快速的更新到正式環境。藉由自動化方式可以用最小時間佈署。並且,優化了整個佈署時間,同時減少不必要的閒置時間。此外,對於IaC的規範與監控這兩大因子的實踐,將幫助我們在持續交付的推進。持續交付已經逐步成為企業的要求,這最終目的依舊就是希望給用戶創造價值,且能在最短時間交付價值。


理想的CD實踐,是在正式環境中同時具有新的版本和現有版本兩套系統,而這時候藉由負載平衡系統,將用戶流量導引到新版本系統,透過監控行為發現若是有異常事件發生時候,可以再將用戶倒回現有版本。另外一種方式,則是透過Feature Tag的切換,這模式將可以透過使用者自行切換到新系統或是使用現有系統進行操作,進而監控相關事件


每當談到持續交付這件事情,大多認為ReleaseDeploy是同一個point,通常,必須說在大部分的情境我們會把這兩個視作同一件事情。但事實上,這兩者還是有一點區分的。眾多時候,談到建立自動化佈署管道,大多是要縮短程式碼Check in到Release之間的時間點。至於,Deployment,往往必須取決於商業需求與策略面,甚至是風險管理。雖然,佈署時候,現在有技術可以達到不停機情況下完成,實際上在這過程中依舊會導致服務品質下降,或是效能變慢。因此,在Deployment策略訂定前,必須要考量到整個商業需求。所以,真的要區分這個差異性,可以從下面方向去思考

  • Release: 是一種發行版本的概念,一般來說將某組版本進行封裝或是建置容器。在這過程中,會包含要執行發布定義中所需之任務和操作所需資訊。像是定義執行環境、變數。每個任務的任務步驟、任務參數和變數,甚至發布策略等等,通常一個Release Definition可以有多個版本,每個版本資訊都會在Release管理中被保存且顯示保存週期
  • Deployment: 佈署是為了讓一個環境可以運行系統的操作行為,基於Release定義中的設定和策略,在每個佈署中去建立、初始化和開始建立這個Release版本。

下圖可以瞭解這兩個差異點

因此,當我們自動化了Release流程,並不意味著也一定要完成自動化佈署才算是達到DevOps,有時候會因為一些因素導致無法立即佈署,像是必須等待API接口完成設定、審核通過、可以佈署的時間等等。


上述提到Release部分,在VSTS中Release管理中會有下面幾個主要的步驟,其他工具也因該會有類似功能,這些步驟依序下去,分別表示VSTS在Release工作順序

  • Pre-deployment approval : 當觸發新的佈署需求時,Release管理會檢查在佈署到環境前是否需要被批准,如果需要,會發訊息通知相關批准人員
  • Queue deployment job : 版本發布可以透過排程方式進行,透過自動化代理方式去進行發佈作業。
  • Agent selection : Release的代理設置,可以讓我們自行定義要透過雲端或是地端方式進行發佈
  • Download artifacts : 代理程式會下載版本中需要Release的相關套件
  • Run the deployment tasks : 運行佈署所需要的所有任務,將應用程序佈署到目標環境
  • Generate progress logs : 替每一個部署步驟創建詳細的Log,讓後續要檢查相關問題更為方便
  • Post-deployment approval : 完成環境佈署後,會在檢查是否需要在環境佈署完畢後再行檢核,如果不需要審核,將會自動進行下一個環境的佈署
上一篇