Questions tagged «team-foundation-server»

Team Foundation Server(通常缩写为TFS)是一种Microsoft产品,提供源代码控制,数据收集,报告和项目跟踪,旨在用于协作软件开发项目。

15
如何说服牛仔程序员使用源代码控制?
更新 我在一个由4个人组成的小型开发团队中工作。他们都使用了源代码控制。他们中的大多数人不能忍受源代码管理,而是选择不使用它。我坚信源代码控制是专业发展的必要部分。有几个问题使得说服他们使用源代码管理非常困难: 该团队不习惯使用TFS。我进行了2次培训,但只分配了1个小时,这是不够的。 团队成员直接在服务器上修改代码。这样可以使代码不同步。要求比较只是为了确保您正在使用最新的代码。并出现复杂的合并问题 开发人员提供的时间估算不包括解决这些问题所需的时间。因此,如果我说诺诺,则需要花费10倍以上的时间...我必须不断地解释这些问题并冒险冒险,因为现在管理层可能会认为我“慢”了。 服务器上的物理文件超过100个文件以未知的方式有所不同。合并需要了解手头的项目,因此需要我无法获得的开发人员合作。 其他项目不同步。开发人员继续对源代码管理不信任,因此不使用源代码控制使问题更加复杂。 开发人员认为,使用源代码控制很浪费,因为合并容易出错并且很困难。这很难辩驳,因为当源代码控制被严重滥用而源代码控制被不断地绕开时,它确实容易出错。因此,证据在他们看来是“不言而喻”。 开发人员认为,绕过TFS直接修改服务器代码可以节省时间。这也很难争论。因为开始同步代码所需的合并非常耗时。乘以我们管理的10多个项目。 永久文件通常与Web项目存储在同一目录中。因此,发布(完全发布)会删除这些不在源代码管理中的文件。这也加剧了对源代码控制的不信任。因为“发布破坏了项目”。解决此问题(将存储的文件移出解决方案子文件夹)需要花费大量时间和调试时间,因为这些位置未在web.config中设置,并且通常存在于多个代码点中。 因此,文化会持续存在。不良做法会导致更多不良做法。不良的解决方案会驱使新的黑客“更正”更深层次,更耗时的问题。服务器,硬盘空间极难获得。然而,用户的期望正在上升。 在这种情况下可以做什么?

7
我们进行版本控制的方式有问题吗?
我和一个程序员团队一起担任业务分析师。我们刚刚发布了该产品的2.0版,并且正在开发3个月内发布的下一个版本(这是内部软件产品)。不幸的是,版本2.0存在一些必须修复的问题,我们将在几周内部署这些修复程序。问题在于,我们也不想部署仍在进行中且计划在未来3个月内不发布的更改。 程序员认为管理此问题的方法是仅检入缺陷代码,而新增强功能的代码将保留在开发人员的本地计算机上,直到完成。我将不得不从他们的机器上获取本地版本进行测试,因为如果他们签入代码,并且我们必须推出另一个补丁来修复缺陷,我们现在还不希望包括这些增强功能。还有一个问题,即同一代码文件同时包含缺陷修复程序和增强功能,因此他们必须在本地复制该代码文件,然后进行更改以修复错误并检查其中的一个错误,然后通过采用以下方法继续进行增强功能:他们制作的本地副本。 似乎很令人费解-是否有更好的方法来处理这种情况?我们正在使用Team Foundation Server和Visual Studio 2010。


10
您如何避免在错误的分支上工作?
通常,小心就足以防止问题发生,但是有时我需要通过检查随机变量的源代码控制路径来仔细检查我正在处理的分支(例如 “嗯……我在dev分支中,对吗?”)文件。 在寻找一种更简便的方法时,我想到了相应地命名解决方案文件的名称(例如 MySolution_Dev.sln),但是每个分支中的文件名不同,因此我无法合并解决方案文件。 没什么大不了的,但是您有没有使用任何方法或“小技巧”来快速确保您位于正确的分支中?我正在将Visual Studio 2010与TFS 2008一起使用。

4
解释产品待办事项与任务之间的区别
此问题是从Stack Overflow 迁移而来的,因为可以在Software Engineering Stack Exchange上回答。 迁移 6年前。 我已经遇到过几次挑战,希望有人可以提供一些参考,培训或建议,以帮助您解释产品待办事项与TFS中的任务之间的区别。 我了解并已经说明,产品待办事项是“什么”,任务是“如何”。我还解释了PBI是要求,而Task是如何满足要求。 当我解释这一点时,我反复遇到空白的凝视和头部抓挠。看来我所解释的软件工程师无法区分。对他们来说都是一样的。 我相信我的另一个挑战是,我无法有效地说明为什么区分这一点很重要。

4
使用TFS跟踪生产支持中的错误
我刚搬到一家新公司,他们正在使用TFS 2010(几个月后的2012)作为他们的版本控制系统,最近开始将其用作开发人员的工作跟踪系统。 但是,似乎没有供开发和测试之外的人员使用的错误跟踪系统。生产支持正在获取有关问题的报告,即时进行修复,并立即向其用户报告。这需要进行更改,但是我真的不希望有一个完善的系统来跟踪错误和跟踪开发人员的工作。 有没有一种方法可以像FogBugz一样创建一种非常轻巧的将错误输入TFS的方法?登录TFS来填写错误报告似乎很繁重,您必须将其与特定的应用程序关联。支持人员可以执行此操作,但是我希望能够对项目进行分类,并可能将关联更改为应用程序以外的其他内容。 我过去曾经使用过FogBugz,并且在添加错误时,可以根据需要添加很多/小项,以便至少将其记录下来,然后当您对票进行分类时,可以将其弹回以获取更多信息。 。

3
向小型团队介绍版本控制分支策略
我是最近刚从一家公司开始的承包商。 团队是由3位开发人员组成的,其中包括2位初级到中级开发人员,以及即将在同级别开始的另一位开发人员和我本人(6年xp)。对于这两个现有的开发人员来说,这是他们从大学/学院毕业后的第一份工作,而且他们之前从未有资深开发人员来监督他们的工作。 没有明确的版本控制策略。开发人员在主干上进行所有开发,然后从其开发机器直接部署到生产中。现有团队不熟悉分支。 我正在改变所有这些,并引入CI,TDD测试/登台/生产服务器等,以及与此相辅相成的版本控制策略。 源代码控制系统是TFS,我以前从未使用过。它被配置为一个巨型存储库。 我已经为他们写下了一些建议,但是考虑到团队的经验,我还有什么要补充/修改的? 版本控制政策 开发在主干上完成 如果更改估计要花费一周以上的时间,则应在分支上完成,并定期从主干合并到分支中,以阻止两者不同步。 释放为生产代码创建的分支。该分支应该只包含稳定的代码。我们可以有一个发布分支,每个sprint从主干更新一次,或者我们可以每周创建一个单独的发布分支。 如果需要进行影响生产代码的紧急错误修复,则在发布分支上进行修复,然后合并回主干。 如果我们采用一个发布分支策略,则主干将在每个sprint接近sprint末尾时合并到release分支中。 如果我们采用每个发布策略独立的分支,那么主干永远不会合并到Release分支中 在某些情况下,如果分支之间的差异太大,可能有必要在不同的分支上进行两次错误修复。如果我们正在做短距离的冲刺,那么这应该不会经常发生。 我计划有三台服务器。测试环境始终在存储库中运行最新代码。一个暂存环境,该暂存环境正在运行用于暂存/测试“ Release Candidate”代码和UAT用途的最新候选候选版本,以及生产环境。 我计划执行此操作的原因是,到目前为止,该客户端仅完成了内部软件。最新的项目是针对高知名度的媒体客户的,我的感觉是团队需要采用比他们目前更为专业的开发模型。 例如,此刻,用户可以通过错误报告给团队打电话。开发人员找到并修复该错误,在自己的计算机上进行快速测试,然后直接部署到生产中。没有自动化测试或其他任何东西。 事后看来,我认为功能分支太远了,我将删除它。 因此,从本质上讲,它可以归结为a)完全没有分支)b)发行分支和主干,以及c)每个发行版本和主干的发行分支。 我倾向于后者。我最初的想法是,我将同时拥有一个发布候选版本和一个发布版本,可以同时在单独的服务器(UAT /生产)上运行,但是实际上,主干在任何时间点都是发布候选版本,因此每个释放趋于疯狂。我唯一的想法是,如果我们不希望我们的涉众看到开发代码,那么我们可能需要一个单独的候选发布分支,但是YAGNI以及所有这些.....

5
在.NET应用程序之间共享代码的最有效方法是什么?
在我们的工作中,我们有几个不同的.net应用程序,它们共享许多基本功能。我们已经使用干净的n层体系结构构建了这些应用程序,但是到了那一刻,我们意识到我们已经在不同的时间重新实现了相同的功能。显然这违反了DRY,我们希望对此进行更正。我们已经使用Nuget成功实现了通用粘合代码(连接IoC,日志记录,设置),但是我们也希望在所有应用程序之间共享数据和业务层。想法是,UI仅处理其实际需要的业务层部分。 起初这似乎是一个直截了当的问题,但是持续的开发可能会带来一些陷阱,我们不确定如何进行。假设我们建立了一个业务层来全部统治。为简便起见,我将其称为“基金会”。我们将我们的应用程序移植为使用Foundation,并且一切都很好。该基金会通过nuget分发给轻量级UI层,我们看起来很好。但是随后我们开始向应用程序中添加功能,并且遇到了麻烦。 假设我们正在开发Project A,并且添加了一项需要更改Foundation的新功能。我们对基础(Foundation-A)进行更改,并将它们作为不稳定的程序包推送到nuget提要。项目A获得了最新的nuget包,一切都很好。同时,另一位开发人员正在开发ProjectB。他从源代码控制中获得了最新的Foundation,但从一个稳定的分支中获取了最新的Foundation,因此它没有Project A的更改。他进行了更改并创建了Foundation-B。一切都很好。但是随后我们发现,Foundation-A和Foundation-B实施功能实际上可以共享代码,因此我们将它们组合在一起。同时,Foundation-C本身也有自己的变化。最终,Foundation-B可以投入生产,因此我们将其推出。但是然后我们需要更新生产A,B, 这似乎可行,但是我们担心使用不同的数据库模式,并使Foundation信息库的各个分支以及Project A,B和C信息库之间的所有内容保持同步。似乎可能需要大量的手动工作,这可能会出现错误。我希望这尽可能自动化。 这是我们使用的堆栈:C#,具有持续集成功能的TFS,Nuget。我们的应用程序是所有类型的ASP.NET应用程序。如果这会使事情变得更容易,我们愿意研究不同的SCM。 我正在寻找使Nuget对我们不同的源代码分支保持理智的方法。我们不想意外地将开发代码推入生产环境,因为我们引用了错误的Nuget包。

3
如何将TFS映射到两个本地目录
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,以使它成为软件工程堆栈交换的主题。 6年前关闭。 我正在使用TFS使用Web应用程序。每次我构建站点时,重新启动都将花费很长的时间。我想在c驱动器上有该站点的第二个映射,在那里我只会获取最新信息并每天构建一次,因此该版本始终会很快。这就像一个“只读”目录,因为我个人不会对其进行任何编辑。 如果可以的话,或者如果您有其他选择,请告诉我。

7
从TFS到Git
我是.NET开发人员,并且多次使用TFS(团队基础服务器)作为源代码控制软件。TFS的良好功能是: 与Visual Studio的良好集成(因此我几乎可以直观地完成所有操作;没有控制台命令) 便捷的退房,入住流程 易于合并和解决冲突 简单的自动化构建 分枝 现在,我想将Git用作我的开源项目的骨干,资源库和源代码控制。我的项目使用C#,JavaScript或PHP语言,并使用MySQL或SQL Server数据库作为存储机制。 为此,我只是使用了github.com的帮助,并在那里创建了配置文件,并下载了Git的GUI。到这部分是如此简单。 但是我几乎坚持不下去了。我只想做一些简单(真的很简单)的操作,包括: 在Git上创建项目并将其映射到笔记本电脑上的文件夹 检出/检入文件和文件夹 解决冲突 那就是我现在要做的。但是,似乎GUI并不那么用户友好。我希望GUI具有一个Connect To...或类似的名称,然后希望显示一个项目列表,当我选择一个项目时,希望看到该项目的文件和文件夹列表,就像浏览TFS项目一样在Visual Studio中。然后,我希望能够右键单击文件,然后选择check-in...或之类的check-out东西。 我期望很多吗?我应该怎么做才能像TFS一样轻松使用Git?我在这里想念什么?

5
奇怪的公司发布周期:进行分布式源代码控制吗?
抱歉,这篇文章很长,但我认为值得。 我刚从一家小型.NET商店开始,其运作方式与我工作过的其他地方有很大不同。与我以前任职的职位不同,此处编写的软件针对多个客户,并且并非每个客户都同时获得最新版本的软件。因此,没有“当前生产版本”。当客户确实获得更新时,他们还将获得自上次更新以来可能已添加到软件中的所有功能,而这可能是很久以前的事了。该软件是高度可配置的,并且可以打开和关闭功能:所谓的“功能切换”。此处的发布周期非常紧张,实际上它们没有按计划进行:功能完成后,软件便部署到了相关客户。 该团队仅在去年从Visual Source Safe迁移到Team Foundation Server。问题是他们仍然像使用VSS一样继续使用TFS,并在单个代码分支上强制执行Checkout锁定。每当将错误修复发布到现场时(甚至对于单个客户),他们都只需构建TFS中的内容,测试该错误是否已修复并部署给客户!(我自己来自制药和医疗设备软件背景,这真是难以置信!)。结果是半熟的开发人员代码甚至未经测试就投入生产。Bug总是会渗入发行版中,但是如果刚获得构建的客户通常不使用该bug所在的功能,他们将不会看到这些bug。主管知道这是一个问题,因为该公司正在逐渐发展壮大突然之间有一些大客户加入,而一些小客户也加入了。 有人要求我查看源代码控制选项,以消除错误的代码或未完成的代码的部署,但又不牺牲团队发行版的某种异步特性。在我的职业生涯中,我曾使用过VSS,TFS,SVN和Bazaar,但是TFS是我大部分经验的去处。 以前与我合作的大多数团队都使用Dev-Test-Prod的两个或三个分支解决方案,其中一个月的开发人员直接在Dev中工作,然后将更改合并到Test然后是Prod,或者在“完成时”升级,而不是在一个固定的周期。使用定速巡航或团队构建的自动化构建。在我之前的工作中,Bazaar被使用在SVN之上:开发人员在自己的小型功能分支中工作,然后将其更改推送到SVN(与TeamCity绑定)。很好,因为很容易隔离更改并与其他人的分支机构共享。 在这两种模型中,都有一个中央的dev和prod(有时是测试)分支,通过该分支推送了代码(标签被用来标记生产该版本的prod中的构建...这些都被制成了分支以修复错误。发布并合并回开发人员)。但是,这确实不适合此处的工作方式:没有命令何时发布各种功能,何时完成将它们推入。 有了这个要求,我看到的“持续集成”方法就失效了。为了获得与持续集成的新功能,必须通过dev-test-prod来推送它,这将捕获开发中所有未完成的工作。 我认为,要解决此问题,我们应该使用没有开发测试prod分支的大量功能分支模型,而是将源作为一系列功能分支存在,当开发工作完成时,这些功能分支将被锁定,测试,固定,锁定,经过测试然后发布。其他功能分支可以在需要/想要时从其他分支获取更改,因此最终所有更改都会被其他人吸收。这完全符合我上一份工作所经历的纯粹的Bazaar模型。 听起来如此灵活,但似乎没有某个开发主干或prod分支似乎很奇怪,我担心分支无法进行重新集成,或者后期的微小更改永远不会被其他分支和开发人员所抱怨。合并灾难... 人们对此有何想法? 第二个最后一个问题:我对分布式源代码控制的确切定义有些困惑:有些人似乎暗示它只是没有像TFS或SVN这样的中央存储库,有人说这是关于断开连接的(SVN断开了90%并且TFS具有功能完善的离线模式),其他人则说这与功能分支和分支之间没有父子关系的合并的简便性有关(TFS也具有无基础的合并!)。也许这是第二个问题!

1
最佳方法:重组现有的Team Foundation Server(TFS)解决方案
在我的部门中,我们正在为某些统一通信服务器开发几个较小的插件。对于版本控制和分布式开发,我们使用Team Foundation Server 2012。 但是:对于我们所有的应用程序和库,只有一个大型TFS解决方案: 主要解决方案 应用领域 应用程式1 应用程式2 应用程式3 外在 图书馆 库1 库2 工具类 “应用程序”路径包含所有主要应用程序。它们并不相互依赖,但是取决于库和外部项目。 “外部”路径包含一些在我们的应用程序和库中引用的外部DLL。 库路径包含常用的库(UI模板,Helper类等)。它们彼此不依赖,并且在“库”和“工具”项目中被引用。 工具路径包含一些帮助程序,例如设置帮助程序,更新Web服务等。 现在,有一些要点为什么我想更改这种结构: 我们不能使用服务器版本。 用这样的解决方案结构来管理带有冲刺,障碍等的TFS Scrum管理是不舒服的。 每个开发人员始终可以访问解决方案中的所有项目。 如果在Visual Studio中意外击中[F6],则完整的构建会持续太长时间。 您将在此解决方案中进行哪些更改?您如何将这些项目分解为较小的解决方案,应如何构建这些解决方案。 我的第一种方法是为每个应用程序,库和工具创建一个TFS项目。但是,如何确保例如App 2始终包含Lib 1的最新版本?我需要监视库1的更改并在库更改后立即手动更新App 2吗?还是可以以某种方式强制Visual Studio始终以某种方式使用外部项目的最新版本? 编辑:在TFS上,只有一个TFS团队项目集合,其中包含一个TFS团队项目。团队项目包含一个大型的Visual Studio解决方案,其中包含几个包含(请参见上面的结构)的文件夹,每个文件夹都包含多个VS项目。 我的问题是,现在您将如何重组: TFS团队项目 VS项目


6
为发行版选择正确的分支策略
从新项目的新开发团队开始,我们必须为源存储库(例如Microsoft Team Foundation Server 2010)定义分支策略。关于是否要...我们进行了激烈的讨论。 一。有一个Release分支,我们可以从中进行生产构建,然后在实际发布某些内容时添加Label 要么 乙。每个投入生产的新版本都有一个新的Release分支(例如,版本1、2、3等) 选项A看起来很简单,但是我们不确定从长远来看是否会导致问题。选项B似乎只是创建了许多长期存在的分支,并且随着时间的推移不断积累。 有人有任何经验可以帮助我们做出决定吗?具体来说,我想听听任何一种选择的痛点所在。随时提供有关TFS和/或发布管理含义的特定经验。

5
什么时候应该创建开发分支?
我们正在将我们的项目团队从使用单个Main / Trunk分支转移到应定期合并到Main中的多个Development / Work分支。我们将基于本文和《TFS分支指南》(我们正在使用TFS和Visual Studio 2010)建立新流程。 目前,任何时候都有1至5个人从事该项目。Main必须始终保持稳定,因为我们希望该选项可以在需要时释放。我们没有固定的冲刺-至少现在还没有-现在每1-2周发布一次。 现在,每个人都在修复整个应用程序中的错误。在几周内,我们将开始为该应用程序开发新的大型组件。 我们发现的一个症结是何时应该创建开发分支。我们将根据开发人员的技能水平并行实施多个用户故事。我们已经考虑过为每个开发人员创建一个分支,但这没有任何意义,因为在一件作品上总会需要一些协作。我们不能只靠一个开发分支,因为我们想在其他工作完成时合并到Main。 有人对此有指导吗?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.