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

• VS到底如何建制專案
  
  • 如何編譯CS程式碼
• 什麼是Build Tool
  
• 到底應該用什麼build tool？
  
  • 為什麼不直接用MSBuild？
• psake到底是什麼？
  
• 結語

在上篇了解到說什麼是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， 執行起來就是我們的程式

先建立一個helloWorld.cs的檔案

打開Developer Command Prompt

在編譯之前沒有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的架構會如何等。