Team Foundation Version Control的未来

Brian Harry MS [原文发表地址] The future of Team Foundation Version control [原文发表时间] 2015-03-12 9:10AM 我之前已经写过类似的东西,但是现在我又不断地想起它。我时常会问自己“TFVS完蛋了吗?”我估计我只能回答。不,它还没有。 我们在TFS 2013 中加入了对Git的支持,以便于我们可以支持行业里最好的集中式版本控制系统和最好的分布式版本控制系统(DVCS)。我们已经为Git做了很多投入,为了使它能和TFVS的用处相媲美,我们做了大量的工作。大家可能因为很多原因混淆了。我们谈论很多我们在Git上的一些进展。这个行业对Git也谈论了很多。如果你一直关注着,那么你会听到越来越多微软的内部团队正在采用Git。我自己的团队已经把一部分东西放在了Git上。这些都是真的,并且一些人认为TFVC正在被抛弃。才不是! 我们大部分的客户仍在使用TFVC,并且我们非常重视它。微软的大部分人也仍在使用TFVC。大部分使用VS Online创建的工程时也选择TFVC。毫无疑问,我们正看到一种转变,Git正在成长,并且我完全期望它将持续成长。接下来的这几年Git的市场占有率可能会超过50%– 我不知道,但这是有可能的。不管怎样,我们仍有数十万,或者数百万的TFVC用户。对我们来讲,在一段非常长的时间内,它将会很重要。 这些都只是说说,让我给你们提供一些证据。 TFVC的核心引擎是非常成熟的。它已经被用于超大型团队,并且被证明是非常可信赖的。 在TFVC投入方面,我们绝大部分的关注点是“围绕核心”。让我给你们举一些例子。 我们已经在网络的Version Control 的UI上做了一些工作-允许像网络编辑,签入,删除等的事情。我们已经在TFVC上实现了这些。 我们加入了对“欢迎页面的支持”,就像维基百科那样。我们使它可以工作在TFVC上。 我们已经完成了TFVC上的一些CodeLens 指标的工作。包括一些只对TFVC有效的东西-像“即将改变”指标。 Build.Vnext支持TFVC。 我们正在构建一种新的代码搜索体验。尽管个人预览只在Git上支持,我们将会在上市前添加TFVC的支持。 我们正关注在代码回顾的改进上,包含像支持迭代代码回顾,网络体验,使用内联注释提高VS体验等。所有的这些都将在TFVC上出现。 我们不久以前通过添加对Mac/Linux上团队查看器的支持,解决了一个普遍的抱怨-TFVC上大于260个字符的本地路径。 团队工程重命名最大一部分的工作已经在TFVC里得到了完整的支持。在引擎中,我们已经做了很多核心的改变来支持它工作。 我们正努力使TFVC和Git可以在同一个项目里更好的共存-当然这需要TFVC。 有很多事情我大概忘记了,还有一些事情我还没有准备告诉大家。TFVC不仅没有完蛋,而且我们很大程度上继续去对它进行投入,这种投入还会持续进行。选择最适合你的工作流的版本控制,时刻保持自信,因为我们会继续带领你前进。 我希望这能帮助您处理一些疑问。请让我知道您是否还有一些其他我能帮助到您的。 Brian


数字证书的变化- 用户验收性测试和敏捷计划

[原文发表地址]Licensing changes – User acceptance testing and Agile planning [原文发表时间]2015-1-27 10:00 am 接下来所说的就是我在十二月份列出的一系列数字证书和功能改变的一部分。在这些改变中,我认为我说过的关于云(或者更多)的改变已经发生了. 另外的一些on-prem的改变会在on-prem更新发布之后才生效 用户验收性测试 截至本周,在用VS在线进行用户验收性测试的时候,将不再需要一个VS在线的高级账号。只是你仍然需要一个账户来创建和管理测试计划,如果你只是要执行测试用例,报告结果,开bug等基本的操作,你只需要一个VS在线的基础账户就可以了。 敏捷计划 这一周,我们也将等级待办事项的管理和工作项图表从VS在线高级账户移到了VS在线基础账户中。这意味着当前所有VS在线的 “项目管理”功能在基础账户下都可以用,而不是分散在基础账户和高级账户中。 团队工作间 最后,我们还将团队工作间功能从VS在线高级账户移到了VS在线基础账户中。现在,所有的有VS在线账户的用户都可以完全的参与到团对工作间中(包含了5个免费的用户). 我们所有的这些改变都是根据用户的反馈和我们想要用户尽可能轻松地让整个团队充分参与到整个软件开发过程中的愿望。相同的(TFS CAL,而不是VS高级版/专业版测试)数字证书的变化也会在今年晚些时候发布的TFS2015上可用。我们的VS在线部署应该会在这个周末(2015年一月30号)完成, 而在这之后,这些变化会在你的账户里面变得可用。 这是关于我之前十二月份早些时候发布的许可证变化的封装(而不是on-prem 剩余的等价物)。这并不是说在未来不会有更多改变,但是不要期待会很快就有很多的变化。我们已经达到了一个新的”稳固状态”, 我相信. 过一段时间,我们会收集到关于我们已经做的这些的反馈,然后再看看我们接下来做些什么。 你可能会问,”现在这个时间,做这么多的改变之后,还有什么是留给VS 在线高级账户的呢?”在现在这个时候VS在线高级账户的主要区别就是测试用例的管理体验。但我相信,这只是一时的情况,我们将会给VS在线高级用户添加更多差异性的功能。 谢谢, Brain


Git中.gitconfig 文件的漏洞

原文发表地址: Git vulnerability with .git\config 原文发表时间: 2014-12-18 1:47 PM 今天Git社区披露了Git的一个问题,即就是:在最坏的情况下,允许开发人员接管机器。这个问题出现在Git的整个系统, 而不仅仅出现在微软的Git实现或窗口中。我将会在下文来描述这个问题和问题的解决措施,以确保我们的客户使用Git存储库来防止这个问题。 首先,我想感谢Hg(Mercurial)社区的帮助。Hg(Mercurial)社区发现了一个类似的问题。他们在研究Git时,发现存在同样的问题。他们谨慎地通知了社区中相应的人,并在披露之前做好共享信息和控制信息来减轻这个问题的影响。这是社区合作中的一个很好的例子。 问题 Git中有一个叫config的文件, 它存储在本地Git 存储库 的git文件夹里。这个文件包含大量的个人/选项设置, 其中有关于git命令的替换名。几乎所有git命令都可以通过执行替换名来做任何你想要的事情。 通常情况下,git客户端要避免重写该文件。即使你提交.git \config 文件并把它发送到一个共享的邮箱, 其他人的git客户端也不能将其放在自己的私人邮箱内。然而,在重命名.git 文件夹时, 发现了一个bug, (如大小写混合, gIT, GiT 等等, Windows文件名缩短.git ~ 123,可忽略的Unicode codepoints .g \ u200cit \config, 等) 一个不能被Git客户端逻辑过滤的问题。这样,如果有人发送一个有上述一种情况的恶意config文件,其他人的Git客户端就会检查出来,覆盖他们的个人配置文件并且改变他们的Git命令。至少,这会影响Windows NTFS和Mac OS X HFS +文件系统,而这两者都是区分大小写的文件系统 风险 风险并不像听起来那么糟糕。当有人要向你做一些有风险的事情时,他们必须向你申请获取信息的邮箱的权限。在一个公司,风险可能就会是内部攻击。最可能的(不是唯一,但最有可能) 场景是在一些小的OSS项目里。大公司通常有知名的/可以信任的提交者。接下来,您将看到已经采取的措施来缓解这个问题。 修复 我们和Git社区的其他成员一起工作准备将这个问题公布出来。我没有对别人说,但是我知道Git核心和GitHub已经在减轻这个问题的影响。我将具体说一下我们(微软) 已经采取的一些步骤。         1. 大概一周之前,,我们在VS Online和Codeplex上应用了一个补丁,防止服务器接受推送的.git \config文件。这个bug其实不是在服务器上(它是在客户端上的),但通过这样做,我们可以减少从我们正在开发的服务器上获取任何更新的客户端的可能性。        …


一个新的Visual Studio Online和Team Foundation Server特性时间表

[原文发表地址] A new Visual Studio Online and Team Foundation Server Features Timeline [原文发表时间] 2014-12-17 10:00 AM 我们一直寻找跟客户更有效的交流方式,有关我们所做的,人们喜欢的、不喜欢的、他们想要的、我们正在计划的、等等。一年前,我们在visualstudio.com的新闻部分添加了特性时间表页面作为这个旅程的第一步。 在新闻部分中,宣布了我们每个开发冲刺阶段所发布的新特性,尤其是VS Online特性时间表将新特性映射到内部部署的TFS版本上,你可以在VS Online里面找到它。以下是摘录的示例: 同时,它们都是反向链接—我们都已经做好了,你可以直接访问。我们所拥有的最好的听取建议的工具就是UserVoice。用它来提交建议和投票给其他的工具非常方便,但是对我们所计划或从事的事情有清晰的蓝图就有点难。我们所做的许多事情都来自于UserVoice中的建议,但也有一些不是。 现在我们用一个新的正在开发的特性”部分更新了我们的特性时间表页面。添加这个部分的目的是为了让你了解我们正在做的一些事情。 无论如何,也还算详尽--起码最初还没有,它提供了关于一些关键投入的不错并简明的视图...这些关键投资可以链接到UserVoice或博客,等等,你可以了解更多有关产品实际的改进,并且给你提供了一个在它还没有发布之前去评论它的机会。 以下是我写这篇博客的一个简介, 我猜测当你读到这篇文章的时候它会有一些不同,因为我们会经常更新它。 为了给你提供一些我们所从事的工作的一些信息,我们同样尝试着给一些有关何时要求它的想法。左边的这一列展示了在VS Online中可用的粗略时间估计。右边的大多数列显示了TFS内部部署的版本和我们期待的新特性的关系。当我们没有足够的自信给出特定的时间段时,我们将会使用TBD。“–”表示与发布的工具无关-或者它已经是可用的了(TFS中的流程模版定制就是一个很好的例子)或者因为不在发布的工具中(TFS的ISO27001证书就是个例子)。 当然,做这项工作的一个风险就是计划的改变。譬如,当我们决定取消我们正在做的事的时候,或简单地改变交付日期,都会有一些风险。当风险发生的时候,我希望你们能够跟我们一起承担。我们目前还没有找出如何应对这些改变的办法,但是,当它一旦发生,我们会找出解决它的办法。 希望这篇文章能给你提供一些有用的信息。由于我们还处于刚开始的试验阶段,如果您有任何有助于我们产品做得更好的反馈和意见,我将非常感谢。 谢谢, Brian


超简单负载测试试用体验

[原文发表地址]Super simple load test trial experience [原文发表时间]10/29/2014 为了使人们更易获取VS在线负载测试,我们几天以前添加了一个基于用户体验的新网站。 当我写到这篇文章的时候,我并不知道这只是针对于有MDSN Ultimate订阅许可的VS在线用户。我们正在讨论是否要改变现在的这种状态,但是现在就只能是这样了。 如果转到任何VS在线账户的账户主页上,你能看到一个最高级别的标签。 点击它,就能打开一个允许你运行的一个非常简单的负载测试。你需要指定一个URL和需求的模拟用户量,测试运行时间,用户的点击速度和浏览器的复杂程度等的一些基本设置,然后点击“现在测试”。 它将从我们的池中申请一个负载测试代理,配置测试,并运行。 一旦完成,它会统计所有的结果,并对负载测试予以简单的分析:显示平均平均响应时间,#每秒的请求和任何遇到的错误。 如果你想要做“真正的”负载测试,那么你需要用Visual Studio旗舰版来创建包含很多的网页,并且每一页有很多步骤等等的复杂负载测试。同时你也可以进行更多详细地分析。 去试试吧。 Brain  


Visual Studio Online在欧洲

[原文发表地址]: Visual Studio Online is in Europe! [原文发表时间]: 27 Oct 2014 9:30 PM 今天,我们在Azure“西欧”地区开放了我们全新并闪亮的VS Online实例,它的位置设在荷兰。这是我们迈出的一大步,也是将VS Online成为一个真正全球性服务的第一步。在过去的一年中,我一直在为不同地区提供宿主数据的能力而 而搜集需求– 从某些方面来讲就是使得他们数据更“本土化”。从其他方面来说就是为了减少访问服务的延迟。无论是什么原因,现在欧洲版是你的选择之一了。 你可以访问http://visualstudio.com来入门, 并创建新的账户。创建账户页面会自动检测离你最近的数据中心,你也可以点击“更改选项”链接来修改。 就像我以前做的一样… 就这么简单,现在你就拥有一个欧洲账户了!你也可以通过Azure门户或在Azure门户预览版中的VS Online账户创建流来选择你的地区。 让我们再深入了解一些深入并棘手的问题,这时你可能会问… 整个账户绑定到一个地区 – 你不可能在这一个地区拥有一些数据,同时又在其他地区拥有另一些数据。如果想让你的项目在不同地区,那么当前你不得不让它们处于不同的账户,这也是我们将来要改善的地方。 你可以到账户设置里去验证你的账户在哪个地区。 目前还没有办法把账户从一个地区移到另一个地区。在下一个版本中我们将会实现这一选项,但需要几个月时间。在非常紧急的情况下,我们可以手动帮你实现。如果你迫切需要的话,请联系支持人员。但由于这还是一个手动过程,所以我们不会移动大量账户。而且我们将告知用户可能等的时间会有点长。 尽管我们已经在美国以外的非英语地区有了第一个实例,但我们还没有支持VS Online本地化体验。你可以用任何语言作为输入数据,但是VS Online的UI当前只显示英语。这是我们期待明年能解决的一个事情。 当你在一个地区中查找账户时。所有的“账户数据”被限制在该区域,并且不能离开。有一些数据并不受限于地区:我们的客户目录、用户目录信息和一些诊断操作数据,这类数据是“全球数据”,它们并不限于所选的区域。但你的源代码,工作项目,生成文件等等都只存在于所选的区域。 截止现在,西欧地区的服务有 – 源代码控制(TFVC和Git)、工作项目跟踪/项目管理、团队房间、构建自动化、测试用例管理和负载测试。Application Insights(目前还在预览阶段)在欧洲版还不可用,计划在下个阶段GA中实现。为你的VS Online账户自动选择一个位置,并且选择该地区所有可用的服务。因此在实例中,创建一个西欧账户会自动使你使用西欧中的自动生成服务。目前尚没有办法选择基础服务的地区。 我们计划添加世界上更多的地区。然而也没有一个明确的蓝图,因为它将完全取决于需求。我们有大量欧洲实例的需求,也有所有其他较远的需求。如果你想看到其他地区的实例,请让我们知道。也可使用 http://visualstudio.uservoice.com把你的建议让别人看到。如果有足够的需求,我们可以在几周内就创建一个实例。 Brian


回顾VS Online八月十四日的故障

[原文发表地址] Retrospective on the Aug 14th VS Online outage [原文发表时间] 8-22-2014 11:10 AM 上周四我们有一个很严重的故障持续了5个多小时。故障表现为性能极其的糟糕,以至于这个服务对于大多数人来说基本是不可用的(尽管采取了各种各样的缓解措施也只能断断续续的访问)。故障开始于UTC时间14:00,结束于UTC时间19:30前。从故障的持续时间和严重程度上来说,这是VS Online有史以来最严重的一次事故。 为此我们感到非常糟糕,我们也将继续致力于做好每一件我们能做的事以防止故障。我很抱歉此次故障所造成的问题。整个团队从周四到周日不知疲倦地工作来解决眼前的健康问题并且修复潜在的可能导致复发的缺陷。 正如你可能想到的,在过去的一周,我们非常努力的工作试图了解发生了什么以及我们做什么更改才能防止这样的事情再次发生。要想找到触发故障的确切证据往往是十分难的,但是你可以通过仔细的研究来学习更多的东西。 关于这一类的故障,我经常问一些问题,包括: 发生了什么? 实际情况是,一个核心SPS(共享平台服务)数据库不堪数据库更新的重负,并且开始严重排队所以阻止了调用者。由于SPS是身份认证和授权过程的一部分,所以我们不能只是完全忽视它 – 虽然我建议当它变得非常缓慢的时候可以那样做,即使我们绕过一些授权检查以保证服务的及时响应,这也并不意味着就是世界末日。 触发器是什么?什么使它在今天发生了而不是昨天也不是其他任何一天? 虽然我们已经很努力的在解决这个问题了,但是仍然没有任何明确的答案(不过我们仍在继续)。我们知道,事发前,一些配置的更改导致“TFS”服务和“SPS”(共享平台服务)之间的通信量显著增加。这些通信量包括对已禁用的附加许可证的检测。我们也知道,大约在同一时间,我们看到了延迟的和未能交付的服务总线消息。我们相信其中一个或者两个就是关键触发因素,但是我们丢失了一些SPS数据库访问的日志,因此没办法100%确定。希望在接下来的几天里,我们会知道更多。 “根源”是什么? 在某种意义上讲它不同于触发器,触发器通常是一个导致一些连锁效应的条件。而根本原因更多的是理解为什么会级联以及为什么会把系统搞垮。我相信事实会证明,根本原因就是我们已经累积了一系列错误,才导致SPS数据库有很多额外的工作要做,同时系统也不稳定 – 从性能的角度来看。仅仅在系统上做几个操作 – 以额外的身份认证和许可证发放形式导致这些错误的连锁反应。其中大多数是在最近几次的Sprints引进的。下面是到目前为止我们发现并修复的核心错误列表: 大量从TFS到SPS的请求引起对“TFS服务”身份特性的不当更新。这将引起SQL写争论,同时无效的身份通过服务总线消息从SPS发送到TFS。此消息引起应用层缓存无效,随后的TFS请求就会发送一个请求到SPS,造成进一步的属性更新和一个恶性循环。 401中的错误处理代码将会对身份进行更新,这将导致身份的缓存无效-没有恶性的循环但是有许多额外的缓存刷新。 Azure门户扩展服务里的一个错误每5秒就会触发一个401错误。 一个旧的行为从每个SPS AT引起同样的无效“事件”(用户1在AT1无效,用户2在AT2无效,那么用户1将收到两次失效)。我们有四个AT,所以这将有一个很严重的乘法效应。 我们还找到/修复了几个“加重的”错误,它们使得形势更加恶化,但不会坏到对它们自身引起严重的问题: 许多易变的属性也被存储在身份的扩展属性中,这会造成重复的缓存失效,大量的“更改推送通知”将被发送给不在乎属性更改的监听器。 有几个地方即使没有更改也会更新属性,如此便会造成没必要的失效和SQL旅程。 所有的这些,在某种形式下都随着对系统身份的更改而改变,这将会导致广播更改推送通知(有些情况下会过分传播),同时引起额外的进程/更新/缓存失效。这是不稳定的,因为这些身份更新中任何导致不期望的负载增长的东西,都会由于乘法效应和循环而无法控制。 从此次事件中我们学到了什么? 我一直想超越并理解底层模式。有时候也被称为“5个为什么”。事实上这也是列表中最重要的问题。为什么会发生这件事,我们能做些什么?而不是我们遇到了什么错误。为什么会出现这些错误?我们应该怎么做,以确保进入生产环境前,在设计/开发过程中就抓到这些问题? 先给大家讲个故事吧。这得从2008年说起,那时候我们首次将TFS横跨Microsoft的非常大的团队进行试运行,我们曾遇到一个灾难性事件。我们极度低估了成千上万的用户和大规模构建实验室将被放到TFS上这一负载。有将近九个月的时间我们如同活在地狱中一样,在严重的性能问题下,系统每天都在痛苦地减速,许多人给我发送厌恶的邮件。 从中我最大的收获就是,你绝对不能相信抽象概念里说的何时会遇到性能问题。在那种情况下,我们将SQL Server作为了一个关系数据库。最后我才知道真的不是这样的。它只是一个在磁盘I/O之上的软件抽象层。如果你不知道在磁盘I/O层发生了什么,你就什么也不会知道。你的无知也许是幸福的-但是当你遇到10x或者100x规模/性能需求的时候,你将完全精疲力尽。我们开始深深研究SQL磁盘布局,主要寻求,数据密度,查询计划等等。我们由上到下流动优化,确保我们能够了解所有CPU和 I/O的走向等。当我们做到这些时,TFS将扩到无比大的团队和代码库。 之后我们会做回归测试,这样会衡量更改,不仅仅及时而且是围绕着SQL旅程等等。 回到上周四…是我们草率了。这次马虎可能太严重了。对所有的团队来说,我们陷入了是自食苦果还是按客户需求增加功能的两难境地。在推动快节奏的过程中,估价每个Sprint等,我们允许了一些工程回归然后衰退-或者更确切地说,就是不把它带到我们正在写的新的代码中。我相信这是根本原因 – 开发者不能完全理解他们所做的一个更改的开销/影响,因为我们在跨软件/抽象层没有充分的可见性,而且当代码更改触发操作在整个资源耗费操作中显著增加时,我们也没有自动化的回归测试来标记。当然,你也可以在人工的测试环境中做这个,例如单元测试,也可以在生产环境中做,因为在你的测试中你抓不到任何东西。 所以,我们已经修了一些错误,在TFS和SPS交互方面还有不少的债务要进行处理,更重要的是我们需要加入一些基础建设,以便更好的在端到端开销上衡量和标记更改 – 在测试和生产中都可以。 讽刺(不是喜剧而是悲剧)的是最近团队才在这一点上有一些重新关注。几周之前,我们刚为小范围的团队人员准备了“编程马拉松”来试验新的想法。其中一个团队构建了一个解决方案的原型,用来捕获一个端到端请求的重要性能跟踪信息。在接下来的两周,我会试着写一篇博客来展示其中的一些想法。在此次事件前的那一周Buck(我们的开发总监)和我关于这个特殊的场景是否需要更多的投入曾进行过一次谈话。不幸的是我们还没有解决这个差距呢就发生了这个严重的事件。 我们将要做什么? 好的,我们学到了很多,但是关于此事我们到底要做什么呢。显然第一步是平息突发事件,让系统快速的回到可持续的健康状态。我想现在我们可以做到了。但是我们还没有解决根本原因。所以,下面是我们所做的计划,包括:…


Connect();峰会中的新闻

[原文发表地址] News from Connect(); [原文发表时间] 2014/11/12 7:30AM 这周,在New York,我们举办了“Connect();”开发者峰会。我们也做了大量的宣传工作。你可以在 Soma的博客,Visual Studio 相关博客和Visual studio ALM 博客以及release notes中得到相关connect()的信息 我们主要宣布了:  Visual Studio和Team Foundation Server 2013 Update 4可以用了。Release notes… Visual studio 2015 和和.NET2015的第一个预览版可以用了。Release notes… .Net 框架即将实现开源和跨平台 可供免费使用的的visual studio Community 2013,—— 一种新版本的 Visual Studio,组合所有速成版和添加可扩展性支 Visual Studio online 的一些新的改进。 我也预先展示了一些在不久之后会被添加到VS Online 和TFS的一些新功能。 今天,我们没有发布TFS 2015 的预览版。不是因为我们没有在TFS 2015上工作 ,而是因为我们发现,把这些功能嵌入到VS Online 中是目前为止为您提供TFS新功能的最快的方法,也是你们给我们提供反馈以便我们修改我们的开发计划的最快的方法。几个月后,我们会发布一个TFS2015的预览。 像往常一样,我将更多关注ALM相关信息,其他人则关注于更广泛的Visual studio…


Visual Studio Online 更新—9月23日

[原文地址] Visual Studio Online Update – Sept 23th [原文时间] 2014/9/23 这周我们即将结束VS Online 的第71个迭代。你可以从新闻页面中了解到更多关于产品的变化。在过去,随着软件的部署,我们挣扎于如何选择时机出版发布说明。但是随时我们拥有越来越多的实例(我们现在有 4个,并且将很快会有第 5 个),为每一个实例选择正确的时机变得越来越难。在刚刚启动这一迭代的时候,我们便计划在第一个公共实例升级开始的同时出版发布说明。这意味着发布说明将始终比功能的真正实现要超前一点点,但是最多超前几天(能阅读到的人并不多)。 我也想评论新闻帖子中提到的一件事: 工作项性能。 我在上一个迭代中提到,我们将一些规模更大的内部团队带入了TFS/VS Online的研发中,在这过程中,我们碰到一些性能 (和可用性) 的问题。针对这类问题,我们在这个迭代中取得的进展比上一个迭代还要多。 样例: 工作项窗体的加载— — 假设一个团队有一大堆相当大工作项窗体。我不推荐这种做法,但我会通过引导的方式来使不同的团队拥有不能级别的复杂程度。当他们在TFS上遇到超大且内容超多的窗口时,平均要花上2.8秒去打开—简直是龟速。对此我们做了优化,其中包括不事先构建隐藏字段的DOM。经过优化之后,我们将这段时间减少到了0.8秒。。对于结构简单的窗体,这样的优化显得没那么明显,但是所有的窗体加到一起就能够明显感觉到速度变快。 共享工作项查询— — 与上一个样例类似, 这个团队拥有大量共享查询。事实上,他们在几个月之内构建了数以千计的共享查询,这些查询结果的加载较慢。每一次导航到查询页面时都需要10.5秒去显示查询结构。使用渐进式显示的方法,我们把这段时间减少到了0.3秒。无独有偶,不是所有人都能看见引人注目的变化,但是每个人都能感受到一些改善 我们正在为下一个 迭代添加更多的方案 — — 例如点击邮件中的链接去打开工作项窗体需要花费几秒钟,我们在第72个迭代中将使它大大地加快。 所有的这些变化也将列入 TFS 2013 Update 4。 期待几周后更多的分享 — — 我们将在第72个迭代中部署大量内容。敬请期待 Brian


Visual Studio Online 更新-9月4日

[原文发表地址] Visual Studio Online Update – Sept 4th [原文发表时间] 2014/9/4 最近,我们已经开始把微软的一些较大团队带入VS Oline。因为他们有很多启发性的经验。特别是适应并解决高带宽的问题(如 bug 会审、 性能和更大数据集的规模问题等)。 现在我们正在部署sprint 70,并且已经发布了基于我们学到内容的大量的小型改进。我认为这种模式将在下几个阶段中一直继续,并让每个改进都集成到到VS Oline的日常使用中。 * * 重要 * * 此部署为期周末两天,因此很多帐户在 9 月 8 日星期一之前,将不会看到所有的改进。 通过Aaron的新帖子,你可以了解更多特殊的改进: http://visualstudio.com/en-us/news/2014-sep-4-vso. 我们新的开放性web 扩展模型也是此次冲刺(发行说明中也有描述)的很大一部分。跟踪工作项的REST API改进是最有意义的改进,但最酷的是增加了对Hubot的支持。 一如既往地,让我们知道你的想法。 Brian