繼前文
自從之前將開發環境使用TFS進行了自動化之后，就享受在此成果中，其他后續進度就停頓了好一段時間。
畢竟在我們這對於開發而言，做出代碼交出發布包事情就結束了，而我們的TFS已經完美的將這個流程給自動化掉了。
本文將聚焦在TFS發布到線上生產環境中所做的一些工作和實踐，如果只是糾結於如何使用TFS可以參考上面的2個鏈接。
之前的線上發布流程
說下我們大概的背景，我們的程序上線流程目前還是相對傳統一些，大體是：
①開發寫完代碼->②提交發布包->③QA拿包測試->④測試完成提交上線->⑤運維拿包進行發布
根據這個流程，狹義上的開發其實到流程②就已經結束了，因為之后從嚴格意義上來說都跟開發沒有關系了（撇開出bug返工fix的逆向流程來說的話）
但是每次發布的時候，開發又必須要留守下來，雖然並不干什么事情，就干等着，但就要你留下，不然萬一出現了問題怎么辦。
之前發布都是手工發布，發布的時候每個機器都要人肉將發布包拷貝過去，覆蓋，重啟下應用程序池。
人工做這些重復而又無聊的事情會發生什么問題就不多說了：容易出錯，枯燥，難以標准化。
而且人肉發布的時候經常直接將站點發布，所以有些站點正在處理某個請求中的時候就強行被kill了導致”每逢發布必報錯“。
沒錯，你想知道什么時候發布，你只要看異常量冒上來的那一下就是發布的時間點了。。。
后面運維團隊搞了jenkins來做自動化發布。
首先jenkins本身是個優秀的東西，但無賴總感覺我們是沒hold住它，首先並沒有解決”每逢發布必報錯“的問題，另外發布時間看起來沒有明顯減少，最后覺得獨立jenkins感覺就是Dev和Ops之間的那個壁壘（信息分割）。
TFS線上發布流程的准備
后面就計划用tfs來進行自動化的線上發布
首先，我們在原來的Release里，新增了若干個環境映射為線上環境
其中我們有一些是分業務線的（一條業務線內，所有前->中->后台的站點均維持同一個版本避免某些用戶終端發布的時機不匹配的問題）就通過Release的Envrionment來進行區分
個別Environment里是有2個相連的情況，是因為某些業務線比較大，機器比較多，將比如10台機器，分成5個一組合計2組，發完第一組之后再發第二組這樣的分組發布
然后我們線上機器使用了Nginx來做軟負載，所以要進行線上發布的話一個正統的流程應該是
①通知Nginx讓這個機器下線，並且可能要等待一段時間（等請求處理完畢）
②更新站點
③通知Nginx讓這個機器上線
其中①和③由運維那邊准備好了專門的python腳本放在每個機器的指定目錄里，只要再發布的時候，遠程到被部署的機器里執行下就好了
這里面遇到了2個問題：
問題1：
“遠程到被部署的機器”這個問題，首先TFS自身的步驟里沒這個玩意，所以自己特地研究了下Powershell研究如何動態的在指定的機器里進行Invoke-Command （不枉當年略微了解過Powershell）
TFS里可以支持調用Powershell
最后搞出通過如下命令即可實現遠程到指定機器里調用指定的命令
[sourcecode language='powershell' padlinenumbers='true']
$username 可以訪問機器的賬戶名
$password可以訪問機器的密碼
$machine = 你的機器地址
$secstr = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $secstr
Invoke-Command $machine -Credential $cred -ScriptBlock { 你需要在目標機器執行的命令 }
[/sourcecode]
問題2：
每個要發布的機器都要執行這3個步驟，想下一個機器3個Task，10台機器就30個Task，30台機器就90個Task，這還有要針對Task的一些變量配置，這茫茫大的配置量。。。
於是乎我們使用了TFS的任務組功能，所謂任務組，就是可以將若干個Task合並為一個Task，然后在通過變量傳參的形式各個Task共享指定的變量
如：
通過任務組將3個Task合並為一個，里面包含”下線->更新->上線”全流程，一個任務組就對應發布指定的一台機器
然后吭哧吭哧的我們將這些問題解決了，就基本上配置出了基礎的線上發布方案，然后就開始…..翻車
發布中遇到的一些問題
發布緩慢
先說下我們實際發線上的一個流程
我們以前（TFS以前）是QA將程序包一直測試到預發布（預生產環境）后，然后運維將預發布的包同步到線上
用TFS自然而然也順着這個流程來，發布預發布的時候將包copy到某個共享目錄下，然后線上的發布都通過去這個共享目錄里拿
但是默認tfs的每一個Release它都會將發布包下載到發布的代理agent里，這個過程比較緩慢，拖慢整體速度
於是乎我們就發布的時候跳過項目下載，實踐證明這個操作能大幅提升發布的效率
發布的時候站點的文件被占用導致發布失敗
這個特別是在Asp.Net Core里幾乎一定會發生，.Net Framework看具體情況但也很可能會遇到
一般而言的解決方案可以通過勾選IIS發布的時候Task App Offline解決（我們通過這個解決了99%的問題）
但實際上我們遇到了更變態的情況（剩下的1%），有一個站點使用了別人家的COM組件導致用這招依然會有文件占用的問題，這個可以通過發布的時候通過停止應用程序池搞定
折騰后的效果
通過上述修改，我們基本線上的發布透過TFS能跑的相對穩一點了
目前發布的效果是：發布期間站點性能有所下降，但是報錯量總體不會發生太大變化
起碼脫離了每逢發布必報錯的時候了
由於最近一直在測試線上TFS發布（折騰了蠻久了）之前發布的數據沒有了，不過看最近的一次發布結果，基本沒發生報錯
有箭頭的位置就是發布的時候（這個稍后會說是如何實現的）
紅色的是異常的數量
可以看到最近的發布里，基本沒有紅色的了
附加值：與Dev的相關整合
由於現在發布使用上了TFS，而我們Dev也是在TFS上的，所以現在我們大家都在同一個工具平台下了。
起碼能帶來一個顯而易見的效果是，有沒有發布，和發布完了沒，我們大家直接透過TFS的面板就能看到了而不用跑過去問運維了。
另外說2個由於發布走TFS后跟我們Dev整合的一些附加值
①自動拉備份分支
以前我們已經就有這個機制，不過因為以前發布不是走TFS，所以我們是在發布到預發布的時候（預發布歸QA管，之前做自動發布流程時候就將預發布以前全部搞好了）就自動拉
但是預發布畢竟不是線上，到了預發布也可能fix bug，所以很多時候備份分支特別多特別亂
而現在就是真正發布到線上的時候才會去拉備份分支，備份分支的備份就顯得更加的“真”了
②發布的時候給監控系統打標記
上面異常量的那個圖里看到的那幾個小箭頭
是每次自動發布到線上的時候，TFS會跟Application Insights（我們用的監控產品）說，我現在對某站點進行代號為XXX（TFS內的發布編號）發布拉，給我打個標記）
Application Insights就會說，好的，收到了，箭頭已經打上，關聯上你給我的信息了
一切通過插件 Release Annotations for Azure Application Insights 來實現即可
然后我就能通過我們的Application Insights的監控里看到什么時候發生了什么樣的版本變動
這個信息有什么用呢？
比如你看到如下的圖的時候會聯想到什么？（某接口的響應時間）
是不是瞬間就能看出來，是因為某次發布導致某個接口的效率急劇變慢，不用猜，不用想，看圖說話。