作为一名开发,经过近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相关之前先插入一个番外篇，虽然跟TFS关系不大但跟DevOps关系很大，觉得有必要在此乱入一下。
番外篇--监控之Application Insights
我们之前并没有任何监控类产品（我指的是应用程序级别的），发生任何异常都是往数据库的表里insert个错误日志，all系统共用同一张错误表。
这其实意味着我们当时的系统是：系统异常基本不关注（线上数据库开发肯定没法查对吧），关注的时候肯定都出事了，对自己负责的系统的运行状态基本不了解，什么性能之类东西纯粹靠猜。
然后我就希望我们能有办法获取到我们系统的各种状态，而此时在VS2015的时候整合在VS里的application insights引起了我的关注。
简要介绍下application insights,是微软基于azure所推出的一款SAAS性质的APM(Application Performance Management,应用程序性能管理)服务，本人不会详细介绍这个，详情可参阅官方文档。
然后也感谢我大学年代曾经当过MSP（微软校园菁英）并透过这个拿到过Visual Studio Enterprise的订阅，然后里面附赠的每个月150美元额度的Azure费用，让我有条件可以先试用Application Insights。
然后自己将自己负责的站点搭上Insights做了个小Demo展示了给老大看，然后老大也对此表示满意。
(Application Insights的概览图)
在后续的一次PMO会上我将此拿出来进行了演示，也获得了CTO的认可和支持，然后终于可以将Application Insights投入到线上使用（当然此时用的是公司正式的账号而不是我那个150刀每月的测试号了）。
但是有Insights投入初期其他小伙伴热情度并不高，大家还是觉得记数据库挺好的，直到后面发生了一件事…
事情是这样的，那是一个要常规发布的夜晚，因为并没有数据库相关的修改，所以DBA已经下班了（要加班到夜里发布，DBA只是正常下班），然后某站点发布上去的时候报错了，然后对应的开发小伙伴不知道为什么，就知道出异常了。
然后此时DBA不在，无法查线上数据库，然后就干着急，最后通过在代码里让异常本地写txt临时解决了发布上的问题，但这个问题完整暴露出记录数据库的不靠谱：万一DBA不在呢？毕竟如果没数据库内容的话总把DBA留下来的话其实也不合理，我们应该要从更长远和更科学的方案解决这个问题。
至此后续我们所有项目加入Insights的进程就加快了，因为Insights里我们可以自主的查看到性能/请求/异常等各种数据了。
另外有了Insights后我们开发自己第一次有了自己的程序运行数据，有时候我们也会针对Insights里的数据做一些对应的优化。
如上图，这是一个通过城市Id获取城市名称的接口，原先调用量巨大（当时设置了50%采样率，所以实际调用量要比图中翻一倍）但是其实这个接口返回的内容可变性不高，然后让前端加了缓存后从原来至少10K以上每小时调用量下降到现在100多的调用量，而这些都是因为我们有了Insights之后才能进行的。
所以说：优化不能靠猜，我们要用数据说话。
而Insights的Analysis功能/智能预警功能等特性也在实际中帮我们解决了不少问题。
然后Insights也是可以跟TFS进行一定程度的整合的，其中主要包括自动发布的时候打上注解和在TFS的面板里查看Insights的信息
版本注解，有了这个我们可以从监控系统里知道什么时候上了预发布环境
可添加在TFS上的widget(新版本的，详情可参看Application Insights: VSTS dashboard chart widget now available)
然后最近Insights里还有各种Preview的功能，比如新的Preview性能面板里能查看到95线/99线等，新的异常面板里还能给你分析出你异常的共同点之类的，Insights也一直在进步着。
在定型监控系统的时候我们曾经议论过听云和是否自建服务端（当时确定了监控的SDK都是用Insights的，但是纠结于是否基于ELK自建服务端）
听云：
老实说从默认的图表来说，听云比Insights的图表更全面，但听云缺乏一个Insights里有的一个很重要功能，查询分析Analysis：
在Insights的Analysis里，可以通过一个长的很像Sql的一种语句，可以快速查询你想要的任何原始数据（精确到每一条）,此语句也能绘制图表，这个绝对是对程序员Friendly的一个功能
比方说出了异常，可能从运维层面更关注异常的趋势，而开发层面更关注的是具体的每一个异常，和每一个异常对应的每一个请求等，另外听云因为是服务器层面的监控无法在代码层面埋点，我们Insights里则埋了如果异常的话将错误请求的Body记录到Insights的Traces里，这样就算是Post/Put之类的请求报错我们也能拿到原始请求报文。
自建服务端：
关于这个我觉得在我们现在连Redis啊队列啊这些更紧急的东西都没有落实的情况下在分出人力去搞这个，就担心做出来后就是个永恒的1.0版本，觉得类似这种东西除非说有专职负责这个的人/团队不然不应该自建，再说那个时候我们组已经用Insights好一段时间了（有接近1年了吧）习惯了上面各种高级特性，而原始版的ELK则呵呵哒（一个自个买的原始毛胚房VS一个租来的豪华精装房），当然如果有专职人员专门投入到上面基于ELK做定制开发我相信也肯定能做的跟Insights那样或者比Insights更好，但是，我们有更多更紧急的事不是么？
不过倒是有一点是因为费用问题我们的Insights是使用了采样率的（就是说并不是收集全部而是部分收集），但是我们希望异常不要被采样，所以后面可能要基于ELK搞个Exceptionless来专门记录异常。
另外Insights跟VS的整合也是棒棒哒，比如下面这样，直接告诉我哪个方法发生了异常，直接反映在CodeLens里
第4篇--自行管理BuildAgent
原先整个TFS服务器的搭建和维护都在运维那边，那为什么要拿出这个来说呢？
首先我们现在正处于一个快速发展的年代，什么框架啊每月总能冒出几个，技术各种日新月异，虽然绝大多数企业本着稳定至上的原则不会说总是用最新，但这不是固步自封，不思进取的借口，在一个“最新”变为”稳定“之后总要试着跳出舒适区步入现代化进程吧？
然后我们遇到的第一件事就是.Net版本升级,我们计划升级到.Net 4.6.2（原来是4.0到4.5.1不等），然后因为自动打包的原因所以要求Build Agent也要升级，然后原先运维部署配置的TFS是服务器+Build Agent放在同一个机器上的，搭载的是VS2015.
然后除了4.6.2之外的话我们有个别类库项目使用上了.Net Core里全新的xproj格式来进行多target framework的开发，这也要求服务器上要有.Net Core的Sdk。
在另外此时在讨论到代码质量审核，然后我们初定使用Sonarqube，而这个也要求Build Agent服务器要有Java的功能。
基于上述原因外加后面我们技术部某神秘人物毛哥批了一批（2台）服务器（也就一般工作电脑）资源给我，后面还有CTO批了一台大服务器（真·服务器，当时可是嘻嘻哒的内心
），然后我开始自己搭建Build Agent。
当前我们组自行维护的4台Build Agent，承载了包括持续集成，自动打包，代码分析，自动测试等一系列任务
装上了一堆现在要用或将来希望想用的功能，满足当前及其可预见的一段时间内的需求
其实关于Build Agent主要觉得这个必须要能适应开发组的步伐，首先我们.Net 4.5->.Net 4.6.2的时候，要求Build Agent要支持.Net 4.6.2或以上，之后我们有计划要上.Net Core（此时已经有基于.Net Core项目的Dll包了），而且之后.Net Core还有2.0版本（主要是NetStandard 2.0），所以我觉得这个Build Agent在我们组内的话我们能更好适配我们的前进步伐。
现在我们的Build Agent里装的是Vs2017 17.3 + .Net 4.7 + .Net Core 2.0 + Docker 17.03.2-ee + CMake 3.9.1 + Python 3.6.2(x64) + JMeter 3.0 + F# 4.1 + Node.js 8.4(x64) + Java 1.8
估计小半年内基本都能满足需求。
第5篇--自动代码质量检查
接着上篇说，我们有了自己的Build Agent，然后自动发布之类的基础功能也有了，于是我们就有更高层次的自动化追求了。
首先就是自动化代码质量检查，在此先声明一点：任何自动化代码质量检查工具都不能代替人肉的Code Review，但能减少人肉Code Review的工作量。
然后在选型上我们选了Sonarqube，当然你们会问为什么选Sonarqube，说来惭愧其实我之前并不了解相关产品，然后在TFS商店里看到了这货然后才知道还能自动化代码检查…然后就去研究这货，发觉总体还可以（规则之类的啊，还有跨平台等），在跟我们技术部神秘人物毛哥上报下技术选型获得认证后就拍板开始干。
通过自己手头有的服务器资源，搭建了个Sonarqube服务器，然后通过TFS的任务加上去
一个带Sonarqube分析的编译过程，作为C#程序员看上去好像一个using的结构（开始->释放)
某项目分析结果
好，然后代码分析质量有了，大家就能照着上面去“优化”代码了。
慢着，我写了一段代码，因为水平问题我也不知道有没有咖喱，然后一提交，然后上面就留下了一个永恒的污点（有历史记录的），这样肯定很不爽，所以后面我们就纠结有没办法能够让代码在进入到Sonarqube系统之前先有个反馈。
然后此时微软就发布了TFS2017，具体参考 TFS2017RTM Release Note
其中它引入了这么一个功能
在拉取请求的时候显示Sonarqube的分析结果（直接定位到你代码上），且该分析结果不记录到Sonarqube服务器里
接着怂恿下老大出面让运维那边帮忙升个级。
然后为了配合Sonarqube，那么每个项目在Pull Request的时候都要进行编译的过程（编译了Sonarqube才能分析），因此也顺带加上了阻止合并不能编译的代码这个额外附加项。
同意一次Pull Request需要一个非本人外的其他人同意且要编译成功
然后审核人也能看到Sonarqube分析的结果就不用每行仔细看也能大概知道个所以然。
当然实践过程中，看别人的代码发现不少什么超过3重if嵌套啊，类超过1000行啊这些，他们总说由于某些原因实在不好改的，那就只能忍了（你能怎么办呢，特别是多重if的往往都是各种业务条件判断复杂，然后自己也没空深入去看他们的业务），但自己项目要求要严格点，要严格控制不能出现任何形式的咖喱。
另外在此吐槽一点：TFS不能直接在Dashboard里浏览Sonarqube的结果，要看Sonarqube结果还要跳到Soanrqube里去，这不符合All in one的TFS理念啊，就没人想过弄个Widget什么的来解决解决这个问题？
第6章--自动测试
自动测试在这里想主要分2块来说，单元测试和集成测试。
首先我觉得对于这2个概念尽管有很官方的说明但实践中很多人都有自己的理解，我简单说下我自己对上述2个词的理解和定义
单元测试：在代码内部进行的不依赖外部环境（网络/数据库等）进行的对某个方法级的测试，特点是只能测试一小块逻辑,能模拟数据且运行较快（毫秒级），代码执行结果可预测。
集成测试：可能是代码也可能是脚本依赖外部环境（网络/数据库等）进行的针对某个流程上的测试，特点是要造数据且运行较慢（至少是秒级），代码执行结果绝大多数情况下可预测（受外部因素影响不能100%可控）。
单元测试：
要让代码可以被单元测试，首先代码先要是可测试的，要如何做到代码可测试呢？答案很简单，随便街上抓一个伪计算机专业的都能给出你正确答案：解耦。
但是你要真的落实“解耦”到你的代码里，又往往是一个异常艰巨的任务（Talk is cheat, show me the code)。
首先在我自己负责的项目里，完全使用依赖注入的形式重构了，另外抽象出了各种各样的接口，理论上要做到所有的”Service“都是可以”被替换”的。
严格限制对static和new这2个关键字的使用（绝大多数情况下static或者new都意味着不可测试，当然static一个数据无关的方法比如Math.Min之类的或者new一个纯数据类这些例外）
在自己一番折腾下，现在自己负责的项目单元测试覆盖率70%+，也算是一个自己比较满意的数字了（这个是Resharper收集的，它将单元测试项目本身也包含进去了的）
在单元测试的加持下，自己想重构代码什么的都能放开手去重构，有没有影响老逻辑？测试跑一下就知道了。
而加新逻辑的时候也能知道会对原有流程造成怎么样的影响。
总之有单元测试后，你会对你的代码更加倍有信心。关于单元测试看看日后是否专门开一篇文章来说说，里面也有大学问。
上面说了那么多单元测试，那么它跟TFS有啥关系呢？测试写完了是吧？你怎么能确保它一定是有在跑呢？这时就可以将单元测试的运行整合在自动编译的流程里
整合到编译流程里的单元测试，每次跑完后会报告结果，如果单元测试失败那么会阻止pull request
在TFS主页的Dashboard里展示单元测试结果
集成测试
我们的集成测试现在主要是QA那边负责，QA那边有基于Jmeter来进行的测试，具体细节因为不是我负责所以我不是特别清楚，但是在Build Agent里装好Jmeter后（QA配置好了各种他们要的插件的版本）然后在自动发布的时候运行下就好了
运行QA他们指定的Jmeter，先从一个位置拷贝配置文件过来然后运行命令行，没错，从TFS角度去理解的话它只是去执行个命令行而已
不过当前QA他们弄的Jmeter是运行后发一个结果邮件，如果能够将Jmeter的测试结果转变为TFS可接收的某种测试结果格式（什么JUnit或者Xunit之类的测试结果）展示到TFS上那就更好了（如果有会的人请赐教）
在集成测试方面我自己也有一套基于代码的（当然现在主流都是基于脚本了）
基于Specflow+xunit的方式我自己做了几个我旗下项目主流程的测试用例（就是那种一出问题QA就邮件出来：”测试环境挂拉“的那种）
基于Specflow的BDD形式的描述文档，尽可能弄的贴近业务层面
描述文档背后对应的是若干代码
目前我自己这套集成测试仅放在Demo环境（第一个测试环境）使用，主要是一旦发觉个风吹草动，立马还原代码…(逃…
关于集成测试按道理此处应有以Selenium为代表的UI自动化测试，不过我自己主要负责的是接口，然后让折腾UI的那位同事目前也只是处于演示级阶段还没正式投入使用，此处就不献丑了。
当然TFS上还有管理手工测试等各种功能，不过由于QA组是基于Jira来管理任务所以并没使用。
第7章--引入NetCore的打包
尽管我们当前在经过一番折腾后全组项目目前已经统一到.Net 4.6.2，但短时间内也不会用上NetCore，但背后一直为了NetCore的迁移在默默准备着。
主要是考虑到在NetCore 2.0后出了个NetStandard2.0，它跟NetCore 2.0以及.Net Framework 4.6.1是兼容的。
那么我们现在项目代码的目标都是兼容Netstandard2.0（底层类库)，但之后真要迁移的时候就改个TargetFramework以及表现层稍微改下就好了（嗯，很丰满的理想）。
说这篇呢主要是分享一个，我们现在TFS是2017Update2，在这个版本下你用常规方法是无法引用任何Netstandard2.0的包的（不信你们试试）
其本质是因为TFS2017Update2自带的Nuget还原工具是4.0版，而4.0是不支持NetStandard2.0，要4.3才可以，那难道我们在现有的TFS下（2018又没Release）就拿NetStandard没辙了？
然后就找到了这篇文章Using the latest NuGet in your build
在这篇文章指引下，将它 那堆Powershell脚本 粘贴上去执行,下面参数写个4.3.0
然后使用自定义的nuget
然后就迎来了胜利的曙光
第8章--我们基于TFS的小折腾
任务管理
虽然我司一直是基于Jira做任务管理的，不过因为Jira并不能直接跟TFS上的代码进行关联，所以我私自上是喜欢在TFS里建对应任务然后关联上去
还能跟代码里结合起来
在TFS里也能做可视化的关联查询
自动备份分支
这是最近折腾出来的小玩意
在Release里加上这个步骤（这是个插件提供的，插件详情请点此处）
然后在执行到对应发布步骤的时候就会自动将当前发布的代码拉一个分支出来，全自动的哟。
第9章—VNext
上面的大概就是我们现在折腾TFS的成果，但我们的道路远没结束，或者说，现在又处在某种程度上的开始。
首先，Docker这个大趋势肯定之后或多或少都要涉足进去的（不过觉得先将诸如服务发现之类的前置条件先搞定在做这个）
还有撇了下隔壁TFS2018的Release Note,这回引入了Wiki功能，回头可能可以直接在TFS上直接写上各种知识库文章了
还有想整个OWASP ZAP然后跟TFS流程整合下来个自动渗透测试分析什么的，让我们自动化更上一层楼(if有空弄的话)。
原文： http://www.cnblogs.com/leolaw/p/7821335.html