前言
個人覺得運氣不錯，從早期單純的程式撰寫、版本控管、單元測試、專案管理工具到目前持續整合，透過工作學習越來越多的知識與技術，而這些知識技術也逐漸優化工作效能與成果，在此感謝一路走來曾經共事過的強者們，感謝你們不吝嗇地分享自身經驗與技術。透過目前工作，第一次實際接觸到的持續整合，也親身感受到程式自動化所帶來的好處。因應公司專案需求，個人有機會實作ASP.Net Web Application持續整合流程，雖然流程不算盡善盡美，但也補足長久以來對於理論的疑問，學習了不少經驗。這次透過鐵人賽，將對於ASP.Net core 部分製作持續整合的的相關經驗做一次彙整紀錄，有別於先前撰寫 ASP.Net Framework 持續整合文章，ASP.Net Core 在持續整合製作過程中有些許的不同，將會在後面的文章一一描述。 序篇將簡單說明目錄、操作環境、基本流程與持續整合的好處，若有錯誤或任何建議，請各位先進不吝提出，謝謝。
目錄
此系列文章目錄為暫定目錄，會依據撰寫情況做修改。
- 序
- TeamCity 安裝與介紹
- 如何在 TeamCity 增加 Agent
- TeamCity Build Configuration 介紹
- Net Core 安裝與介紹
- Net Core 基本指令使用與整合 TeamCity
- Net Core 多環境佈署設定
- Gulp 基本介紹
- Gulp 套件介紹
- TeamCity Agent 執行流程說明
- Deploy : Robocopy
- Deploy : WebDeploy
- Deploy : Ftp Deploy
- Deploy : Deploy to Azure CDN
- Deploy : CDN Solution 1 - Hash and Replace
- Deploy : CDN Solution 2 - 資料夾命名規則
- IIS remote management : 變更站台實體路徑與移除舊有資料
- 伺服器篇 - CI 環境設置作業
- TeamCity build scripts撰寫 (含範例專案架構)
- JMeter 基本介紹
- JMeter BeanShell
- JMeter 與 TeamCity 整合
- Microsoft Bot Framework
- Skype Bot C# 基本教學
- Skype Bot 與 TeamCity 整合 1 - TeamCity Restful API 介接
- Skype Bot 與 TeamCity 整合 2 - TeamCity Notification
- Docker 安裝與介紹
- Docker : aspnetcore image , Dockerfile 與 Docker hub
- Docker 與 TeamCity 整合
- 心得與感想
操作環境
實作自動化流程並沒有固定的套件或方法，本系列文章將使用下列工具：
- ASP.Net Core
- Nodejs
- Gulp 與相關套件
- Windows server 2016
- TeamCity
- JMeter
- Docker
- Microsoft Bot Framework
- Microsoft Azure CDN
基本流程介紹
佈署流程
在進行佈署自動化工程前，了解其流程是非常重要的事情。上圖為 ASP.NET web application 佈署流程圖，在一般開發佈署過程中，我們會面對這些步驟：
- Restore: 下載與彙整專案所需要的套件。
- Build: 將專案進行編譯，產生編譯後的檔案。
- Publish: 將專案進行發佈，產生可佈署於IIS上的站台資料夾。
- Test: 對專案進行單元測試與整合測試。
- Deploy: 將Publish Folder 移動至 Web Server，並設定至 IIS 上。
透過這張流程圖，我們能明確了解需要實作哪些工作。理所當然，程式語言、專案結構與開發團隊需求的的不同，自動化流程也不盡相同，如：前端可能需要編譯 sass 為 css 與 css 的最小化工作，在流程中就需要添加額外工作。本系列文章的主軸在於佈署 ASP.NET Core Web Application，進而延伸壓力測試、skype bot 與 docker 整合等內容。
TeamCity 流程
上圖為一個簡易的系統架構圖，包含 Git Server、TeamCity Server、TeamCity Agents 與 Web Server...等伺服器。使用者於 TeamCity Server 進行操作。當使用者觸發佈署工作後，TeamCity Agent 從 Git Server 取得指定 Branch 程式碼後，開始進行相關處理程序，最終將網站佈署於網頁伺服器。
在建置CI過程前，您需要了解專案中每一台伺服器的作用，分別進行套件安裝、防火牆設定、伺服器組態設定(如:Domain, port, low balance...)與服務啟用等工作。了解這些伺服器的關聯與需求，您才能與IT團隊進行溝通，取得所需要的資源建置自動化流程，而我們在後面的章節會提到，當您取得一台新的伺服器時，需要注意哪些事項。
除此之外，您需要清楚了解您的專案架構：可能包含前端與後端，您需要了解不同程式語言該如何進行編譯、測試與佈署，才能開始撰寫專屬的 Build Script；隨著產品越來越大，越來越多的環境(如 CDN Server)與複雜的自動化需求(如壓力測試)，您的 Build Script 會越來越多而且有趣。
持續整合的好處
減少人工操作步驟，節省時間
無論在 Java 或 .Net Web Application 開發或維護期間，經常需要佈署新的程式碼到網頁伺服器上。從版本控管伺服器抓下程式碼、編譯、檢查與佈署等步驟雖然都不困難，但操作過程中必須專心在每一個步驟，些微的不注意就可能發生錯誤並重新佈署。
過去同事常常開玩笑著說，我們的系統協助客戶節省了不少人力成本，應該將這些節省下來的時間成本換算成維護費用，按此比例算錢給我們，才能顯示出系統的價值。程式佈署自動化也相同，一個專案數百次甚至數千次編譯與佈署，累積節省的時間相當可觀，但最重要的是能讓工程師將心力專注於開發。
降低人為操作可能造成錯誤
過去曾經有幾個專案，因為客戶要求短時間內將維護的功能持續做更新，當時的專案經理與資深工程師認為發佈與佈署非常的簡單，一天做幾10次都沒有問題，忽略控管的問題。不嚴謹的代價就是系統常常佈署完後立刻壞掉，讓客戶對產品很沒有信心。在如此頻繁更新程式碼與版本的情況下，更需要自動化流程協助，確保每次更新皆能成功佈署，減少停機的時間。
降低程式錯誤
若在自動化程序加入觸發程序，每個 push 或 merge 的分支皆進行編譯與測試，則可以有效提升程式品質，降低因人為疏忽造成的語法錯誤、套件錯誤或邏輯錯誤等情形發生。這並非規範，但這一種自動化檢查程序與紀錄可以讓開發人員明確的了解問題在何處，有效提升程式產出的品質。
下一篇：TeamCity 安裝與設置
註：本系列文章將於2016 IT邦幫忙鐵人賽進行同時，一併發佈於個人blogger與dotblog。
