本來想說要來講Pull Request，但想一想先把Pipeline 簡單說一下好了，讓我們把整個SDLC做一個完成後，再來跑一個循環。
我們在寫完程式之後，一定會需要把成品給需求單位進行測試，確認我們寫出來的東西被買單，然後才可以上到生產環境嘛。以前在電子廠的時候，如同我之前說的，有一位強者幫我們把source code 透過jenkins每天的build image，交付給Q單位進行測試，測出問題就回報，我們就繼續修。所以有人幫我們鋪墊好自動化這件事情，讓我們的研發團隊的確是更有生產力的，每天只要跟software PM 撿Bug回來一直修就好，不需要管其他雜務。
來到這裡後，讓我回憶到最早的過去，渾沌年代。
筆者在這裡先回憶到最早期學的程式語言，.net framework，這個程式語言是筆者從大學就接觸的，那時候印象深刻visual studio 2003 + .net framework 1.1。其實一開始學校教的是Java，但用dreamwaver寫程式老覺得不太會，對於http post又認識的不夠，所以那時候都是瞎寫。後來接觸了visual studio，突然覺得這個IDE真的好好用啊！我不需要學會任何指令，我就可以在本機把服務跑起來驗證寫出來的結果，而且Debug的方式也很直覺，設定一個中斷點就可以馬上知道自己寫了什麼鬼東西。在加上那時候他也自動的code behind，就覺得自己好像很會寫程式，產出很快。
那以前交付程式，也沒有甚麼自動化，反正就是手動把程式放到IIS指定的目錄下，會跑就好了。而且.net framework很妙的是，你可以deploy source code 到指定目錄下，aspnet_compiler會自動編譯後幫你跑起來。所以整件事情，根本就沒在自己編譯，就是把本機source code 放到IIS的目錄下而已。
沒想到，我來了這裡，還是有很多系統是使用這種部署方式，伺服器上面充滿了原始碼。而且，以前我們是自己放到學校專題的伺服器裡面的目錄，不論是用ftp或是遠端桌面，整包給他蓋過去。現在就是要申請後，請作業人員一樣用遠端桌面連線到資料夾下，把修改過的程式碼貼上去。
開發人員只要寫出一大堆的文件，蓋過一關又一關的印章，就會有一個專屬的作業人員，幫你把你這次改過兩行的那隻程式，自動的有另外一個人的手幫你放到要佈署的位置。
由於visual studio 真的太好用了，IIS又太聰明不用放編譯檔就會跑，所以以前都沒有認真學過用指令的方式進行編譯，直到這次的機會才認真的碰過msbuild，所以一開始也常常不小心踩到一些雷，但大多數也都解決了。
其實以前在內部測試伺服器試作自動編譯時，最大的問題就是裝套件。這分了兩個層級，一個是編譯本身所需要的環境，一個是編譯時會需要的套件(如nuget)。
.net framework的版本非常的多，後來又出現了.net core，而且我們非常多外包的系統，各個版本的runtime都有，所以光安裝東西就會搞了很久的時間。那編譯要的套件又是另外一個議題，因為像我們在本端即時進行編譯的時候，其實nuget都會透過internet去把對應的package抓回來，但如果在我們的測試環境，那是內部的伺服器，跟外界的網路根本就無法連通，大家就會想一些歪招，例如....把套件也丟到版控系統上面去，結果每個專案包都好幾百mb，source code 才佔不到多少容量，都是package。
那以前一直都覺得這件事情我們根本就沒救了，要做自動編譯，就要搞好幾台主機來處理這件事情，而且既然有主機，就表示他的弱點會不斷被資安工具每半年掃描出來，就要開始修補到天邊.....。直到去年我在找一些解決方案的時後，跑到了微軟的某場workshop，看到了微軟的工程師用了hosted pipeline，驚為天人！我當下就下定決心。
我要用這套服務，所以我要雲端版本。
要知道，有一套環境可以依照你的需求代理作業，而且甚麼工具在上面都裝好了，還可以不用理他的安全性修補問題，這對這個行業的AP人員是多大的吸引力。
用一句話來說，就是微軟幫我們做了一些image，裡面裝了一大堆我們需要的東西，在我們需要的時候即時叫起來進行任務，結束任務就刪除的好東西。
Microsoft 裝載的代理程式
上面的連結中就有所有的清單，目前提供以下的image讓我們使用，截圖如下：
由於他還有提供windows 的編譯環境，這表示我們公司那一堆.net framework 的程式，也都可以走這整套流程。況且我也不需要對於映像檔安全性或是主機安全性，每半年都要想盡辦法進行修補的動作，這對我真的是天大的好消息！
丞相起風了，這風很適合燒曹操的船
iThome鐵人賽
看影片追技術