如何选择适合自己的Team Foundation Server部署方案

微软的Team Foundation Server作为企业级DevOps解决方案，已经经过了超过10年连续8个大版本的迭代，在全球多家大型企业中支撑着超过5000人的大型软件研发团队。作为一款为企业级产品，其服务器的部署模式，可靠性，安全性，可维护性都经历了多重考验和国内外上万家企业用户的严苛考量。应该说，如果从企业级软件的综合能力评价来说，当前市场上没有任何一款DevOps解决方案产品可以与TFS进行抗衡。在中国大陆地区，leansoft团队已经实施了多家超过千人的软件研发团队，为他们提供可靠稳定的DevOps解决方案服务器运维工作。对于如何能够确保这一复杂企业级应用的服务持续性我们具有其他服务提供商不具备的经验和技能。

这篇文章的目的为了能够让选择TFS作为自己研发团队的DevOps解决方案的管理者了解如何能够发挥TFS的高性能，可扩展性，可维护性和高可用性等特性，确保这一研发业务关键性系统的服务持续性。

我们会主要关注一下两个方面的内容

1. 如何选择正确的TFS系统网络拓扑
2. 怎样规划TFS数据存储策略

如何选择适合自己公司的 Team Foundation Server（TFS）方案？ 这里有很多人都会在选择方案时从以下几个方面考虑：

1. TFS的性能怎么样？
2. 我有多少人要用TFS？
3. 我的TFS服务器是不是要具备高可用性？

如何选择正确的TFS系统网络拓扑

首先如果你是一个小于5人的微型创业团队，建议使用 Viusal Studio Team Service（VSTS）！ 当然VSTS与TFS的差异还是蛮大的（点这里看差异），比如：最大的差异就是VSTS是一个SaaS系统，还有就是账户系统，数据仓库等等，但是总体来讲VSTS才是初创企业的更好选择，因为你能借助VSTS，Azure帮助你快速实现DevOps, 这个话题我们后面会详细说。

TFS的官方部署方案有三种： 1. 单机部署；2. 双机部署， 3. 集群部署。

微软官方的部署建议是：

这个方案只是参考，实际硬件选择还要从多方面考虑，下面会进行介绍。

这里基于官方给出的方案给出了几种扩展方案，并简单说明：

• 首先，只要是生产环境，就不建议使用单机部署。单机部署方案就简单说就是将SQL Server与Team Foundation Server及其他服务（如：搜索，代理）安装在同一台服务器。
• 部署方案一：500人以下可以考虑使用双机部署方案。 如下图：

• 部署方案二：如果500人以上，但是数据量不大的情况下可以考虑使用下面的部署方式，随着服务器压力的不断提升，可以按照实际情况添加TFS应用服务器数量

• 部署方案三：如果使用人数超过了500人，并且发现TFS的数据量很大，且增长很快，我们可以考虑将对TFS的数据层做分布式部署，也就是把集合数据库放置在不同的数据库服务器的数据库实例中。对于怎样规划数据库集合，下面会讲

• 部署方案四： 随着人数的增长，单个数据库实例很难满足性能要求，这样我们就需要考虑将集合数据库部署到多个数据库实例上，并且对于大型团队来说，一般情况下TFS都是要支持高可用的。如采用高可用方案，TFS配置数据库所在的数据库实例是必须要进行SQL Server AlwaysOn部署的，集合数据库所在数据库实例可选。因为配置数据库一旦发生故障，那么TFS将不能访问，而集合数据库只会影响数据库映射的TFS集合不能访问。

这里对最复杂的部署方案四配置进行一下详细说明： 用户通过DNS域名访问TFS服务器，DNS指向负载均衡（软负载，硬负载均可），负载均衡内配置好所有的应用层， 所有应用层都通过数据库实例上配置的AlwaysOn高可用性组的侦听器指向同一个TFS配置数据库（这个在配置向导中选择已有的TFS配置数据库即可），这样就做好了一个高可用性的TFS部署，在使用过程中可以将新建集合配置在其他数据库实例，并且如果新增集合数据库实例也配置了AlwaysOn高可用性组，那么在添加新集合的配置向导中，需要指定新集合的AlwaysOn高可用性组的侦听器。

大家在选择部署方案时需要考虑几个问题：

1. TFS用户规模和具体使用场景

这里我们不能只考虑用户数量，应该从多角度考虑，如：

• 你准备使用TFS的那些功能？ 工作跟踪，源代码管理， 自动化生成&发布，测试，Wiki？

如果你只打算使用工作跟踪，源代码管理，那按照微软的硬件建议就没有问题，如果不是那就要适当提高系统性能

• 你现在软件团队的基本情况， 如：你是否在使用敏捷开发？使用系统的人员是外包人员？平均每个人员使用系统的频率？

这跟敏捷开发有什么关系？ 我可以用我的实际经验告诉你， 一个执行良好敏捷开发的200人团队，在使用双机TFS部署时对系统造成的压力，要高于一个500人的主要由外包人员组成的开发团队。

• 你有多少人要用系统？

分析完上面的问题，我们就可以由人数来确定最终的部署方案了

1. TFS所提供的功能的操作性能

提高T操作性能的主要手段，就是提升服务器性能，比如：采用集群部署，系统服务器性能就会优于同等硬件条件下的双机部署。同时我们也对TFS进行了多次压力测试，这里给大家分享一下关于调用TFS服务创建工作项的：

对于TFS的工作项进行创建，查询操作的压力测试（本次测试过程中对TFS进行了一系列调优操作，详细请看）

根据实际使用计算100并发相当于一个大于2000人的团队对服务器产生的压力峰值，希望以上的数据可以对大家选择部署方案有帮助

3. 是否需要高可用？

我们在部署TFS之前要先决定是否要需要采用高可用部署方案，需要考虑的因素如下：

• 团队是否可以接受TFS宕机时间小于2小时。TFS恢复非常简单，只要数据不丢，可以很快将应用重新配置并启动。
• 如果发生硬件灾难导致数据丢失，团队是否可以接受丢失的数据不超过宕机前15分钟。因为TFS的应用层是无状态存储，所有的数据全部在数据中，并且TFS自身自动化数据备份策略，可以实现每15分钟备份一次（可以更短，但是不建议，如果用户量大，使用频率高的话，建议最少一个小时）
• 高可用的优点及缺点，优点很明显：当发生服务器宕机时，服务不会中断。缺点同样很明显：维护较为复杂，比较容易出现问题，而且一旦出现问题，修复时间较长。这里的问题大家不要误解，不是指微软的产品问题，而是自身的运维问题。 因为我就遇到过一个场景：一个客户的运维人员给服务器做了个杀毒软件升级，结果TFS宕机，而且产生了数据同步错误，最后花了1天的时间查找并解决问题。

如果你能接受一定程度的服务中断和数据丢失，那么非高可用性方案就是你的最佳选择。并且对于很多企业来讲，硬件本身就具备高可用策略，已经可以不考虑数据丢失的因素。因此对于中小团队推荐优先考虑非高可用方案。

如果一定需要实施高可用，具体的方案主要包含两部分：

• 使用Microsoft SQL Server的AlwaysOn支持数据库的高可用（点击这里查看SQL Server ALwaysOn）
• 在多台服务器上部署TFS应用，并链接到同一个数据库实例

综上所述，针对不同的使用场景，这里给大家一个建议配置：

怎样规划TFS数据存储策略

这里先介绍一下TFS的数据层：

1. TFS的所有数据都在数据库中，包括配置，工作项，生成，代码，测试等等
2. TFS数据库有：Tfs_Configuration配置数据库，存储所有TFS系统的配置信息及账户信息；Tfs_Collection集合数据库中包含所有在集合中创建的团队项目，上传的代码，生成，工作项等等数据；Tfs_Warehouse是TFS的数据仓库，TFS会定期将配置数据库以及集合数据库中的数据整理并同步到数据仓库中，以便我们查看及进行数据分析；Tfs_Ayalysis是SQL Server的Cube数据库，数据来源就是Tfs_Warehouse。
3. 所有集合数据库必须要在配置数据库中注册才能使用，但是集合数据库能被单独分离，并在其他TFS配置数据库中注册

因为TFS的数据存储结构，我们对于TFS团队项目集合的创建可以使用如下方案：

• 在数据量、使用人数及访问量没有达到你能承受的极限以前，尽量保持单集合数据库，也就是所有开发团队都链接到同一个集合。这样做可以让你的所有团队在具备权限的情况下查看其他团队的信息，更好的进行协同操作
• 如果发现数据库性能达到瓶颈，或者数据量过于庞大，那么可以考虑将现有集合进行分离（点击这里查看如何分离集合数据库），并且同时考虑将分离出来的集合数据库放在其他数据库服务器上

虽然对于大数据量的TFS集合数据库来说，并不会导致性能下降，但是过大的集合数据库会大大提高我们的维护成本，比如：对于一个1T的集合数据库的30天TFS自动备份，文件自身的大小就会达到4T，因此在日常使用TFS时要注意以下会影响数据库大小的操作：

• 尽量不要把文档放置在TFS的代码版本管理工具（TFVC，Git）中，建议使用SharePoint作为文档存储，因为其具备在线协同编辑，文档的全文检索等。
• 尽量不要在工作项中上传附件，因为无法对版本进行管理，而且查看麻烦。应该将文档保存在SharePoint中。
• 当你的团队在频繁进行自动化构建操作时，绝对不要把TFS生成结果保存在TFS服务器， 因为会快速撑爆的数据库，而且你只能等生成定义的保留策略到期之后才能删除这些保存的数据。
• 在测试时，尽量不要录制视频，音频等多媒体文件