2016年12月3日 星期六

[iThome第8屆鐵人賽 03]CI - VS是如何建制(Build) .Net專案

在上篇了解到說什麼是DevOps之後,我們就開始探討第一個部分,也就是Continous Integration (CI)。

CI最基本的核心就是build專案 - 所以我們需要了解一下到底VS是如何build專案的,只有了解之後我們才能夠把它腳本化,也才有可能自動化。

因此,這篇將會介紹:

  1. VS到底如何建制專案
  2. 什麼是build tool
  3. 為什麼接下來系列會選擇使用psake作為build tool

VS到底如何建制專案

我相信這個問題,很大的可能寫了2~3年的.Net programmer可能都回答不出來。原因是VS實在太方便了,.Net工程師太依賴於這種便利性,反而對於底層運作不需要那麼清楚。

說實話,我覺的這個是 好事,因為工程師就能夠focus在重要的地方,不過壞處就是如果有問題或者想做點調整可能無從下手,因為從來沒有那種概念。像我當初轉到Eclipse就有發現,很多VS幫我們做掉了,而 Eclipse就需要手動設定

其實別說建制專案了,很多工程師連程式最小單位,如何編譯一個cs檔案都不知道如何去做,所以,我會從最底層開始說起。

如何編譯CS程式碼

我們都知道程式碼是需要編譯才能夠使用,但是到底如何編譯呢?

其實很簡單,當我們安裝了VS的時候會自動安裝一個csc.exe的程式,而這個程式就是c# compiler。

我們可以打開visual studio安裝時候帶的Developer Command Prompt, 然後這個時候建立一個簡單的hello world cs檔案,然後輸入:csc helloWorld.cs,我們就會得到一個helloWorld.exe, 執行起來就是我們的程式

image
先建立一個helloWorld.cs的檔案image
打開Developer Command Promptimage
在編譯之前沒有helloWorld.exe,編譯完之後多出了helloWorld.exe,並且執行起來正常

了解編譯器之後,我們會發現可以編譯程式碼了,但是當我們有大一點點規模的專案的時候,用csc實在太不方便了。更別說我們有時候要用Debug模式編譯,有時候要用Release模式編譯,有時候要 整個rebuild - 這些如果都自己下csc指令來達到會瘋掉,而且又不能在專案之間共用。工程師懶是一種美德,這個時候就有build tool的出現,而VS就是使用了MSBuild這個build tool 來建制專案。

什麼是Build Tool

Build Tool 就是透過設定Task,然後執行這些Task達到編譯程式碼的工具

通常來說build tool的task是有相依性,例如Task A 只有在 Task B執行之後才能夠做,透過把編譯需要做的事情包成一個一個的Task,然後透過這種相依性關係,達到執行起來整體是一個chain。

build tool的task的設定有些是參數化的,因此像是要用debug模式還是release模式其實只是一個參數不同,但是其他都一樣的動作。

Visual Studio預設所使用的Build Tool就是MSBuild,而MSBuild是一個xml base的build工具。

當我們用記事本打開那些solution或者csproj的時候就會發現,其實整個檔案是xml格式,而那些就是在定義MSBuild所看得懂的參數,當VS要執行build的時候,就依照這個csproj的定義去執行 應該的動作。

到底應該用什麼build tool?

說實話,build tool實在太多了,從VS預設用的MSBuild,到JS base的gulp,到java的gradle,到用F#寫的FAKE和C#的CAKE,到我們將來會用的用PowerShell寫的Psake,是在是太多了。

到底應該用什麼基本上取決於團隊,不過有幾個點可以考慮:

  • 這個build tool需不需要額外安裝什麼?要考慮我的build應該要在任何地方都能夠執行,越少這種OS的dependency越好
  • 這個build tool用的多不多?也就是eco system好不好 - 這樣很多網路上範例都可以直接拿來用
  • 這個build tool好不好寫?符不符合習慣 - build tool最終是要給人用的,好不好用,用不用的習慣非常重要

為什麼不直接用MSBuild?

從上述幾個考量點,會發現,MSBuild既然VS預設就用,那應該和popular,範例應該也很多,那為什麼還要考慮其他的build tool?

其實原因有兩個:

  1. MSBuild是xml base - xml字定義task的時候看起來很繁瑣,明明很簡單的東西定義起來很費勁,看又不容易看
  2. 相較於我們會用的psake(powershell),MSBuild原本的視野有點狹隘,他關注於建制.net的東西,但是隨著前端興起,隨著我們要自動化的東西越多,MSBuild不是做不到,而是 做起來比較麻煩。反過來來看PowerShell,本身就是為了讓MIS能夠腳本化達到自動化的工具,很多Windows東西都可以透過PowerShell來設定,因此決定使用psake。

psake到底是什麼?

說了那麼多,希望對build tool有點概念(就算沒有,等到我們進入實作的時候都會明朗),那接下來就介紹我們之後會使用到的工具psake。

psake是一個powershell的module,所以基本上在撰寫psake的task設定的時候,整個powershell的能力我們都能用到(換句話說包含整個.Net Framework我們都能用到)。

psake的唸法和日語的清酒sake是一樣的。

psake的好處有:

  1. 我們是建制.Net專案,所以建制的機器都在Windows上面(這邊不考慮.Net Core) - windows 7 之後一定有powershell,所以基本上要使用psake不用裝什麼(除了psake module)
  2. 因為psake只是powershell的module,整個powershell的平台功能都能使用,換句話說網路上任何powershell有關的資源都能用 - 要知道powershell建立的目的是為了讓MIS和工程師 不用每一次為了一些小功能就要開發一個console程式的平台
  3. 可以藉著了解psake了解powershell的能力 - 相信大部分工程師都不太用powershell,但是其實他功能很強大,很多windows設定都能夠透過powershell來達到 - 很多功能也都可以透過 寫powershell script把日常自動化 - 像我日常用git就是用powershell的module posh-git - 所以powershell其實都最好了解一下

結語

希望這篇能夠讓大家了解到什麼是build tool,和怎麼選擇一個build tool。

這幾天的理論相信大家一定都煩了,接下來開始我們將會進入到實際操作的部分。

在下一篇,我們會先了解怎麼使用psake,未來的demo code的架構會如何等。

沒有留言 :

張貼留言