logo头像

Edward.K Thinking

(學習DevOps系列 2) DevOps中的Backlog、Version Control和Testing

在前一篇談論到DevOps的一些概念,現在來談談在DevOps針對Backlog、Version Control和Testing這三種工作該怎樣進行。DevOps的文化轉變中,其中有一個重要的變革就是在於Backlog的等級,在鳳凰項目一書中有提到兩種類型的工作,分別是商業專案(Business Project),這邊可以簡單說是使用者需求,以及工程專案或IT內部專案兩種

Backlog


這兩種類型的工作,都因該被歸屬到整個DevOps流程中,針對使用者需求工程專案或IT內部專案兩類的定義如下:

  • 使用者需求: 來自企業商業所需要的功能或是使用者需求專案
  • 工程專案: 在使用者需求中必須去建構的Infrastructure的工作項目或是維護該需求的專案,以及系統的改善專案。這些類型的需求,也因該與使用者需求一樣,放在同一個Backlog去被追蹤和完成,並不可以被排除在工作項目之外

大多數的團隊,很容易把第二項給忽略,甚至認為做那些是無價值的。在DevOps持續改進的精神中,為了不斷改善、優化系統的流程和適應性。建議是要花整個團隊的20%時間去給這些非商業功能需求的項目,像是系統的資訊安全、Infrastructure、工程流程…等,讓這些支持商業需求的項目,可以更好及更穩定。若是,長期不把時間分配到這些項目上做改善,容易累積許多的技術債,甚至,會造成日後更多非計畫性或是預期性的工作,像是系統穩定性、漏洞…等等


而將一些計畫外的工作或是復原工作,附加到原本的計畫工作項目中,很容易造成工作切換上的瓶頸和混亂。有時候會讓原本backlog有了更長的Lead Time。往往發生這些事件,就是長期忽略技術債的消除或是在日常沒有一些改善的方案去進行。當團隊開始程式開發到代碼第一次被佈署到正式環境,這期間的周期,可被定義為Lead TimeLead Time本身是可以被衡量的指標,而透過DevOps的一些實踐方式,有助於改進它

Version Control


大多數的團隊或是企業,都知道使用版本控制來管理程式碼,但是,並非所有人都可以有效做到這一點,有時候,大多數的版本管控作法只像是檔案備份,而忽略兩種版本控制的方式

  • 有效的建立版本控制分支策略
  • 將工作項目連接到程式碼,達到透明度

建立分支的策略有很多種,最好的方式是依照組織或團隊的特性進行訂製。較為簡單作法,就是建立一個分支,這個分支建立持續整合流程,每當程式碼被Check-in時候,就自動化佈署到開發環境中,透過這樣方式,再與工作項目結合,就可以輕易的知道有那些變更被發佈到開發環境中。然後,再把開發環境的分支提升到測試或是正式環境,這樣相同的程式碼將會被佈署到正式環境,而不會出現未經過驗證或是檢查的代碼被發佈到正式環境。此外,在佈署到任何環境時候,必須確認所有更改是跟商業或業務需求是一致的

工作項目連結程式碼(Connecting work to code)

把工作項目與程式碼連結一起,主要是一種簡單驗證程式碼變更和需求是相關性,並且透過建置和佈署後,從使用者的反饋中去了解這次的代碼變更。定義分支最簡單的規則就是保持低維護性和較高的可持續性。若是有一個分支,長期很少有合併的動作,那麼將可能累積隱藏不少的技術債


如果團隊或是企業,還沒開始做有效的版本控制機制,那麼開始使用版本控制這件事情是重要的。一個好的開始可以從開始學習Git版本控制模式下手。


從DevOps的團隊來看,infrastructure的處理方式是和軟體開發因該是要相同的。其中,Infrastructure as Code (IaC)就是透過程式碼去管理和建置機器環境,這些程式碼是需要被版本控制的,同時,也要能與團隊協同合作完成

Testing


在測試部分,DevOps提到是持續進行測試,這樣測試是包括程式碼和佈署環境的測試。不過,在實務上,持續測試是持續交付中最困難的一部分。但持續測試最終結果將會在整個交付過程中,提供高品質的軟體,並提升我們佈署到正式環境前的信心程度。但怎樣的要接受怎樣測試成果,是可以由團隊規範,建立一個Bug Cap規則,在這規則下進行持續交付的動作

  • 自動化: 自動化是測試的關鍵,從單元測試、整合測試、UI測試到負載平衡測試都是屬於持續測試一環
  • 使用增量和迭代方式: 越接近正式環境的上線,其測試的深度會不斷前進

Beta testing and progressive exposure

Beta testing和漸進式公開功能是在DevOps在正式環境中,接受終端用戶反饋的重要方式和策略

  • Beta testing: 這是一種提供給外部使用者測試的方式,將發布的版本提供給受限人員進行測試,讓版本發布到正式環境區做更多測試,或是從受眾群體中得到一些反饋
  • Progressive exposure: 類似Feature flag,把一些新功能或技術,讓少量的使用者可以進行切換到新版本或是新功能使用,進而得到反饋。然後再逐步發布給大量使用者去使用這些功能

以上兩種方式都是透過先給小量使用者進行測試新功能,由他們測試後,迅速提供反饋意見。透過,這樣的快速反饋,可以讓開發團隊知道哪些功能是有相關性、有價值的,並且藉由這些資訊,做為下次改進和策略應用的依據。

上一篇