前言

終於完成這次IT邦幫忙鐵人賽，深刻有一種如釋重負的感覺！！
這次算是第二次參賽，比起兩年前的經驗，今年的事先規劃加上整年所學習的技術整合，文章內容比較完善也比較一致。這個月每天回到家用完餐，寫鐵人文章到凌晨已經是規律的行程，理所當然，假日也不例外：處理完家務事與雜事後，往往開始寫文章的時候也已經是晚上。整個過程最煎熬也最花時間的部分是實作與範例，每篇文章幾乎都有安裝、程式與實作範例，而並非只有理論與描述，因為我認為透過程式碼與實作可以讓技術學習更加扎實，故每個步驟能截圖就截圖，能提供程式碼就程式碼。

感謝所有看到最後一篇的讀者，這次系列文章雖然有事先規劃，但仍舊不夠完善，抵不過一日一篇的壓力，文章品質與內容不如自己預期的好，在此先跟各位致歉，後續這鐵人賽期間內，會再檢查與修補內容，讓這系列文章更加盡善盡美。

前言

前面兩篇簡單的介紹，不免俗地還是要與TeamCity扯一點關係(笑)。
本篇文章將透過 TeamCity.Virtual 套件協助我們整合 docker，這篇範例舉的實際案例不是很實用，但可以讓您知道如何透過這個套件整合docker，若有觀念錯誤或任何建議，希望各位先進指點。

前言

上一篇我們簡單的介紹如何透過 Skype bot + TeamCity Restful API 對TeamCity 進行操作，但若要得知工作完成的情況，定時去查詢其實相當沒有效率。運氣很好的事 TeamCity 有許多的 plugin 可以使用(雖然有些好像年久失修，但對 slack 支援度蠻高的)。在這一篇文章我們將用一個簡單的範例，透過 web hook 發送訊息到 skype bot MessageController，告知使用者目前情況，若有錯誤或任何建議，請各位先進不吝提出，謝謝。

前言

上一篇我們簡單介紹了 Skype Bot C# 程式中如何傳送與回覆訊息，而在這一篇，我們將簡單介紹如何讓機器人觸發 TeamCity build confguration，讓您直接與機器人聊天，就能完成自動化建置工作，若有錯誤或任何建議，請各位先進不吝提出，謝謝。

前言

前面兩篇我們簡單介紹 JMeter 安裝、基本使用、BeanShell 前/後至處理器與語法，透過這些基本的操作，您可以對於專案內的WebAPI開始撰寫測試的腳本。在這一篇我們將透過 JMeter plugin for TeamCity 整合TeamCity 與 Jmeter，讓您透過 TeamCity 也能進行壓力測試並觀看結果，若有錯誤或建議，請各位先進不吝提出，謝謝。

前言

前面連續介紹 18篇有關 .NET Core 持續整合相關指令、gulp 件、IT架構與佈署流程介紹，在本篇文章，我們將彙整前面的文章，透過一個簡單的專案架構，簡單說明如何撰寫前、後端 Build Script。若有錯誤或任何建議，請各位先進不吝提出，謝謝！

前言

原先在這一篇，要說明範例專案架構、規劃流程與Build Script撰寫，但經過一番思考後，認為伺服器篇說明篇應該先說明才不容易混淆。在本篇文章將簡單彙整，當 IT Team 提供新的伺服器與作業系統環境後，需要安裝那些套件與注意事項，這些是過去小弟與 IT Team 合作與碰壁的經驗，提供給有興趣的朋友參考。若有錯誤或任何建議，請各位先進不吝提出，謝謝。

註: 本系列文章主要以實作 .NET Core web application為主，作業系統、套件以下列為主
環境： Windows Server 2016
安裝套件：

1. .NET Core 1.1 SDK
2. .NET Core Windows Server Hosting
3. IIS
4. Nodejs
5. Windows Update

前言

在前面六篇文章，我們介紹有關實作 Deploy 的方法與處理 CDN 環境下遭遇的問題。而在這一篇文章我們將要介紹最後一個步驟：變更站台實體路徑。如同先前文章提過的，這一個步驟為的是避免在 Deploy 過程中，使用者進行操作可能得到網站錯誤訊息的處理方法，若您的產品有固定維護或更版時間，或許可以跳過這個步驟。另一個好處是，若在 Deploy 過程中發生程式或系統等不可預期的錯誤，仍有機會可以切換回前一個正常版本，漸少服務停擺時間，降低損失。本篇文章若有錯誤或任何建議，請各位先進不吝提出，謝謝！
註:因.Net Core與.Net Framework皆可使用此方式變更實體路徑，故本篇文章為參考個人部落格案例撰寫

前言

上一篇我們透過 gulp-replace 與 gulp-hash 更改檔案名稱與引入程式名稱方法處理 cache 的問題，而在這一篇，提供利用多一層版本資料的方式解決相同的問題。這種做法的另一優點在於：若佈署後發生程式錯誤情形，仍可以透過引入上一版本資料夾的方式先行處理，減少服務無法運作時間。若有錯誤或任何建議，請各位先進不吝提出，謝謝！

前言

CDN 的原意是透過節點與快取方式於增加網站的速度與穩定度，但在開發、維護專案的過程中，常常遭遇到更新javascript、css或圖片檔案後沒有作用的情形發生(因為快取)，有些 CDN 網站有提供 flush 功能清除快取，但使用上卻有次數限制，若修改程式次數較頻繁，仍會遇到修改無法及時生肖的問題。在收集 CDN 相關資料後發現多數開發人員建議在 CDN 上放置靜態或不常更動的檔案，若將常異動的檔案放上則違背 CDN 的原始用意的意思，但為了解決程式更新問題，本篇與下篇文章將透過一些**特殊方法(旁門左道)**的方式進行排除 cache 問題(僅供參考)，若有錯誤或任何建議，請各位先進不吝提出，謝謝！

前言

CDN - 內容傳遞網路，透過網路連結各地強大處理能力的伺服器，快速傳輸照片、音樂、文件...等檔案給使用者，提供快速、高傳輸性與低成本的服務，也成為現今網站快速與穩定的解決方案之一。個人因為工作關係，曾經接觸過2-3種不同 CDN 服務，而有些 CDN 可以透過 FTP 傳輸檔案，您可以利用上一篇文章方法實作 deploy task。而在這篇文章，我們簡單介紹如何在設定 Azure CDN 與透過 gulp-deploy-azure-cdn 套件實作 deploy task，若有錯誤或任何建議，請各位先進不吝提出，謝謝。

前言

在前面的章節，我們介紹如何在 gulpfile 內安裝與使用 robocopy，並透過檔案同步方式實作 Deploy 工作。透過 robocopy 方式雖然方便，但很有可能遇到網域與安全性問題而難以實作。而講到檔案傳輸方式，最常用也最讓人耳熟能詳的方式莫過於 FTP，只需要架設 FTP Server 與使用Ftp client 即可進行檔案傳輸。理所當然，我們也能透過 FTP 的方式實作 Deploy 工作。在這一章節，我們將使用 gulp-ftp 與 gulp-util 實作 Deploy。

前言

過去個人工作經驗，在多數專案中，測試、開發機(如:dev, qa, staging)通常會位於公司網域內，由 IT人員進行管理，但正式機(production)幾乎位於客戶的機房(若您的公司是自己開發產品可能例外)，由客戶方的IT人員進行管理。因為安全性的關係，客戶方的 IT管理人員很少開放資料夾存取權限讓您隨意使用。故多數情況下，我們需要透過 WebDeploy serices 協助進行佈署動作。接下來在本章節，我們將介紹如何使用 WebDeploy，若有錯誤或任何建議，請各位先進不吝提出，謝謝！
註:因.Net Core與.Net Framework皆可使用此方式佈署，故本篇文章為參考個人部落格案例撰寫

前言

在.NET Core 安裝與介紹這個章節，提到了因為.NET Core 的特性，可以透過本身指令進行 Restore, Build, Test 與 Publish 等工作，因此只需要對於Deploy與IIS管理上撰寫 Build Scripts 即可。Deploy 並沒有固定方法或必須遵守的規範，您可以透過檔案搬移、Rsync、FTP或WebDeploy...等不同方式完成 Deploy 工作，而您只需要依據環境選擇最合適的方法即可。接下來的幾篇，我們會介紹數種不同 Deploy 方法，若有錯誤或任何建議，請各位先進不吝提出，謝謝！
 

前言

在這篇文章之前，我們介紹了 TeamCity, Net Core 與 Gulp 的安裝流程與基礎應用。接下來的章節將開始介紹Deploy tools與撰寫Build Scripts。但介紹 Deploy tools 之前，我們將在這一章節對於一些小細節進行說明，包含：

1. TeamCity build agent 做了什麼？
2. TeamCity build agent 執行時間
3. 為什麼套件不要上版本控管？ 而要執行 restore？
4. 為什麼要佈署網站到IIS後更改實體路徑？
   這些內容看似簡單，但若有基本的認識，您在實作自動化流程會得心應手。若有錯誤或任何建議，請各位先進不吝提出，謝謝。

前言

上一篇我們簡單介紹如何安裝 Gulp 與其基本原理，並且提供了一個minify的範例。在一篇，我們將會介紹實作 NET Core 持續整合過程中前後端所需要的基本套件。透過這些套件的使用，可以幫助我們快速完成檔案搬移、參數傳遞與指令執行...等自動化工作。除此之外，npm 網站上有許多強者提供了許多 gulp 套件提供下載使用，您可以嘗試搜尋你想要到的工具，協助您更快速完成工作。若有說明錯誤或任何建議，請各位先進不吝提出，謝謝！

這章節我們介紹的套件，包含：

1. yarg： 提供從指令讀取參數功能
2. gulp-clean： 清除資料
3. gulp-sass： 將sass編譯為css
4. 執行 powershell 指令：若真的找不到套件，powershell 會幫您很大的忙

前言

從前面幾篇的介紹，我們有了持續整合伺服器(TeamCity)的協助，加上 NET Core 本身的指令，目前為止可以完成多數的工作。但在自動化過程中，我們仍需要透過一些工具進行其他的工作，像是資料搬移、檔案命名或邏輯處理，當然，我們可以透過命令提示字元 command-line、powershell 或程式語言(C#, F#)...等方式進行這些工作。而這系列文章中，我們會使用 Gulp 與 powershell 來進行這些工作。若有說明錯誤或任何建議，請各位先進不吝提出，謝謝！

前言

DevOps 流程內會設置許多環境，像是 Development ,QA ,Staging, and Production，依據需求的不同分別提供給開發者、測試人員與客戶使用。其優點如下：

1. Dev環境:因為佈署於伺服器而非工程師本機環境下進行操作與測試，減少了軟體套件未安裝、作業系統版本不同、系統參數不同...等佈署後發生問題的機率。
2. QA環境:測試人員進行測試的階段可能需要輸入假資料進行測試，避免影響到正式產品的資料正確性。
3. Staging:提供另一個備份的正式資料庫 搭配最新開發的程式進行操作。以最接近正式產品環境進行測試，找出可能發生的問題。
4. Production: 正式機 (當然，如果能不碰就不碰 XD)

前言

前一篇，我們介紹安裝 .NET Core 相關檔案，並分別透過 Visual Studio 2015 與 Command line方式建立第一個 Web Appliction 專案。在本篇，我們將詳細介紹與持續整合相關的指令操作，包含了 restore、build、test、publish,與 pack，並在最後說明如何在 TeamCity 使用這些指令建立 Build Script，進一步協助我們建立自動化整合流程。若有說明錯誤或任何建議，請各位先進不吝提出，謝謝。!

前言

ASP.NET Core早期被稱為 ASP.NET vNext 與 ASP.NET 5，但並非原有的 ASP.NET升級版，而是重新製作的 ASP.NET。最大的特色就是可跨平台運行於 Mac OSX 與 Linux 作業系統。當得知跨平台特性時，個人就非常期待未來的發展，很幸運的是 .Net Core 整合在2016年6月釋出後，Team Leader希望新專案可以進行透過 .NET Core 進行實作。期間雖然遭遇開發方式不同、過去常用套件不支援與佈署流程差異等問題，但透過這次專案累積了寶貴的經驗，也嘗試建立了自動化佈署流程。
本系列文章對於.NET Core 只簡單介紹相關的內容，包含：安裝、指令操作、TeamCity整合與多環境設定等部分，其他部分可以參考官方網站(像是 middleware 與 DI 部分也相當有趣，建議各位先進可以嘗試看看，至於開發經驗分享部分，只能等鐵人賽結束再說惹)。本篇文章若有錯誤或任何建議，請各位先進不吝提出，謝謝！ 

前言

前兩篇文章中，我們說明了安裝 TeamCity 與增加 Build Agent的設定步驟，而在這一篇我會簡單介紹 TeamCity 的操作介面與如何設定 build configuration(建置設定) 功能，讓大家能在 TeamCity 上進行基本操作。本篇文章若有錯誤或任何建議，請各位先進不吝提出，謝謝！

前言

TeamCity build agent 為負責執行整合流程的服務程序，負責執行各種持續整合工作，Agent越多，表示同時進行測試與部署工作越多，這在大型專案與多人共同開發情境下非常的重要。在 Professional 版本、不購買任何 agent lincesee 情況下，我們最多可以設定 3 agents 同時進行工作。在上一篇文章中，我們簡單介紹如何安裝 TeamCity，並且在安裝過程中設定了一個 TeamCity agent，而這在本篇會簡單介紹如何安裝與設定新的agent。若有錯誤或任何建議，請各位先進不吝提出，謝謝！

前言

TeamCity 是由 JetBrains 開發，一套 Java-Based 持續整合與管理的伺服器，能協助開發人員依據專案特性，從開發、編譯、整合、測試到發佈軟體等流程，建構一套專屬的 DevOps。TeamCity整合多家套件，如版本控管、測試框架、通知、視覺化圖表、問題追蹤、雲端支援...等，協助開發人員順行進行各種整合工作，功能相當強大。

前言

個人覺得運氣不錯，從早期單純的程式撰寫、版本控管、單元測試、專案管理工具到目前持續整合，透過工作學習越來越多的知識與技術，而這些知識技術也逐漸優化工作效能與成果，在此感謝一路走來曾經共事過的強者們，感謝你們不吝嗇地分享自身經驗與技術。透過目前工作，第一次實際接觸到的持續整合，也親身感受到程式自動化所帶來的好處。因應公司專案需求，個人有機會實作ASP.Net Web Application持續整合流程，雖然流程不算盡善盡美，但也補足長久以來對於理論的疑問，學習了不少經驗。這次透過鐵人賽，將對於ASP.Net core 部分製作持續整合的的相關經驗做一次彙整紀錄，有別於先前撰寫 ASP.Net Framework 持續整合文章，ASP.Net Core 在持續整合製作過程中有些許的不同，將會在後面的文章一一描述。  序篇將簡單說明目錄、操作環境、基本流程與持續整合的好處，若有錯誤或任何建議，請各位先進不吝提出，謝謝。

前言

個人實作 .Net Framework 、.Net Core 持續整合流程，並整合前端佈署至CDN整體流程後，深感製作自動化流程隨著技術創新，變得越來越簡便。尤其是 .Net Core 部分，Restore, Build, Test部分都可以以自身指令執行，不需要額外引入套件與撰寫指令，只需要實作 Deploy 部份，這讓我非常的驚訝(但這部分就不在此系列贅述，而會在.Net Core系列文進行說明)，也感嘆科技進步神速。

此外，這篇文章是這系列最後一篇，個人覺得後面幾篇文章表達方式比較不好，近期內會逐步修正部分內容，讓有興趣的人更容易理解，請多包涵。在此也感謝花費時間觀看此系列文章的所有人，若有觀念錯誤或建議請各位先進不吝指教。

前言

在gulp中執行powershell指令，變更IIS website實體路徑的實作過程，提供大家參考。若有觀念錯誤或者建議請各位先進不吝指教。

前言

在上一篇，我們透過 Gulp Robocopy 套件進行網站佈署，而本篇我們將使用微軟的Web Deploy 進行網站佈署。不同於 Robocopy ，網頁伺服器目標資料夾需要開放編輯權限(若開放所有使用者讀寫權限，可能有些安全性的疑慮)，Web Deploy 則是使用Windows Service (透過 port 8172) 協助進行佈署。理所當然，因為是第一次使用CI流程，過程中遇到許多IT問題，這此也一併記錄下來，提供各位與未來自己設置的時候參考使用，若有觀念錯誤或者建議請各位先進不吝指教。

前言

執行完 Restore, Build, 與 Test 後，接下來進行的工作是 Deploy。Deploy 實作的方法有許多種，並沒有哪一種方法是最正確的。在這系列文章中我們使用robocopy 與web deploy 兩個套件完成這項工作。無論使用哪一個套件，都有些限制與前置作業需要進行。Robocopy 使用上相當簡便，但 Team City Agent 必須"找得到"要佈署的伺服器，透過分享資料夾與設定權限的方式，將程式複製過去後完成佈署。如同第一篇我們所顧慮的，複製期間若沒有實行關機，進行操作的使用者可能會收到錯誤訊息，故我們將不直接將資料傳輸到目前運作版本的資料夾內，而是使用建立新版本資料夾後，更改實體路徑的方式，降低系統運作中發生錯誤的機會。

若有觀念錯誤或者建議請各位先進不吝指教。

前言

陸陸續續從 Net Framework Fake CI，轉到了 Gulp CI，繼續轉往 .Net Core + Gulp CI 的，最後仍需要整合 Front end CI 部分，一路走來有挺身的感觸。 做持續整合就像是造橋舖鐵軌蓋捷運，工人需要處理許多基礎建設與技術，才能讓乘客舒適又快速地到達目的地，提供遊客更好的服務品質(自動測試、自動佈署、前端避免cache處理與自動刪除舊版程式...等)，讓開發人員專注於程式開發。
當然，不免要碎碎念一下.... 
建構 CI 的過程中碰了不少壁，維護需要應付許多雜事，當 CI 掛掉的時候，所有人等著維修好的感覺真的很歡樂 ，所以請善待處理 CI 的工程師(笑)。

前言

本篇主要說明如何使用gulp-msbuild套件進行專案建置，除了在建置需注意是否安裝了
.NET Tools、 .NET Framework與相關套件，也需注意msbuild指令中的設定。個人過去
對於msbuild指令中的屬性設定較不熟悉，過程中查了資料才漸漸了解相關設定(如更
新web.config內容、產生publish資料...等)，若有觀念錯誤或者建議請各位先進不吝指教。