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

做为一名开发,通过近2年折腾,基于TFS的Devops主线工程大致落地完毕。
在此大致回忆下中间的各类历程。

 

开始以前简单说下什么是TFS(Team Foundation Server)。

TFS是微软推出的一款ALM（Application Lifecycle Management)管理工具。

透过TFS你将能获取到从代码版本管理->项目管理->持续集成->自动发布->自动测试等一系列软件生命周期在内的全家桶功能，它也有一个云端版称之为VSTS。

VSTS/TFS=Github+Trello/TeamBition/Tower/Jira/Rally/RTC+QC/TestLink+Jenkins。

TFS不只是个存代码的，

TFS不只是个存代码的，

TFS不只是个存代码的，

重要的事情说三次。只用TFS来存放代码的就至关于6000块买个iPhone当着200块的诺基亚功能机在用，暴殄天物。

本文将会说：TFS在咱们组里对提高咱们组Devop所起到的做用和各类历程。

本文将不会说：如何对TFS进行具体配置。

但愿该文章能够帮助到在用TFS或者但愿用TFS的团队或者我的。

 

第0章--历史

刚到公司的时候,那一年是2015年,做为一名开发小白的我刚加入战局。

此时公司是基于TFS2010使用TFVC来进行代码管理,基于Jira进行项目管理,无自动打包/发布,无自动测试。

首先做为一个有志青年,在这个以SVN为表明的集中式代码管理已经日趋没落而git蒸蒸日上的年代,对和SVN一脉相承的TFVC天然是不屑一顾。

并且还用着5年前的TFS2010…那个界面：

一看就不想用.已经彻底不符合时代潮流的UI.

而同时期的TFS2015：

明显就更现代化,更加的User Experience。

而后遂用着VSTS（那会儿还叫Visual Studio Online)里的git进行代码管理,固然这对我司是不合规矩的,不过一方面本身手头负责的是新项目(新建项目开始的那种),另外一方面也只是个临时方案。

固然与此同时也向老大申请,看看可否搞个TFS2015来…毕竟要紧跟时代潮流。

 

第1章--推广git

后面在老大的协助下,终于弄来了咱们本身的TFS2015,而后固然第一步先将原VSTS里的代码迁过去,而后本身就基于上面happy地coding。

而后后续其余项目也逐渐迁移到新的TFS服务器上。

由于新的项目集合都基于git来作代码版本管控,这中间有几个问题：

①如何说服已经习惯了TFVC工做流程的其余同事使用上git；

②在git上如何作代码管控。

 

要说这个问题前先说说为何我本身喜欢用git：

首先我以为在技术选型上必定要避免由于这个是最流行/最新因此我就要用它的这种形而上学主义,咱们要用一个产品,必定要明白它是什么,以及它是为了解决什么问题而诞生的,只有这样才能选到合适的产品(注意:是合适,而不是”最好”)。

我我的是个BYOD主义者（自带设备上班）,一方面是客观上公司电脑战斗渣（起码如今升级后仍是机械盘,俺主力的微软亲儿子4好歹是个全固态)，另外一方面被BYOD思想给洗脑了,在另外一方面还能方便随时随地加个班…

git的离线提交对我而言是个至关强有力的功能存在。

另外和集中式管控的每次提交都要作策略不一样,我我的更倾向于每次提交无需任何策略检查,而是在pull request阶段在作策略的”打包式代码管控”。

在另外的就是git的分支,让分支这个功能今后变得唾手可得..

基于上述理由因此我选择了git。

 

而后就是对原有同事的”普法”了，其中一个比较头疼的问题是git的commit和push这2个概念常常说不清,虽然如今的我也不见得就能说清,毕竟TFVC的时候点下提交就真的上服务器了,而如今你”提交”了不算数,还要在同步(sync)或者推送(push)一下才能够。

在另外就是启用了pull request来管理须要开发/发布的代码,同时也是初步引入了”代码审查“的概念：每次pull request都须要非本人以外至少一人赞成：

而后由于git的分支使用起来特别方便,以后协同开发也变得更加方便,由于各自都在各自的分支里进行独立开发。

并且自此咱们每次发布后都会按照当时发布日期拉一个分支出来做为备份分支,用于作各类临时更新所须要的处理：

阶段总结,因为引入了git给咱们带来了:

①更方便你们协同合做开发,如今每一个人都有本身的开发分支来开发本身负责的功能；

②更方便拉取备份分支,今后咱们组在处理临更这件事上更加游刃有余；

③引入了Pull Request和最原始的代码审核。

 

第2章--引入最初的自动发布

从第0章的历史里已经写到,原来咱们是没有任何自动发布的工具或者套路的，咱们的一个常规发布流程是:先开发好,而后用vs的”右键->publish”生成一个发布包(文件夹)，而后提交到svn，在告知qa的同事拿包更新到测试环境。

首先这个流程繁琐而又浪费时间，其次还常常出错，并且时而还发生好比某人的代码没合并进去之类的恶性问题，不管是咱们开发组仍是qa组都对这个苦不堪言，因而自动发布被提上优先处理的日程。

最第一版本的自动发布的想法只是简单的将vs里的”右键->publish”自动化。

首先咱们知道vs的publish是能够支持发布到远程服务器的：

我只要在target location填入目标服务器的共享文件夹地址且我服务器有权限访问目标服务器的话，那么就能够直接发布上去：

对应的在tfs里的Build Solution步骤里的MS Build参数里只要填上发布的对应配置文件，就能将上述过程变得自动化。

但这套方案有以下几个问题：

①被发布的机器必定要有共享文件夹配置；

②Build Agent到被发布的机器必定要有访问对应共享文件夹的权限（要事先弄好）；

③每次发布其实都是从代码库里将代码拖出来再从新编译的，若是比对版本的话各个环境的dll版本都是不匹配的..(最起码文件建立时间铁定不同)。

这就致使配置这套要被发布的机器和BuildAgent同时都要作不一样程度的配置，并且这个明显对后期不管BuildAgent的增长或者是被发布的服务器增长都不是个好事，但毕竟第一步，有好过没有，先上了再说。

 

另一点是咱们正规作法是提交代码时候都是不能带dll的,因此如今本地引用dll的形式在自动发布的时候都很容易会出现问题(别跟我说将dll提交到版本管控里)。

也所以咱们首次将nuget做为一个必须项引入进来,在此以前nuget虽然也有可是都是属于想用就用,不想用就本地dll这样的方式。

因为自动发布的须要，咱们再也不容许本地引用dll而要求全部外部依赖必须经过nuget服务器来进行管理。

 

同时，QA组同时也对这个流程上提出意见，他们要求上测试环境必需要他们赞成才能够而不是开发说想何时上就何时上（否则我就配置个Trigger搞持续集成了）。

因而咱们新引入了QA分支的概念。

QA分支只有QA组的同事有pull request的审核权限，以下图这样的配置：

QA分支只要赞成后就会自动触发Demo环境（第一个测试环境）的自动发布（经过Trigger实现），后续testing环境和预发布环境也只会基于QA分支的代码来进行。

而后试用一段时间下来，有自动发布的项目在发布上的问题明显减小了不少，并且QA同事花在更新包到测试环境上所需时间也明显下降。

 

阶段总结：

①引入了自动发布；

②引入了QA分支，明确了发布上的流程；

③将nuget做为引用外部dll的惟一选择，统一外部依赖的管理。

 

第3章 自动发布的优化

此时微软发布了TFS2015Update2，相关更新内容能够参考 TFS2015Update2更新日志。

其中最重要的一点是：

引入了Release Management的功能，之前这是做为一个独立产品的如今做为一个子功能整合到了TFS里，而后又在咱们老大协助上让运维那边升级了TFS到Update2以后，就着手怎么让咱们也用上“Release”的功能。

另一点是这个版本开始TFS也有了本身的Store，今后走上了能够装各类扩展的日子了

 

首先我理解的Release和原先已有的Build应该是这样子的:

先经过Build将代码变成dll,而后找个地方存起来,以后就经过Release发布到各个环境，因为Release只是充当一个“复制dll+配置“的功能,而dll都是最初那个Build生成的，因此各环境下的dll应该都是同样的。

而后通过调整后（删掉有的没的只留下必要的）一个典型的Build的步骤是这个样子的：

而后Release的步骤大概是这样：

这里不会详情阐述上述截图的意思，具体的配置能够参考微软官方文档Build for Asp.Net 和 Deploy to Windows VM

到如今咱们的自动发布就变成相似这样：

注意中间的格子，灰色表明对应环境没执行发布动做，而绿色则是发布过且发布成功，对应还有黄色（发布了但部分红功）和红色（发布失败）。

而后咱们项目发布过程到达了哪一个阶段如今也能一目了然而不是老是跑过去问QA：”如今发布到哪里了，testing上了吗？”。

 

在这套自动发布上了以后没多久,我惊讶发如今Release里的”IIS Web App Deployment”的Task有这么一个东西：

虽然我英语很差，不过字里行间隐约猜到它应该是能够在部署期间替换某些参数（猜想跟Vs发布时候的那个Transform那样）。

之前咱们发布的时候都要求排除掉web.config的，由于像是数据库连接字符串，在各个环境下都不同，而后就各个环境web.config实现准备好，发布时候不发布web.config这样的方式来解决。

这有个问题是咱们常常更新nuget包的时候其实它是会动web.config的，而后这种变更每次在SVN包里写个txt告诉QA怎么改（你能想象QA们在一堆xml里找到你须要的节点而后作对应修改的痛苦么？）。

相似这样子：

后面运维那边提出将“环境相关”的web.config抽取出独立的config文件来做为不更新的部分，web.config总体就做为发布的一部分每次都更新，大致拆分的Web.Config的拆分能够参考 使用 ConfigSource 特性 拆分 Web.config 文件

但我总归以为这种事情应该要能更“自动化”的解决，并且一个文件若是长久不发布后面万一真要变的时候谁会想的起还有这码事？而后就去研究那个”Web Deploy Parameter File“。

发觉只要指定一个xml文件而后在IIS部署阶段Web Deploy就会用对应配置文件替换掉你站点里的全部指定配置文件（没错，是全部，不局限于web.config）。

它的文件定义大概是这样子的：

 

后面投入使用后也反馈良好，自此以后咱们开发将web.config也做为发布文件发布上去，而后每次发布的时候会透着这个文件在部署阶段自动转换注入数据库连接字符串或者某些appsetting。

自此作了这套方案的项目，基本上没有经过一个txt的形式告诉QA怎么改配置文件了。

 

阶段总结：

①升级了TFS得到了Release Management功能以及支持商店功能；

②将自动发布拆分了Build和Release两个步骤，更规范的自动发布流程；

③经过Release咱们开发能清楚知道如今测试到什么阶段；

④web.config为表明的发布配置自动化。

 

大总结

经历过上述折腾，如今咱们基本从封建时代阶段步入工业革命时代，引入了git（特别是它的分支功能），引入了自动化发布。

总体让咱们组进入初步现代化的阶段。

以后将会讲讲咱们组基于TFS如何来作代码分析，整合监控，NetCore的支持等，敬请期待..