TFS在項目中Devops落地進程（上）

做爲一名開發,通過近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的支持等，敬請期待..