作為一名開發,經過近2年折騰,基於TFS的Devops主線工程大體落地完畢。
在此大體回憶下中間的各種歷程。

開始之前簡單說下什麼是TFS(Team Foundation Server)。

TFS是微軟推出的一款ALM（Application Lifecycle Management)管理工具。

透過TFS你將能獲取到從程式碼版本管理->專案管理->持續整合->自動釋出->自動測試等一系列軟體生命週期在內的全家桶功能，它也有一個雲端版稱之為VSTS。

VSTS/TFS=Github+Trello/TeamBition/Tower/Jira/Rally/RTC+QC/TestLink+Jenkins。

TFS不僅是個存程式碼的，

TFS不僅是個存程式碼的，

TFS不僅是個存程式碼的，

重要的事情說三次。只用TFS來存放程式碼的就相當於6000塊買個iPhone當著200塊的諾基亞功能機在用，暴殄天物。

本文將會說：TFS在我們組裡對提升我們組Devop所起到的作用和各種歷程。

本文將不會說：如何對TFS進行具體配置。

希望該文章可以幫助到在用TFS或者希望用TFS的團隊或者個人。

第0章--歷史

剛到公司的時候,那一年是2015年,作為一名開發小白的我剛加入戰局。

此時公司是基於TFS2010使用TFVC來進行程式碼管理,基於Jira進行專案管理,無自動打包/釋出,無自動測試。

首先作為一個有志青年,在這個以SVN為代表的集中式程式碼管理已經日趨沒落而git蒸蒸日上的年代,對和SVN一脈相承的TFVC自然是不屑一顧。

而且還用著5年前的TFS2010…那個介面：

一看就不想用.已經完全不符合時代潮流的UI.

而同時期的TFS2015：

明顯就更現代化,更加的User Experience。

然後遂用著VSTS（那會兒還叫Visual Studio Online)裡的git進行程式碼管理,當然這對我司是不合規矩的,不過一方面自己手頭負責的是新專案(新建專案開始的那種),另一方面也只是個臨時方案。

當然與此同時也向老大申請,看看能否搞個TFS2015來…畢竟要緊跟時代潮流。

第1章--推廣git

後面在老大的協助下,終於弄來了我們自己的TFS2015,然後當然第一步先將原VSTS裡的程式碼遷過去,然後自己就基於上面happy地coding。

然後後續其他專案也逐漸遷移到新的TFS伺服器上。

因為新的專案集合都基於git來做程式碼版本管控,這中間有幾個問題：

①如何說服已經習慣了TFVC工作流程的其他同事使用上git；

②在git上如何做程式碼管控。

要說這個問題前先說說為什麼我自己喜歡用git：

首先我覺得在技術選型上一定要避免因為這個是最流行/最新所以我就要用它的這種形而上學主義,我們要用一個產品,一定要明白它是什麼,以及它是為了解決什麼問題而誕生的,只有這樣才能選到合適的產品(注意:是合適,而不是”最好”)。

我個人是個BYOD主義者（自帶裝置上班）,一方面是客觀上公司電腦戰鬥渣（起碼現在升級後還是機械盤,俺主力的微軟親兒子4好歹是個全固態)，另一方面被BYOD思想給洗腦了,在另一方面還能方便隨時隨地加個班…

git的離線提交對我而言是個相當強有力的功能存在。

另外和集中式管控的每次提交都要做策略不同,我個人更傾向於每次提交無需任何策略檢查,而是在pull request階段在做策略的”打包式程式碼管控”。

在另外的就是git的分支,讓分支這個功能從此變得唾手可得..

基於上述理由所以我選擇了git。

然後就是對原有同事的”普法”了，其中一個比較頭疼的問題是git的commit和push這2個概念經常說不清,雖然現在的我也不見得就能說清,畢竟TFVC的時候點下提交就真的上伺服器了,而現在你”提交”了不算數,還要在同步(sync)或者推送(push)一下才可以。

在另外就是啟用了pull request來管理需要開發/釋出的程式碼,同時也是初步引入了”程式碼審查“的概念：每次pull request都需要非本人之外至少一人同意：

然後因為git的分支使用起來特別方便,之後協同開發也變得更加方便,因為各自都在各自的分支裡進行獨立開發。

而且自此我們每次釋出後都會按照當時釋出日期拉一個分支出來作為備份分支,用於做各種臨時更新所需要的處理：

階段總結,由於引入了git給我們帶來了:

①更方便大家協同合作開發,現在每個人都有自己的開發分支來開發自己負責的功能；

②更方便拉取備份分支,從此我們組在處理臨更這件事上更加遊刃有餘；

③引入了Pull Request和最原始的程式碼稽核。

第2章--引入最初的自動釋出

從第0章的歷史裡已經寫到,原來我們是沒有任何自動釋出的工具或者套路的，我們的一個常規釋出流程是:先開發好,然後用vs的”右鍵->publish”生成一個釋出包(資料夾)，然後提交到svn，在告知qa的同事拿包更新到測試環境。

首先這個流程繁瑣而又浪費時間，其次還經常出錯，而且時而還發生比如某人的程式碼沒合併進去之類的惡性問題，無論是我們開發組還是qa組都對這個苦不堪言，於是自動釋出被提上優先處理的日程。

最初版本的自動釋出的想法只是簡單的將vs裡的”右鍵->publish”自動化。

首先我們知道vs的publish是可以支援釋出到遠端伺服器的：

我只要在target location填入目標伺服器的共享資料夾地址且我伺服器有許可權訪問目標伺服器的話，那麼就可以直接釋出上去：

對應的在tfs裡的Build Solution步驟裡的MS Build引數裡只要填上釋出的對應配置檔案，就能將上述過程變得自動化。

但這套方案有如下幾個問題：

①被髮布的機器一定要有共享資料夾配置；

②Build Agent到被髮布的機器一定要有訪問對應共享資料夾的許可權（要事先弄好）；

③每次釋出其實都是從程式碼庫裡將程式碼拖出來再重新編譯的，如果比對版本的話各個環境的dll版本都是不匹配的..(最起碼檔案建立時間鐵定不一樣)。

這就導致配置這套要被髮布的機器和BuildAgent同時都要做不同程度的配置，而且這個明顯對後期無論BuildAgent的增加或者是被髮布的伺服器增加都不是個好事，但畢竟第一步，有好過沒有，先上了再說。

另外一點是我們正規做法是提交程式碼時候都是不能帶dll的,所以現在本地引用dll的形式在自動釋出的時候都很容易會出現問題(別跟我說將dll提交到版本管控裡)。

也因此我們首次將nuget作為一個必須項引入進來,在此之前nuget雖然也有但是都是屬於想用就用,不想用就本地dll這樣的方式。

由於自動釋出的需要，我們不再允許本地引用dll而要求所有外部依賴必須通過nuget伺服器來進行管理。

同時，QA組同時也對這個流程上提出意見，他們要求上測試環境必須要他們同意才可以而不是開發說想什麼時候上就什麼時候上（不然我就配置個Trigger搞持續集成了）。

於是我們新引入了QA分支的概念。

QA分支只有QA組的同事有pull request的稽核許可權，如下圖這樣的配置：

QA分支只要同意後就會自動觸發Demo環境（第一個測試環境）的自動釋出（通過Trigger實現），後續testing環境和預釋出環境也只會基於QA分支的程式碼來進行。

然後試用一段時間下來，有自動釋出的專案在釋出上的問題明顯減少了很多，而且QA同事花在更新包到測試環境上所需時間也明顯降低。

階段總結：

①引入了自動釋出；

②引入了QA分支，明確了釋出上的流程；

③將nuget作為引用外部dll的唯一選擇，統一外部依賴的管理。

第3章 自動釋出的優化

此時微軟釋出了TFS2015Update2，相關更新內容可以參考 TFS2015Update2更新日誌。

其中最重要的一點是：

引入了Release Management的功能，以前這是作為一個獨立產品的現在作為一個子功能整合到了TFS裡，然後又在我們老大協助上讓運維那邊升級了TFS到Update2之後，就著手怎麼讓我們也用上“Release”的功能。

另外一點是這個版本開始TFS也有了自己的Store，從此走上了可以裝各種擴充套件的日子了

首先我理解的Release和原先已有的Build應該是這樣子的:

先通過Build將程式碼變成dll,然後找個地方存起來,之後就通過Release釋出到各個環境，由於Release只是充當一個“複製dll+配置“的功能,而dll都是最初那個Build生成的，所以各環境下的dll應該都是一樣的。

然後經過調整後（刪掉有的沒的只留下必要的）一個典型的Build的步驟是這個樣子的：

然後Release的步驟大概是這樣：

這裡不會詳情闡述上述截圖的意思，具體的配置可以參考微軟官方文件Build for Asp.Net 和 Deploy to Windows VM

到現在我們的自動釋出就變成類似這樣：

注意中間的格子，灰色代表對應環境沒執行釋出動作，而綠色則是釋出過且釋出成功，對應還有黃色（釋出了但部分成功）和紅色（釋出失敗）。

然後我們專案釋出過程到達了哪個階段現在也能一目瞭然而不是總是跑過去問QA：”現在釋出到哪裡了，testing上了嗎？”。

在這套自動釋出上了之後沒多久,我驚訝發現在Release裡的”IIS Web App Deployment”的Task有這麼一個東西：

雖然我英語不好，不過字裡行間隱約猜到它應該是可以在部署期間替換某些引數（猜測跟Vs釋出時候的那個Transform那樣）。

以前我們釋出的時候都要求排除掉web.config的，因為像是資料庫連結字串，在各個環境下都不一樣，然後就各個環境web.config實現準備好，釋出時候不釋出web.config這樣的方式來解決。

這有個問題是我們經常更新nuget包的時候其實它是會動web.config的，然後這種變動每次在SVN包裡寫個txt告訴QA怎麼改（你能想象QA們在一堆xml裡找到你需要的節點然後做對應修改的痛苦麼？）。

類似這樣子：

後面運維那邊提出將“環境相關”的web.config抽取出獨立的config檔案來作為不更新的部分，web.config整體就作為釋出的一部分每次都更新，大體拆分的Web.Config的拆分可以參考 使用 ConfigSource 特性 拆分 Web.config 檔案

但我總歸覺得這種事情應該要能更“自動化”的解決，而且一個檔案如果長久不釋出後面萬一真要變的時候誰會想的起還有這碼事？然後就去研究那個”Web Deploy Parameter File“。

發覺只要指定一個xml檔案然後在IIS部署階段Web Deploy就會用對應配置檔案替換掉你站點裡的所有指定配置檔案（沒錯，是所有，不侷限於web.config）。

它的檔案定義大概是這樣子的：

後面投入使用後也反饋良好，自此之後我們開發將web.config也作為釋出檔案釋出上去，然後每次釋出的時候會透著這個檔案在部署階段自動轉換注入資料庫連結字串或者某些appsetting。

自此做了這套方案的專案，基本上沒有通過一個txt的形式告訴QA怎麼改配置檔案了。

階段總結：

①升級了TFS獲得了Release Management功能以及支援商店功能；

②將自動釋出拆分了Build和Release兩個步驟，更規範的自動釋出流程；

③通過Release我們開發能清楚知道現在測試到什麼階段；

④web.config為代表的釋出配置自動化。

大總結

經歷過上述折騰，現在我們基本從封建時代階段步入工業革命時代，引入了git（特別是它的分支功能），引入了自動化釋出。

整體讓我們組進入初步現代化的階段。

之後將會講講我們組基於TFS如何來做程式碼分析，整合監控，NetCore的支援等，敬請期待..

原文地址：http://www.cnblogs.com/leolaw/p/7821335.html

.NET社群新聞，深度好文，歡迎訪問公眾號文章彙總 http://www.csharpkit.com