2017年12月16日 星期六

[從.Net工程師的角度來看DevOps 25]在Visual Studio Team Services執行Build Script和CI Server總結

image
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/ 和 https://blog.xebialabs.com/2016/03/21/essential-devops-terms/

在上一篇([從.Net工程師的角度來看DevOps 24]免費build私人Repo的CI Service - Visual Studio Team Service介紹)了解了如何用Visual Studio Team Services(VSTS)的內建Template來build範例專案;在設定的過程,其實沒辦法直接使用內建template,會需要調整一些參數。

這些調整的內容和AppVeyor要調整的非常不一樣,造成了如果要換CI Server會花一些時間在這些瑣碎的細節上面。

這篇將會看看,如果要把VSTS改成用build script來build專案,會需要做些什麼。

調整VSTS來執行build script

首先,先建立一個新的build definition,這次在template的部分選擇empty template:

image
選擇emptytemplate

進來了之後,只需要加入一個powershell script的step並且指向專案裡面的build script,並且選擇Save & Queue

image
設定powershell script
這邊要注意在step前面的Get Sources需要設定和github連上。

之後build就會開始,並且跑完了之後可以看到log資訊和我們在local執行的時候是一樣的內容:

image
執行完的結果

簡單總結CI Server和build script的關係

目前為止,看了兩個CI Server:AppVeyor和VSTS。在這裡面會發現2個問題:

  1. 每個CI Server設定方式都不同
  2. 拿不到build完的內容 - Artifact

每個CI Server設定方式都不同

在AppVeyor,已經幫使用者區分好build、test、deploy等等階段,只需要設定這些階段要執行什麼,AppVeyor就會建制完。

在VSTS則是用step的概念,由使用者自己定義每一個階段要執行什麼,然後有一些已經定義好符合某些專案的template,方便快速設定。

可以想象每一種CI Server有自己的設計理念,如果今天沒有build script要設定每一個CI Server其實很麻煩,尤其是當CI Server更新版本的時候,位置和內容可能都會不一樣,需要花時間再去研究。

反過來說,如果把build邏輯都整合到build script,不止不會被綁到某一個CI Server,並且不管在哪一個CI Server只需要執行那個build script即可,並且build script在做什麼非常清楚, 不像如果依賴CI Server,不能夠肯定裡面到底執行了什麼操作。

拿不到build完的內容 - Artifact

當程式碼build完之後,一定會有一個產出,例如library會是一個dll,這種產出在CI有個名稱叫做Artifact

如果眼尖的朋友,會注意到,如果用CI內建的方法,會產生出Artifact,但是執行build script 會沒有

image
VSTS內建template build的結果,artifact有東西

並且build過程有些資訊,像是測試情況、測試涵蓋率(Code Coverage)這些在自己的build script也會看不到。這是因為目前build script還沒有結合CI Server,這也是接下來需要補強的部分。

結語

目前build script基本已經完成了,但是如果沒辦法自動打包產出結果,對於發佈和整個CI效用就大打折扣了。

因此,接下來將會開始進入另外一個階段,Package的階段。

而在package裡面,有個非常重要的概念是版號(Version),因此下篇將會介紹版號的重要性。


沒有留言 :

張貼留言