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的监控里看到什么时候发生了什么样的版本变动

这个信息有什么用呢?

比如你看到如下的图的时候会联想到什么?(某接口的响应时间)

是不是瞬间就能看出来,是因为某次发布导致某个接口的效率急剧变慢,不用猜,不用想,看图说话。

原文地址:https://www.cnblogs.com/leolaw/p/10092395.html

时间: 2024-10-06 12:13:50

TFS线上生成环境发布历程的相关文章

配置开发环境测试环境线上生产环境

1.正确打包 项目有三种环境: 1.本地开发环境(local) 2.开发测试环境(dev) 3.线上生产环境(product) 不同的环境有不同的配置,比如数据库连接什么的....maven打包时默认去resources文件夹下打包这些配置文件,放在WEB-INF/classes下,然后再打成war包,就能用了...现在通过修改pom.xml文件,增加三种配置,让maven打包时选择打包不同文件夹下的配置文件到WEB-INF/classes下,这样就省事儿了.... 如图所示,resources

线上的活动发布平台最优选-创成汇

在如今这个"大众创新,万众创业"的时代,各地政府.各大投资机构及各大众创空间为了更好的鼓励,孵化创新性企业,都纷纷开始办起各类创新创业大赛,大赛有了,下一步该寻找的就是要在哪里发布大赛,除去政府机构网站外还可以在一些线上的活动发布平台,活动发布平台一般都会有其自身的项目库.宣传渠道.及专业的项目征集人员.例如创成汇. 创成汇是国内专业的创新创业成果转化平台,采用大数据.智慧智能等新兴技术理念和互联互享等先进产业模式,有效整合优质创投资源.在承办大赛方面也是有丰富经验的,就近而言,除了前

线上版本灰度发布策略

从接触运维开始,最苦逼的事情就是业务上线,为什么这么说? 就是因为有了很多的大坑队友.不是因为开发的童鞋漏提代码,就是因为测试童鞋线下测试的不到位导致代码扔到线上后出现各种问题,各种404.近期和各位童鞋研究了应对这种现象的解决方案,得到了如下结果: 上线分为如下几种等级:测试发布.预发布.灰度发布.正式发布,下面分来来针对这四种发布介绍下区别. 测试发布:写完程序在线下测试,测试的过程和结果成为测试发布. 预发布:程序经历过测试发布后要把代码在线上部署一套(和生产环境一模一样的环境),使用生产

线上测试环境搭建过程记录

第一步:安装JDK,以jdk1.8为例子: 1.将jdk1.8的rpm软件包拷贝到 /usr/local 下 2.执行 rpm -ivh jdk-8u191-linux-i586.rpm 3.安装完以后  会在 /usr/java/latest 下有对应的 jdk 版本 4.添加环境变量: vi .bashrcexport JAVA_HOME=/usr/java/latestexport PATH=$PATH:$JAVA_HOME/binsource .bashrc 5.查看版本 java -v

如何利用docker 构建golang线上部署环境

公司最近开发了一个项目是用golang 写的,现在要部署到线上环境去,又不想在服务器上装单独的golang,决定用docker 封装下,直接打到镜像里面,然后就直接在hub.docker.com上面搜了下golang的镜像,直接就docker pull golang 最新的是1.9的版本 然后参考官方的文档弄了下Dockerfile大概是这样: FROM golang MAINTAINER jackluo #指定工作目录 WORKDIR /go/src/ActivitApi COPY . . C

线上生产环境部署Djngao+Nginx+Uwsgi

是否曾想过把django项目从windows移植到Linux上运行,Linux性能众所周知,作为Django运行的服务器再合适不过啦,今天分享一下如何在线上云机器的Linux环境运行Django项目. 客户端访问服务端的流程 1.首先客户端请求服务资源, 2.nginx作为直接对外的服务接口,接收到客户端发送过来的http请求,会解包分析. 3.如果是静态文件请求就根据nginx配置的静态文件目录,返回请求的资源,否则会根据django配置文件设置的static目录去找资源. 4.如果是动态的请

vue cli3配置开发环境、测试环境、生产(线上)环境

cli3创建vue项目是精简版的少了build和config这2个文件,所以配置开发环境.测试环境.生产环境的话需要自己创建env文件. 需要注意2点: 1.cli2创建项目生成的config文件里的env文件是js后缀 2.cli3创建自定义env文件的话不需要js后缀 下面开始创建配置: 一.直接在你项目的根目录创建三个文件(注意都没有后缀,直接创建新文件):.env.development (开发环境) .env.test(测试环境).env.production(生产环境) .env.d

rsync实现负载均衡集群文件同步,搭建线上测试部署环境

闲来无事,搭建一个负载均衡集群,至于负载均衡集群搭建过程,找时间写下.这次主要写集群之间的文件同步,以及线上测试环境的搭建. 笔者看过很多公司都没有线上测试环境,真是崩溃了,不造怎么确保线上线下环境一致的. 笔者此次使用三台服务器: 192.168.138.3   web服务器 192.168.138.4   web服务器 192.168.138.10  web服务器+线上测试环境+源站 其中3 4 服务器作为集群中的web服务器,对外开放,是负载均衡集群的部分. 其中10 服务器不对外开放,代

Node.js项目线上服务器部署与发布

第1章 课程预热   1-1 为什么是全栈最后一公里   1-2 搭建线上生产环境需要做什么第2章 待部署的 5 个本地 Nodejs 项目   2-1 快速本地搭建一个纯静态简易站点   2-2 Nodejs 电影网站项目上线准备   2-3 狗狗说 React Native 开发的 App 后台项目分析   2-4 微信小程序的项目介绍   2-5 电影微信公众号的项目概况   2-6 从一个故事理解整个部署思路第3章 选购域名服务器及备案   3-1 选购域名的经验分享   3-2 主机厂