前言

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

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

前言

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

前言

本篇文章將簡單介紹如何透過 Dockerfile，以microsoft/aspnetcore base image 建置自己的 Net Core Web Application image。除此之外，也簡單介紹將自己建置好的 imag e放上 Docker hub進行管理，若有觀念錯誤或任何建議，真誠的希望各位先進指點。

前言

終於進入最後一個主題：Docker。
Docker 是近幾年相當熱門的技術，但我卻到近一個月才開始學習與了解這項技術，本身觀念與實作方面尚未成熟，若有觀念錯誤或任何建議，真誠的希望各位先進指點。這套作業系統虛擬化軟體專案大大改變個人對於傳統伺服器、虛擬機器持續整合與自動化流程的想法。原先 Docker 並未規劃本系列文章之類，而想藉由這次鐵人賽邊學習邊撰寫，開賽前規劃約 5 篇講述這個主題，而至上星期為止，因為多補充了幾篇文章而減少至三篇。這三篇將會以安裝、指令操作、.NET Core 與 TeamCity為主。本系列實作與測時的環境為：

1. Windows 10
2. Docker V1.13.0-rc4-beta34(9562)

前言

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

前言

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

前言

上一篇我們介紹如何建構自己的 Bot 程式，並且上傳至 Azure Web App，因應後續我們需要直接與 TeamCity API進行介接，在這一篇我們將簡單介紹如何取得 Skype 訊息與回覆訊息，若有錯誤或任何建議，請各位先進不吝提出，謝謝。

前言

在後續的三篇文章，我們將嘗試使用 Microsoft Bot Framework 與 TeamCity 進行互動。一般正常持續整合流程其實比較少見透過機器人程式幫助我們進行工作，但若是機器人的程式部分做的不錯，將更簡化我們的操作流程，像列出進行某項持續整合工作、顯示說明、回傳建置結果與列出log...等工作，甚至你完全不需要了解持續整合如何運作，您只需要與之溝通即可完成你想要的工作，相當方便。本篇文章將簡單介紹如何透過 Microsoft Bot Framework，建置您專屬的管家，若有錯誤或任何建議，請各位先進不吝提出，謝謝。

**註:Microsoft Bot Framework 目前於 preview 版本，網站與操作方式可能因為改版而與本篇文章有所差異。

前言

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

前言

當您需要進行提供或介接 WebAPI 的工作，在撰寫程式前我們會透過 Postman 進行測試，進一步了解服務是否正常與確認回傳的內容；或透過 swagger 讓工程師了解介接過程中使用的參數與回傳結果，方便進行介接與測試工作。雖然這些工作都可以自行撰寫程式進行測試，但過程相當耗費時費力，這些套件透過腳本可以進行複雜的介接功能，節省我們另行撰寫程式的時間。壓力測試也不例外，也能透過腳本撰寫的方式，進行複雜的測試。這一篇，我們將介紹如何在JMeter 中使用 BeanShell scripts 進行前處理與後處理，若有錯誤或建議，請各位先進不吝提出，謝謝。

前言

透過前面19篇文章介紹，我們已經了解如何透過 Gulp + TeamCity 實作.Net Core web application持續整合。而在後續的幾篇，我們將增加持續整合的應用(如：壓力測試、機器人控制)與持續交付(docker)部分，這些應用將有效提升自動化流程的效率。如有錯誤或建議，請各位先進不吝提出，謝謝。

前言

前面連續介紹 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 在持續整合製作過程中有些許的不同，將會在後面的文章一一描述。  序篇將簡單說明目錄、操作環境、基本流程與持續整合的好處，若有錯誤或任何建議，請各位先進不吝提出，謝謝。