我们目前使用Gerrit,一个大约12人的团队和一些开发人员。
这是我们当前的工作流程:
从master
我们喜欢这个工作流程,它很棒。它为我们的开发带来了奇妙和迫切需要的过程和纪律,并从我们以前被忽视和忽视的代码审查瓶颈中制定了一个待办事项列表,每个人都为此而感到高兴。
X-间歇-X
我们现在希望将我们的任务管理转移到Jira上。在我设置它的时候,我也设置了Crucible,因为它看起来像是让代码审查成为整个shebang的一部分的自然集成。我不能做的是重现我们喜欢的上面的工作流程。有了Jira/Crucible的集成,因为我们不再有我们的存储库门户来保持一切(我们也不想为Atlassian的存储付费),我们将把代码推送到Bitbucket。我们不能再直接在master上工作,因为糟糕的代码将不再被“把关”,而是在它通过任何测试或代码审查之前被开发人员合并到master中。将其排除在主分支之外的唯一解决方案似乎是forks。好吧,这很烦人,但我可以接受。但是,在通过代码审查后,我如何从开发人员分支获得提交,以便合并到主分支中?这就是我想听到的,那些做过任何类似事情的人,或者知道如何在我的情况下完成它的人。
所有这些的替代方案是尝试使用https://github.com/hobbs/jirret强制在Jira和Gerrit之间进行集成,但使用的是XML,Jira仍然支持XML,但不再进行任何开发。
发布于 2012-08-21 01:17:47
Vic,要从开发人员的fork中获取更改并将其带入原始repo的主代码行,您可以在Bitbucket中使用pull请求。它们是对您正在进行的Crucible代码审查的补充。如果forking是一种痛苦,你可以尝试在你的repo中创建一个“集成”分支,并让开发人员频繁地在那里推送代码(甚至在他们准备接受同行评审之前)。这个分支变成了一种汤,在那里集成问题可以浮出水面并得到解决,而不会污染master。Atlassian的一些开发团队使用了集成分支,还利用了竹子对自动将CI方案应用于新分支的支持,以及每个构建分支之间的自动合并。通常,每次将代码推送到dev分支时,您都会将您的开发分支合并到集成中。这对及早发现冲突很有帮助。
链接到的博客Matt更详细地描述了这种工作流程。不管你使用哪种CI工具,基本的工作流程都可以成功(尽管竹子确实有很好的支持和出色的JIRA集成)。
我希望这能帮到你!
发布于 2012-08-18 17:26:15
如果你不介意做一些编程,你可以使用Jira scripting suit来使用Jira工作流事务在你的服务器上运行实际的代码,并相应地更新问题内容/状态。要显示动态内容(来自本地文件或任何远程服务器),您可以使用Jira behaviour plugin和by using Javascripts and HTML code。
正如我所说的,这将需要一些编程,但您可以将原始工作流与Jira集成。
注意:尽管"XML,Jira仍然支持它,但不再为它做任何开发“,这个API非常强大,并且具有一些其他API所不具备的功能,所以即使它不会在将来开发,您也可能会发现它满足了您的大部分需求。
希望能有所帮助。
发布于 2013-01-15 04:22:49
我已经在Bitbucket的追踪器上打开了一张票,询问一个非常相似的东西:https://bitbucket.org/site/master/issue/5652/allow-for-pull-requests-to-require
不幸的是,我从Atlassian得到的回答似乎是“对不起,我们不会这么做的。请购买Stash。”我们遇到的问题是,Stash目前不是一个托管解决方案,我们也没有计划自己设置基础设施来托管它(实际上,我们以前就是这样做的,但在与Atlassian交谈后,最终迁移到了他们的托管解决方案)。考虑到他们已经在Stash中完成了这项工作,我不太确定为什么他们不把它作为Bitbucket的一个“企业”功能提供。就目前而言,我想我所能做的就是让人们对这张票发表评论,以表明开发人员对这些类型的工作流非常感兴趣(这是一个将其与GitHub区分开来的特性!)。
https://stackoverflow.com/questions/12015628
复制相似问题