TFS注意事项.docxVIP

 HYPERLINK /n/172675/ 源代码管理 TFS（Team Foundation Server ）是一个工作流协作的引擎，它允许一个团队使用他们自定义的流程，并使用在项目历史中实时收集起来的一个集中的数据仓库。 Team Foundation Server 和 Visual Studio Team System 中其它的部分一起，组成了软件开发过程中的核心部分。s 我们的方法是唯一的，因为前端的设计有良好的可用性，而后端的设计集成了整个生命周期。我们主要关注于可用性，以及为个人和团队以一种无缝的方式进入软件开发周期。 客户关心的另外一个方面是灵活性和审核。Team Foundation Server 支持 Software Engineering Institute 的 CapaBIlity Maturity Model (CMMI) 的报表和审核的功能。通过 Team Foundation Server，组织可以自动收集必要的信息，并生成自定义的报表，它可以帮助在工业管理中定位增长点。 解决方案 另外，许多合作伙伴已经宣布他们将把他们的产品与 Team Foundation Server 的功能相结合。 · Teamprise 宣布了他们即将发布的解决方案，Teamprise Client Suite 1.0。Teamprise Client Suite 允许软件开发团队在异构的环境和其它的 HYPERLINK /view/880.htm \t _blank 操作系统中，包括 Linux 和 MAC OS X，在 EClipse Integrated Development Environment (IDE) 中使用 Team Foundation Server 的 HYPERLINK /view/60376.htm \t _blank 源代码控制和工作项目跟踪的功能。 · Ravenflow 宣布了 RAVEN ProfESsional，建立在公司的 REVEN Scenario 产品的成功之上的一个工具包。REVEN Scenario 是唯一一个可以从英文文本自动生成 HYPERLINK /view/174909.htm \t _blank 统一建模语言（UML）图的工具，它允许公司在开发开始前验证需求。 · EDS 和 Fujitsu 正在演示他们的开发方法论，并且在为他们的客户开发解决方案时扩展 Visual Studio Team System。这些都期望在 Team Foundation Server 中调节 BI 和报表的能力，并通过收集实时的数据来影响分析和计划。 若是还有可以毫无偏见地涉及各个编程语言，比源代码管理软件更必要的工具，我倒是很想见识一下。源代码管理软件是我们工作的必备工具，是许多开发团队的血液。那为什么我们都会对它??所误解呢？为什么都很难理解版本控制系统的核心价值和基本原理呢？ 　　我总结出 10 条惯例——如果你愿意也可以用“戒律”——意味着必须服从它而且从一开始很难去理解。它们与所有类型编程语言的版本控制软件都有关联。在这里我选取了 Subversion 和 .NET 的几个例子，不过它们也广泛地适用于其他的一些技术。 　　第一.如果你现在还在使用 VSS－请立刻停手 　　VSS 的全称为 Visual Source Safe 。作为 Microsoft Visual Studio 的一名成员，它主要任务就是负责项目文件的管理，几乎可以适用任何软件项目。管理软件开发中各个不同版本的源代码和文档，占用空间小并且方便各个版本代码和文档的获取,对开发小组中对源代码的访问进行有效的协调。 它已经死了。当然不完全对，它也存活了许多年，被全新的更实用的源代码管理工具超越之后还在苟延残喘地活着。准确地说当微软 HYPERLINK /lifecycle/search/default.aspx?alpha=Visual+SourceSafe \t _blank 几个月后不再为其提供支持时(还是会坚持一段时间的)，它才是真的死了。 　　平心而论，VSS 还是一个不错的工具。在 1995 年，它的光芒被像 Subversion 这样类似于 Git 和 Mercurial 的分布式软件给遮盖住了。微软表示要取代它已经好多年了。 　　原因是因为不支持如今的标准所导致的一系列缺陷使它一直不被看好。众所周知它是 HYPERLINK /alan/windev/sourcesafe.html \t _blank 微软的悲剧系统，但不知何故它能坚持这么久，尽管它有那么多小故障，缺陷，并且不包含必需的功能（相对于今天的标准）。? 　　第二.如果代码没放在源代码管理软件里，等于