继前文
自从之前将开发环境使用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的监控里看到什么时候发生了什么样的版本变动
这个信息有什么用呢？
比如你看到如下的图的时候会联想到什么？（某接口的响应时间）
是不是瞬间就能看出来，是因为某次发布导致某个接口的效率急剧变慢，不用猜，不用想，看图说话。