将坩埚与tfs集成

maz*_*maz 3 tfs jira jira-plugin tfs2012

我使用TFS与Jira管理我的团队任务.我想在开发过程中集成Code Review工具.

当我尝试使用坩埚时,我发现它不支持TFS.

我想知道是否有一个好的和可信的解决方案,让我能用坩埚和TFS.

另外,如果VS和JIRA的代码重新审视工具还有其他建议.

谢谢!

Ale*_*zis 9

前段时间我们决定在我们的项目上运行Crucible.我们的项目使用TFS 2012.我们在TFS中使用一个名为'dev'的分支作为主干,即开发人员提交的分支和原始代码所在的分支.第二个分支,其中发布代码名为'main'我们的同行评审工作流程是:

  1. 进行一些更改并搁置代码
  2. 发送电子邮件给评论者
  3. 审阅者在某些自定义工具中进行审核,并发送电子邮件通知他已完成
  4. 将代码提交到TFS上的"dev"分支
  5. 等待构建服务器成功构建
  6. 提交生产代码所在的"主"分支

我们的目标是改进第2步和第3步.Crucible是很棒的工具,但它不支持开箱即用的TFS,因此我们决定使用一些TFS桥.实际上,使用tfs-> svn或tfs-> git有两个主要选项.最后,我们决定使用tfs-> git bridge,因为在git中创建分支非常便宜并且它可能有用(它确实如此),因为我们正在考虑在git中使用分支来获取TFS中的搁置集.最后我们决定使用git.到目前为止,我只知道将TFS转换为git的两个选项:

  • git tf - 这个适用于Linux并由Microsoft推荐
  • git tfs - 这个只适用于Windows,但我们选择这个,因为大量的命令我们需要将TFS分支转换为Git repo并将我们的git存储库保持在新的状态.我们不使用git将新的更改推回到TFS,我们只需要针对Crucible的git repo.

我们已经采取了一些步骤来实现目标:1.首先,我们将我们的TFS"dev"分支克隆到"dev"repo中.我们只需要这一个分支,并且我们没有从"主"分支进行任何后向合并.我们已尝试使用clone命令执行此操作,但没有任何运气:

git tfs clone http://tfs:8080/tfs/DefaultCollection $/SOME_PATH/dev
Run Code Online (Sandbox Code Playgroud)

这个命令克隆了TFS的完整历史记录,但似乎我们的TFS分支相当大,并且在某些时候git-tfs崩溃了System.OutOfMemoryException异常.另一次,除了超出路径的最大限制之外,我们失败了,我们通过将工作空间dir映射到尽可能短的路径来找到解决方法,如下所示:

git config --global git-tfs.workspace-dir e:\ws
Run Code Online (Sandbox Code Playgroud)

当我们使用clone命令失败时,我们开始使用quick-clone命令.这个克隆从历史上的任何时间开始,从任何变化集开始.

git tfs quick-clone -c545532 http://tfs:8080/tfs/DefaultCollection $/SOME_PATH/dev
Run Code Online (Sandbox Code Playgroud)

选项-c545532这里是开始复制的变更集的编号.每年一次,我们用新标题更新所有源文件,因此我们只需从当年年初开始复制.通过这种方式,我们应该拥有从搁置集中分支的所有必要历史.如果你没有在这里使用-c参数,那么根本就没有任何历史记录,因为 如果你要求快速克隆复制只是历史记录.克隆存储库后,我们编写了"脚本"并将其放入任务调度程序中,每5分钟运行一次.脚本正在做的只是检查TFS中的新提交并在我们的git存储库上创建新的分支.同样,我们在这里使用git-tfs.要获取所有新提交,我们称之为pull命令:

git tfs pull 
Run Code Online (Sandbox Code Playgroud)

要将TFS shelveset取消搁置到特定的git分支中,我们使用unshelve命令:

git tfs unshelve -user=TFSDOMAIN\Username "Shelveset Name Here" Branch_Shelveset_Name_Here
Run Code Online (Sandbox Code Playgroud)

最后一个命令在TFS中从shelveset'Shelveset Name Here'在git中创建分支'Branch_Shelveset_Name_Here'.shelveset的名称可以包含空格和一些转义字符,因此我们的"脚本"可以清除这些情况.正如我所说,在git上创建非常便宜的分支,因此我们对此没有任何问题.如果有什么东西被推入git repo,我们会调用crucible API来刷新它.顺便说一句:为了让网络中的git repo可见,我刚刚安装了SCM-Server.Crucible已安装并配置为使用我们的域用户名/密码,因此我们也会收到电子邮件通知.因此,我们从工作流程中大大改进了第2步和第3步,它可以工作几个月,我们很高兴.

我们的工作流程:

  1. 进行一些更改并搁置代码
  2. 等待我们在坩埚中的搁架(约6-8分钟),创建评论
  3. 审稿人在坩埚中进行审查
  4. 将代码提交到TFS上的"dev"分支
  5. 等待构建服务器成功构建
  6. 提交生产代码所在的"主"分支

在使用这个时,我注意到几个问题:

问题1:如果您将新文件添加到项目中并搁置它,您将无法在git repo中看到它,因为git-tfs无法找到它的父提交.我不确定这个工具是否有错误,但最简单的解决方法是,在shelveset中至少有一个文件与现有父文件.例如,您添加了2个新文件,并希望将其发送以供审核.相反,这些文件创建搁置的,刚刚接触它已经在混帐回购协议(使它在Visual Studio待定),最后你将能够与三个文件(2个新文件[添加]和1个用于编辑[编辑]创建搁置任何文件).在这种情况下,一切正常,git-tfs可以让TFS'搁置到git分支中.,即我们可以在坩埚中看到它.

问题2:有一天,我们在git repo中的HEAD脱离了"主"分支.一旦发生这种情况,坩埚就没有看到新的变化.我用命令修复了它:

git rebase HEAD master
Run Code Online (Sandbox Code Playgroud)

我已经创建了图片,这一切对我们的项目是如何工作的,可能会有所帮助:

TFS-GIT坩埚