你可以增加多少数据到Visual Studio Online中?

[原文发表地址] How much data can you put on VSOnline? [原文发表时间] 2013-11-20 5:53 AM 我不经常问那个问题,但是会偶尔问,为了使服务更成熟,我知道我将会问越来越多次那个问题,因此它一直存在于我脑海中。昨天我看了一些关于我们 某些最大的客户的数据。是的,我看不到他们的IP(我不能)但是我看了一些元数据来了解使用情况,所以随着客户的增长,我们可以提前规划确保我们的服务依然能够提供良好的用户体验。 到目前为止,没有客户在VSOnline中存储多少数据方面受到任何地限制,但是限制是存在的,我一直在想如何帮助人们了解这种限制是什么,从而使得他们可以在自己的规划中考虑到这一点。为了这次话题的目的,这次话题列举了以下两种你们主要使用的存储方式: 1) 大型二进制对象存储–它反映的是那些被存储在服务器上的文件,附件等的大小。为了缩小这些文件的大小,因此这些文件是被压缩的。大型二进制对象存储就是为了使得所有目的不受到限制(即使我们可以时不时的强制限制以防止滥用)。合法的使用基本上不会受到限制。 2) 元数据存储–元数据(版本控制版本信息,工作项记录,测试执行结果等等)被存储在一个叫做SQL Azure的数据库中。现今SQL Azure数据库的最大容量是150GB。那在我们现今生活中是硬性限制。SQL Azure有一个关于增加存储容量的计划,并且我们经常给他们提供压缩工作的支持(我们的数据压缩的特别好)因此我认为最近它在任何时间任何人身上不会变成一个大问题,但是这个问题我会一直记得。 因此一直困扰着我的问题是如何回答“有多少数据可以存储到VSOnline中?”以前没有人清楚150GB元数据限制的意义。所以我倾向于思考人们最容易理解的,150GB的大小是指他们的相关源代码/文档/附件和最终会有的其他工作的大小。当然使用方法可以改变,跟别人相比,你可能会有大量的工作项或者测试结果,但是这是目前我所能想出的最佳的衡量方法。 所以当我昨天看到那些数据的时候,以下是迄今为止我能发现的关于我们最大用户的数据: 260GB 压缩大型二进制对象存储–我常常评估3X压缩比(变化取决于你查看了多少源vs 二进制数据,但是平均值是很接近的)。因此那相当于是780GB没有压缩的数据。 11GB元数据–那么,这使得它们约7%的方式来限制占大部分空间的元数据的大小。 所以如果在达到元数据最大限制之前,我可以推断出它们可以存储多少数据,我得到:150GB/11GB * 780GB = 10.5TB。多么理想的数字!拥有那么多开发数据需要存储的机构不多。 因此,在我心中的另外一个问题是跨用户间的二进制数据与元数据比是否一致。换句话说,是否每个人在里面都可以获得如此多的数据或者使用方法的不同导致结果有显著差异。我想你们猜想的答案是正确的,它们确实具有显著差异。我看了许多其他大用户的数据,发现了在5和23之间比率是不同的(结果显示用户越大比率越大)。因此如果我用最保守的数字做同样的推断得到的是2.2TB。 所以现在,我所能说的根据使用方法你可在2.2TB 和10.5TB之间存储。不管怎么说有大量数据可以存储,没有人接近极限。 今天的一点随想,但是我想你可能会好奇。


TFS Git 支持可持续地传送到Azure的Web站点上或Web服务上

[原文发表地址] TFS Git support for Continuous Delivery to Azure Web Sites and Services [原文发表时间] 2013-11-07 一年多以前,我们推出了一个从TFS 到 Azure间可持续传送的功能,利用这个功能你可以去配置TFS构建通道,从而可以自动部署正在运行的Azure应用程序。在这段时间中,我们将Git支持添加到了TFS中。但是将Git集成到所有情形是一个漫长的过程。这周我们迈出这个过程的一小步:实现从TFS Git到Azure的连续传送。 Scott他的博客上,写了一篇关于这种情形的很好的概述,与本文并不重复,我推荐给大家。大约从这篇文章的一半处开始介绍相关内容。 http://weblogs.asp.net/scottgu/archive/2013/11/04/windows-azure-import-export-hard-drives-vm-acls-web-sockets-remote-debugging-continuous-delivery-new-relic-billing-alerts-and-more.aspx 检查出来,并一如既往地鼓励反馈。 Brian


Team Foundation Service更新 ——11月8日

[原文发表地址] Team Foundation Service Update – Nov 8 [原文发表时间] 2013-11-08 由于我们下周将要做一个大的产品启动,所以我们用sprint56中的部署计划更新了TFService, 比预期稍有提前。今天我们部署了几个不错的改进 – 使图表功能可以更容易地分享,同时改善了负载测试服务。在发行说明中,你可以看到更多的改变。 下周将是重要的一周。我要去纽约参加VS/ TFS2013的启动仪式。作为其中的一部分,我将制作很多公告,并使TFService的一系列新的功能可用。您可以登录http://events.visualstudio.com在线参与,也可以通过新闻页面了解。 我期待着一个令人兴奋的一周。 Brian


Team Explorer Everywhere 2013可以使用了

在今年10月份发布的Visual Studio2013中,我们在Visual Studio 2013也嵌入了Team Explorer Everywhere—在2013版中,提高团队成员在Eclipse中和/或在非Windows环境的工作经验,Team Explorer Everywhere包括一个Eclipse插件,一个跨平台的命令行客户端,和一个构建自定义工具来访问TFS的Java SDK。 除了修复了一些bug,2013版的发布显著提高了Team Explorer经验,并向Team Foundation版本控制和Git版本控制经验增加了新的功能。 您可以从下载中心下载Team Explorer Everywhere 2013,或者直接通过Eclipse IDE 为Eclipse安装TFS插件。更新站点的的网址:http://dl.microsoft.com/eclipse/tfs。如果您安装或使用任何TEE组件遇到任何问题,,访问Eclipse和跨平台工具论坛。 2013版的一些亮点: 改进的Team Explorer(具有可停靠视图的特性) 在2013的发布版中,在TEE中的Team Explorer视图特性大大的提高了。Visual Studio的Team Explorer视图匹配大为改善。TEE同时也借鉴了添加在Visual Studio里的一些好用的组织和导航功能 。提供快速访问最常用的功能这一新特性,当你右键点击某一个区块,就会出现实现快速访问的菜单了。例如,右键点击“生成”的区域可以很容易浏览已经完成或正在排队等待生成的项目工程。我们还增加了一些你可以访问Web门户网站地方,当你需要访问一个只在网站上可用的一个功能时,这个将会大大节省时间。   停靠视图的功能也被加入。现在,您可以取消停靠挂起的更改和生成的视图,,并且可以将其放置工作台窗口内的任何地方。所有的视图也会在“窗口”>“显示视图”下面显示,这使得将这些视图添加到另一个透视图成为可能。例如,你可以在Java透视图显示挂起的更改,并可以快速访问、查看和检查挂起的更改。 源代码资源管理器中的搜索功能 源代码管理器寻找功能,以前是嵌入在Power Tools中的功能,现在已经完全集成到TEE产品当中。这个功能能够使用户在源代码资源管理中通过过滤名字,路径或签出状态迅速查找文件或文件夹。这样更容易找到被任何用户甚至特殊用户挂签出或者某一路径下的文件。一旦查询结果返回后,你可以将这个文件签出并进行编辑,撤销挂起,查看历史,查看属性,或者在源代码资源管理器中打开,或者复制文件的完整路径到剪贴板中。 注意: 当进行搜索时, 只有显示签出状态的复选框被选中的情况下,搜索出的结果视图里签出状态和签出代码编辑的功能里才是可用的。   源代码资源管理器的添加功能 在TEE2013的发布版中,我们显著提高了把文件加到TF源代码资源管理器的经验。UI窗口不在是以前那样的对话形式,而是被重建成一个多页的向导界面。新的向导有几个很大的改进包括支持把符号链接添加到源代码资源管理器,当文件被添加在非映射的源代码资源管理的文件夹下面面是时可以直接创建工作区映射,自动过滤掉在源代码控制器中的本地文件,从工作映射区之外的本地文件夹中导入文件。 符号链接 随着2013的发布,TEE开始支持基于Linux操作系统的符号链接。就像普通的文件一样,符号链接也可以被添加到源代码资源管理器,也可以被更改(如添加,编辑,删除)可以检测,挂起,并随后更新源代码管理器。当使用符号链接(查看历史,合并,分支)或者从版本控制窗口下载符号链接时,开发者有足够的版本控制权限,他们被创建为文件系统中的符号链接。 Git资料库中导入项目 为了更容易地使用TFS上的GIT资料库中的托管代码开始工作,2013版的TEE中包含一个复制和导入项目到工作目录的向导。此向导增强了由Eclipse EGIT工具提供的基本导入向导,提供了一次性复制多个资料库(可用于代码分布在多个存储库的大型项目中)的功能。对于Team foundation server 上托管的资料库,此向导将引导您安装替代的证书,因为EGIT工具不再像TEE一样支持联合身份验证。一旦这些替代证书安装并存储在Eclipse 安全存储中(向导会自动存储),你在使用EGit Tools的时候,便不会提示你需要重新提供证书,该向导执行以下操作: 1. 从TFS中克隆一个或者多个GIT资料库到你的本地工作目录。 2。检查并导入这些克隆的资料库中的Eclipse项目。 3. 在EGit中设置到克隆的资料库的链接。 集成Eclipse Egit工具…


你如何衡量服务质量?

[原文发表地址] How do you measure quality of a service? [原文发表时间] 2013-10-14 自从几年前我们开始走上在线开发的道路后,我已经了解了很多。在众多我已经了解的事情里,其一是衡量服务的健康状况。我不妄想对于问题只有唯一的解决方法,所以我很高兴借鉴任何人的不同意见。 这篇文章的目的,在于我将 “服务质量” 定义为服务的可用性和响应的程度。 问题 解决这种问题的“传统方法”被称作“合成事务处理”。在此方法中你创建一个“测试代理”每隔N分钟就发送一些请求到你的服务器,一遍一遍的重复这个操作,直到失败的响应都指向一个问题并且时间窗口被标记为“失败”。然后你计算失败的时间间隔数目并在随后的窗口中除以间隔的总数,例如,让我们将30天定为你的可用性度量。 那么这样做有什么问题呢?我先讲一个故事。。。 当我们第一次推出团队资源管理器时,我们有许多关于SQL Azure的问题。我们是第一次正式在SQL Azure上开发高规模,互动式的服务。在过程中,发现了很多问题(现在已经好了很多,如果你关注这个问题)。但是,在我们推出服务的三到四个月后,我正在雷德蒙德与SQL Azure团队的许多领导者一起就怎样解决使我们头疼的SQL Azure问题进行讨论,我需要了解他们快速解决问题的方案。 当我在他们的地板上通过中央走廊的的时候,我注意到他们有一个服务仪表盘正在滚动显示一组live状态服务的数据。顺便说一句,这是一个很普遍的方法(我们也用过)。它是一种很好的方法来给团队强调在服务业务中“live-site”是最重要的事情。我停了几分钟只是看着滚动屏幕上显示的他们的服务。所有的服务都是绿色的。事实上,看着仪表盘你根本不知道有任何的问题——可用性是好的,性能是好的等等。但作为服务的一个用户,我可以向你保证实际上没有任何的性能是绿色的。我很失望因为我参加了一个有着有趣开始的会议。 第二次,是在每个人说“布莱恩说,SQL Azure 糟透了”之前。我说的是在两年前,对我们来说它还有些非常重要的可靠性问题 。虽然现在不是很完美,但是它工作很稳定,而且说实话我不确定没有它我们是否可以更轻松的做我们的服务。它提供的高规摸弹性数据库是真正梦幻般的。 那为什么会出现这种情况呢?为什么运行服务的人在健康服务方面和使用服务的人有不同的看法?好吧,这有很多答案,但是其中一些取决于你如何衡量和评估服务的健康状况。 经常测量一项服务的健康状况并不能反映用户实际上拥有的经验。我以上所描述的“传统”模型可以说明这个理论。当你运行综合事务时,你通常需要运行他们的服务端点的某个子集,针对一些数据的子集。此外,虽然很容易行使“读”的路径,但是“写”的路径却很棘手,因为你通常不想更改数据。为了解决这个问题,在TFService的早期版本中,我们设置了一些相似的集成事务处理记录,例如能够登录,请求几个web页面,阅读某些工作项等等。这一切都发生在我们服务提供团队创建的测试帐号中(因为我们显然不能和用户帐号混在一起)。从理论上讲任何一位客户都可以关闭我们的系统而我们的集成事务处理仍能正常工作。 依我的愚见这是这种方法的根本问题。你的集成事务处理仅仅只运行小的数据子集(尤其在一个独立的多用户系统)和小的端点子集,遗留了很多会错过客户实际上拥有的经验的途径。 我见过的另一个错误是总是在聚集视图中评价服务。你可能会说我的请求有99%是成功的并且你认为这个数据是ok的。但是如果所有的错误都集中在一小部分客户上,他们会放弃你。然后会是下一组等等。所以你不能让你的眼睛太模糊。你要了解每个客户发生了什么。 一个解决方案 好吧,对于这个问题的讨论足够了,让我们开启讨论解决方案的旅程。 我从开始就学会了的一个大的经验就是我希望我们最主要的可用性测量是基于真实的客户经验而不是综合事务(我们仍在使用综合事务,而且以后会更多)。幸运的是,多年来,TFS拥有了我们称为“活动日志记录”的功能。它记录了任何发送给系统的请求,谁创建了它,什么时候接收的,它用了多长时间,它是否成功等等。这对于理解和诊断TFS的问题是非常有价值的。 我学到的另一个经验是“可用性”衡量,如果你想要的是一份有意义的同时包含可靠性和性能的用户经验。只是统计失败的请求数,这会留下一个巨大的差距。如果你的用户必须要等待很长的时间,系统在一点响应也没有的时候只会是不可用状态。 最后,任何可用性检测应该反映总体系统的健康状况而不仅仅是给定组件的健康状况。你也许会感觉一个组件运行良好,但是如果用户需要同时和3个组件互动来做某些事情,只要它们中的一个有问题就会导致用户操作失败。 我们的第一次可用性度量是统计在可用性日志中的请求数。公式是可用性=(总请求数-失败的请求数-响应慢的请求数)/总请求数。在很长一段时间里,这个公式对我们很有用。它很好的反映了我们工作中的各种不稳定情况。它基于真正的用户经验并且同时包含了可靠性和性能。此外我们也对外进行综合事务的监督,顺便说一句,这不是我们首要的可用性度量。 在过去的6个月左右的时间里,我们发现从我们相信实际的服务经验的重要性开始这项措施日益分歧。它被规划成一个比现实更乐观的画面。为什么呢?有很多原因。我认为的主要现象是“更改行为”。如果你获取到一个失败的请求,因为各种原因,你可能不想再发送其他的请求。例如:如果你尝试去开始一个build并且它失败了,将导致所有它生成的请求永远都不会发生也没有机会失败。其结果是,如果用户实际上已经能够取得进展、,你可能会低估失败的请求总数。当然,如果系统不能工作,你的用户不会仅仅靠墙坐下敲着脑袋,他们会一起去吃午饭。在这个例子中,如果没有人使用系统,可能性就是100%(我们会,好吧,实际上就是未定义的分母是0,你明白了吧) 我们已经花费了过去的几个月时间在一个新的可用性模型上。我们尝试了几十次并且模拟了我们所有的数据来检测我们是否恰当的反应了“真正的用户体验”。在最后,都不重要了。 数据仍然衡量了在活动日志中代表的真实用户请求的成功与失败情况。但是计算过程是很不一样的。我们试图增加的一个约束是我们希望它既可以适用于个人用户去衡量自己的经验也可以适用于所有的用户的聚合。当我们进入需要为SLA违规行为提供补偿的业务时,这最终是很有价值的。 首先,像传统的监测,我们已经介绍了每一次失败的“时间罚款”。也就是说,如果我们得到一个失败就意味着我们标记整体时间间隔为失败。这是为了对付我在上面描述的“修改行为”的现象。它把分子从请求数改变为一个时间段。我们同样需要把分母改变为一个时间段来使这个公式成立。我们原本只是用客户或用户乘以在一个月中的时间间隔,但是那确实影响可用性曲线。相反,我们期望分母反映实际尝试使用服务的人的数量以及他们尝试持续的时间。要做到这一点,我们定义了一个汇总期。任何在汇总期使用服务的人都会被统计为分母的一部分。所以,让我们看看公式。 用英语描述,过程是这样的: 对于每一个在5分钟汇总期内使用服务的用户,统计他们每分钟内经历的失败数(失败的请求或者速度慢的请求)。把在1分钟内所有使用服务用户的故障数加起来。用5分钟汇总期内使用服务的客户数乘以5分钟后的值来减去它。这样你就获得了在5分钟汇总期内的“成功客户时间”数。除以总客户时间(在5分钟汇总期内使用服务的客户数乘以5分钟),之后给予你一个客户成功率a%。在窗口中求所有的5分钟汇总期的平均数(在24小时里有288次)来得到可用性a%。 我们仍然在调整1分钟间隔,5分钟汇总期,10秒perf阈值的值。 在我们试过的所有模型中,这个模型提供了一个合理直观的,恰当反映真实用户问题(没有激进)的结果,并且更贴近我们认为的客户实际看到的经验。它基于真实的客户体验而不是人工合成,它会捕获系统中的任何用户体验的每一个单一问题。为了形象化展示区别,请看下图。橙色线是旧的可用性模型。蓝色线是新模型的结果。你所看到的是一个24小时可用性数值图。当我们把它变成一个30天的SLA运算平均值,它会减弱的稍多一点。 有一句谚语:“谎言,该死的谎言和数据统计”。我可以手工制作一个可以满足我任何需求的可用性模型。我可以让它看起来很好或很坏。当然,那些都不是目的。你想要的是一个可以告诉你你的用户体验的可用性数据。当你的用户不满意的时候你期望它是坏的。当你的用户满意的时候,你期望它是好的。 这是所有你需要的吗? 总的来说,我发现除了一些缺失外这个模型工作的很好。问题是无论你在哪里测量,总不能避免会有失败。在我们的案例中,当请求到达我们的服务时,活动日志会被收集。在IIS传输时,在云网络中时,在云负载平衡时,在ISP中时,等等,它都可能会失败。在这里我们会人工汇总事务,因为你主要只是测试一个请求是否可以到达你的系统。我们利用我们的全球服务监控服务将终端放置在世界各地并每隔几分钟进行一次事务汇总。对于如何将这些数据融入到我们的可用性模型中,我们 有些想法,但是在几个月内可能不会这样做(此刻这不是我们最主要的问题)。 当我刚开始进入这个领域时,云业务负责人告诉我——在外面的监控(什么GSM,主题演讲,Gomez等等)仅仅衡量了互联网和“生产测试中”的可用性。——在你自己的数据中心中进行测试,衡量的是你自己的应用程序的健康状况。我认为这是很有见地的。我认为你仍然需要去做但更重要的是要想想它在你的整体健康评估战略中所扮演的角色。 关于SLA的一个字 我不能遗漏SLA(服务水平协议),即使这个可笑的长帖子没有一个字是关于它的。SLA通常定义客户可以对你的服务所期望的最低水平。我见过这种现象发生在团队中,当团队定义了SLA后,那定义变成了目标。如果我们在SLA中承诺99.9%的可用性,那么目标就变成了99.9%的可用性。我怀疑我的团队和其他人已经很多次听到我抱怨这种情况了。SLA不是目标!SLA是你不得不把钱还给客户前你要达到的最低标准。目标是100%的可用性(或之类的)。 当然,所有这些都是折衷方案。为了获取最后0.0001%的可用性你需要做多少事情以及相同时间内你可以提供多少很棒的新功能来代替。所以,我从来不会要求我的团队做任何事都不能有一点失败。但是我们会调查每一次失败,我们学习并且了解我们能做些什么来防止它,评估成本效益,了解问题以及解决方案。眼下,我努力推动我们定期地朝着99.99%可用性的目标前进(就是期望在一个月中停机时间少于4.32分钟)。 对不起写了这么长。希望它至少对某些人是有用的…


Visual Studio中的Team Rooms特性

[原文发表地址] Team Rooms in Visual Studio [原文发表时间]2013-10-26 6:12 AM 在TFS 2013中我们提出了一种名叫“Team Rooms”的新特性,这一特性可以记录下团队提交代码,更新工作项,生成失败,代码审查等过程中所发生的事情。你也可以在Team Rooms中直接进行关于此活动的会话。这一纪录能够将团队所发生的事情持久地保留并且便于团队内外出人员的跟进或者是提出问题。 在2013年,Team Rooms仅仅只出现在TFS Web UI层面上。我们从预览它的那天起,就开始搜集关于在Visual Studio中启用team rooms出现的问题。遗憾的是,我们没有时间在TFS 2013中实现。然而,我们微软专家组中的一员主动承担起利用我们的REST架构的API接口建立起一个VS的扩展。 虽然它仍处于预览阶段,但是我已经使用了它的一些功能而且看起来很好。你可以在此链接上http://visualstudiogallery.msdn.microsoft.com/c1bf5e4f-5436-465d-87da-09b2f15ff061上找到它。它将在办公内部部署的团队基础服务器和团队基础服务上发挥作用。 Brian


更新Team Foundation Service – 10月21日

[原文发表地址] Team Foundation Service Update – Oct 21 [原文发表时间] 2013-10-22 4:21 PM 如果你昨天查看了新闻帖子,你会发现在sprint的部署上对工程和账户主页有大的改变。老实说,账户主页大多数是无用的而且不美观。更新中我们关注的一个大的方面是提高入门体验。我们做的一个改变是增加了一个新的“创建你的第一个工程”面板在账户主页(你创建一个账户后直接登陆的地方)来试着使下一步要做的有用的事情看起来比较清楚。 在你创建了一个工程之后,“创建你的第一个工程”的面板会消失并且你会看到新的账户主页,其中一系列图块(它们是可以取消的)来提供关于入门经验的附加信息。 在取消它之后,你会看到这个。我已经缩小了这个截屏中的浏览器来强调我们所进行的另一项工作。在这两个主页上我们已经开始实现当改变浏览器的大小时改变相应的UI也会改变它的布局。你将会注意到这是一个2栏布局而不是一个3栏布局。我们没有重点解决手机形式的因素但是我们期待这个UI在平板形式之上也能够有效工作。我们同时也已经着手提高我们的触摸体验,不过你应该期待这是我们将要不断发展的一个方向。 查看工程主页了解更多的事情,你可以阅读Aaron的新闻帖子。 愿你喜欢! Brian  


Visual Studio 2013 RTM 版可用了

[原文发表地址] Visual Studio 2013 RTM Available [原文发表时间] 2013-10-17 今天早上凌晨,我们取得了Visual Studio 2013, Team Foundation Server 2013和.NET 4.51的最后版本。您可以下载试验版和相关产品,而且MSDN订阅者可以从用户门户下载产品的许可。您可以了解更多关于what’s new in VS 2013 here。 今天Windows 8.1的也可用了。从商城可以快速轻易的去升级。 我们将主办在11月13日Visual Studio2013的启动仪式。在启动仪式上,我们会强调Visual Studio 2013的新特性和功能的广度和深度。 获得VS 2013是很容易的。如果你有一个激活的MSDN订阅,那么你已经拥有了它。如果你不这样做,你也可以用99美元的认购价格,在有限的时间里来升级你的VS。检查购买选项: http://www.microsoft.com/visualstudio/eng/buy VS 2013可以和之前版本的Visual Studio同时安装,或者,如果你有一个VS 2013的预发布版,它可以安装在预发布版本之上。 TFS 2013不能和之前版本同时安装,但也可以覆盖以前的版本( TFS 2012或TFS 2010 )或预发布之上。 我们正努力执行计划的工作,所以我们期待在未来几个月中听到更多在VS / TFS 2013.1上的提高。 Brian


在CodePlex上托管GPLv3 项目

[原文发表地址]Hosting GPLv3 Projects on CodePlex [原文发表时间]2013-10-03 12:00 PM 我最近很少在这里讨论关于CodePlex的一些更新和改变。针对它的每一次发布更新,我不会每次都发博客,否则我得每周更新这个网站, 但是今天我们做了一个针对CodePlex的更新,我认为这个更新值得 在这里提一提– GPLv3证书已经被添加到可用的开源证书列表里面了,这些证书是当我们在CodePlex上面创建一个新的开源项目的时候需要的。 在CodePlex上面发布一个项目之前,我们一直以来都要求客户指定你需要什么样的证书去发布你的源文件代码。当你想发布你的代码到网络上而且你希望你的代码通过你提供的的证书能够自由的被大家使用,这时,指定证书是非常重要的。客户需要做的只是把代码放在上面而不是真的使它成为开源http://opensource.org/osd. 我们想确保当大家在CodePlex上访问一个工程并且下载它的源代码时他们能够很容易的发现这些开源证书下面对应的源代码。 但是选择正确的证书可能是件伤脑筋的事情,我们不是给出每个单个可能开源证书的下拉列表,而一直都是通过给出一个包含了在社区中最受欢迎的证书的实际列表,这个列表里包括许可证书例如MIT, Apache 2.0 或者MS – PL 和像GPLv2一样的不同的公共版权证书. 最近我们的开发组重审了这些证书列表,项目所有者能够从这些证书列表中选择并且对比很多人一直以来都很想使用的证书。很清楚的是我们之前的证书列表和有些人期待的有些差距,这些开发者想把他们的项目代码发布到GPLv3下面 https://codeplex.codeplex.com/workitem/14272. 所以今天,对于在CodePlex上面新创建的项目时,GPLv3已经被添加在快速方便的证书选择器里作为可选择项之一。 我们想保证CodePlex上的项目证书尽可能的简单,这也是保持下拉证书列表短和简单的原因。但是毋庸置疑GPLv3是十分重要的,足够多的社区需要它放在证书列表里面。如果你需要的证书在我们的下拉列表中不支持,那么你可以联系CodePlex组 https://www.codeplex.com/site/contact 去请求自定义的证书。只要你的源代码是开源的他们通常都能够提供帮助。 Brian


TFS 2013 Power Tools可用了

[原文发表地址] TFS 2013 Power Tools are available [原文发表时间] 2013-09-22 抱歉让大家久等了, TFS2013 TFS 2013 Power Tools终于可用了。此版本虽然没有增添新功能,但却有很多的bug修复,并且Power Tools已经全部更新,可以与VS2013和TFS2013协同工作。同时,版本检测功能也已经更改,以便于Power Tools可以与VS2013的更新版本协同工作——所以无需等待针对每一个VS更新版本的Power Tools。当然,Power Tools也将会与VS2013 RTM版本协同工作。我们并不打算专门为了VS2013RTM版本而做Power Tools的更新,除非大家发现需要解决的重大问题。 Microsoft Visual Studio Team Foundation Server 2013 Power Tools Microsoft Visual Studio Team Foundation Server 2013 Build Extensions Microsoft Visual Studio Team Foundation Server 2013 MSSCCI Provider 32-bit Microsoft Visual Studio Team Foundation Server…