TFS线上生成环境发布历程

Posted 2021-01-25 leolaw

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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]