TFS线上生成环境发布历程

继前文

TFS在项目中Devops落地进程（上）

TFS在项目中DevOps落地进程（下）

自从以前将开发环境使用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的监控里看到何时发生了什么样的版本变更

这个信息有什么用呢？

好比你看到以下的图的时候会联想到什么？（某接口的响应时间）

 

是否是瞬间就能看出来，是由于某次发布致使某个接口的效率急剧变慢，不用猜，不用想，看图说话。