logo头像

Edward.K Thinking

(學習DevOps系列 6) VSTS在DevOps中的持續整合運用


談到Continuous Integration就會講到CI,那到底CI是要做甚麼用的,有一個解釋如下:


CI是讓開發團隊每次把程式碼放入版本控制時候,自動化的進行一系列的編譯和測試過程,並透過版本控制分享每一份程式碼。通常開發人員都是獨立工作,項目完成後再與團隊成員的程式碼合併一起,通常若是經過多天或多週來進行合併程式碼,將容易發生合併衝突,或是過多差異性程式碼,大家為了解決這些問題又要花費一些成本。CI通常會要求開發團隊的程式碼要不斷合併到branch中來避免這類問題發生


在CI中,關於Main’s Branch必須是乾淨且與正式環境的程式碼是相同版本,目前在VSTS上比較建議採用的版本控制類型是使用Git,透過創建短期的分支來隔離不同功能性的開發,開發人員可以透過pull request,將程式碼合併到Branch中,並刪除目前功能分支。每個團隊都因該建立符合自己團隊開發方式的分支策略,來確保主分支(Main)的程式碼品質。有了這些分支策略,團隊必須確認每個分支在程式碼交付後都會自動執行建置和測試過程,以確保開發週期的早期能找到錯誤,讓修復成本更低

持續整合的三要素

持續整合主要仰賴三個要素來實現,團隊必須使用相對應工具來實現這三要素,有三大要素分別為:版本控制持續整合自動化建置

VSTS中的Build Agents


當我們在VSTS中要開始進行DevOps的持續整合,必須先了解Build AgentsBuild Agents主要是負責進行建置的工作,在VSTS中,如果你要編譯程式碼或是佈署系統,最少需要一個Build Agent來執行這些動作,而當你日後的程式碼越多且開發人員也增加,將會不再只是使用一個Agent,將會需要多個Agent,這樣就會形成Agent Group。所以,VSTS要執行編譯管道是要透過Build Agents實現,這些Build Agents會被安裝在VM上面。在VSTS上的Build Agents有兩種類型,分別為:Hosts和Private Agents

  • Hosts: 這類型的Agent是被VSTS給管理,當然其版本也是VSTS來進行升級與維護,透過雲端管理Agent有它的優缺點
    1. 託管類型的,並沒有其他成本(除了錢之外),並且可以立即使用
    2. 直接安裝一些常用的軟體和元件
    3. 沒有互動模式
    4. 不允許使用者管理和登入它
    5. 不支持UNC檔案類型和XAML建置
    6. 不能有Hardcode的參考,固定驅動程式編號、資料夾和文件名稱
    7. 超過30分鐘,就會發生Time-out
    8. 當程序處理完畢後,會自動消失,每一次都必須從repository取得程式碼開始
  • Private Agents: 在自己的機器上建置,且必須根據你的需求自行設定
    1.需要一台VM,最小記憶體要2G,最好是直接安裝Visual Studio,當然要只裝MS Build也可以。需要安裝關於系統編譯的軟體,像是NPM、Nuget之類
    2.安裝VSTS Agent
    3.透過PAT讓Agent和VSTS連接

    詳細安裝方式可以參考[打通自動化雲端部署到地端-安裝VSTS Agent]這篇

VSTS中的System capabilities



System capabilities一種是Key/Value的設定檔,它可以確保每次編譯所用到的Agent是符合你編譯所需要的環境變數,這些環境變數自動會被列在其中,一些Framework也會被列在其中。每當Build開始進行排隊,會自動被指派有符合編譯的條件的Agent去進行編譯

技術債的來源和影響


技術債這名詞,不管在甚麼樣的研討會或是課程都會聽到這個名詞,且一般來說開發人員對於這個名詞絕對印象不好,也希望不要發生這些債,但是,往往事與願違,在實務上尤其在不同產業對於技術債的承受風險也不同,基本上要達到技術債的指標是很困難,因此,短期的技術債承受力,必須考量到團隊、企業業務和時間之間的影響去判斷,我們可以接受多少技術債,如果只是一昧避免技術債,忽略的商業需求和時間成本,整體來看反而影響更大。談到這,也來說說原理上技術債會生成的原因

  • 程式碼撰寫風格和標準
  • 單元測試設計不足或是較差
  • 忽視或是不了解物件導向設計原則
  • 對於技術、架構和方法的不熟悉,像是忘記系統屬性設計、使用者體驗、擴展性和維護成本
  • 創建一些不需要用到的程式碼或是架構
  • 註解和文件不足
  • 死代碼、沒必要註解

以上大概是大眾歸類的一些生成技術債原因,當然,在不同組織或團隊下,產生技術債方式也不同。通常技術債的影響會隨著時間的推移,最終,修復和重構這些技術債的時間成本將會大大影響到團隊專案的進行以及執行力。


解決這問題,實在沒有很多標準解法,就如我剛剛所說,為了解決技術債而忽略商業需求,也不是一件好事。在兩者間取得平衡方式就是透過不斷迭代、在新需求開發之餘,也修復先前一些技術債


在持續整合的流程中,除了自我團隊對於系統理解重構外,另一個方式就是透過創建多類型的自動化測試,透過有效的使用測試應用程式。頻繁的運用測試,當不同程式碼被Check in後可以很快速測試這些應用程式是否還可以正常運作。通常,在持續整合過程中,其中重點在於發布和測試管理流程,典型的持續整合測試會包含這些

  • 自動化建置和測試
  • 建置應用程式的佈署和測試的環境
  • 配置應用程式佈署和測試
  • 執行測試和分析測試結果
  • 設定整個工作流程是持續性的
  • 選擇一套可擴展性的建置工具
  • 選擇一套測試框架
  • 所有流程項目是可以擴充,可以依照業務或系統需求,自由增加
  • 簡化設定和佈署的體驗
  • 能分散式的方式對於遠端伺服器進行大量不同的自動化測試
  • 了解測試報告,並且深入了解測試失敗原因,提升發布品質

技術債可能是蓄意造成或是無意之間造成。對於已知的技術債,因該盡早記錄下來,並且進行修正和商業需求的程式碼變更,通常已知的技術債還不是最嚴重,最嚴重通常是無意之間造成的,通常要修正這之前,必須多加檢測和識別進行確認。一般來說檢測技術債方法有幾種

  • 人工檢查
  • 程式碼分析
  • 測試覆蓋率
  • 程式碼度量
  • Class的繼承深度
  • Function可維護性指數
  • Class之間的耦合性
  • 程式碼架構圖

當然在VSTS額外的工具有

  • SonarQube
  • NDepends
  • Built-in-Tools

最後,談到就是程式碼Check-in的規範,在VSTS中的管理者可以去設定程式碼Check-in規範,大概可以分成三項

  • Builds: 在Check-in前必須先確認前一次Build是成功的
  • Code Analysis: Check-in之前進行程式碼分析
  • Work Items: 必須與工作項目進行關聯

這些Check-in的驗證,是被安裝在單一個Visual Studio內,如果有多台都安裝Visual Studio,必須個別設定這些規範

上一篇