如果你使用subversion,你如何组织开发人员可以轻松检查最后一个工作版本并处理这个版本,而不是处理可能损坏的HEAD?
问题背后的想法如下。当许多开发人员同时在一个项目上工作时,有人可能会破坏构建或某些测试。持续集成有助于尽早发现这些事情,但这并不能防止HEAD版本暂时中断。所以我想让每个人都能够轻松检查并处理已知有效的最新版本,并且只在必要时才更新到HEAD进行提交。使用SVN创建标签似乎不是这样做的合适方式,因为在SVN中,标签本质上是一个新的分支,并且可以在每次成功构建之后移动。你会怎么做?
答案 0 :(得分:2)
如果您的开发人员遵循'更新头,运行本地构建/测试,签入'的标准做法,那么您的服务器构建中断的可能性应该非常小......
也就是说,您可以让您的构建在成功时更新公共批处理文件/脚本,开发人员会使用它来检查特定的主干版本(运行成功构建的修订版本)。因此,在成功构建时,您需要将checkout命令更新为:
svn co https://<ServerPath>@RevisionNumber
其中RevisionNumber
,在运行服务器结帐时存储,或通过调用svn info
并提取Revision:
值
答案 1 :(得分:1)
从纯技术角度来看问题是,您正在尝试根据持续集成环境中的构建结果来协调源代码控制的行为。我不知道有什么方法可以让开发人员在同一路径中从早期版本中提取,具体取决于CI构建结果。
但实际上,这是一个开发实践问题。开发人员不应该提交“打破构建”的代码,并且已经写了很多应该抛弃给那些做的人的惩罚:)
但是,当然构建本地构建可以成功,而集成回主干的代码构建可能会失败。这就是为什么像TeamCity这样的产品具有“个人构建”的概念,从而可以针对主干构建正在进行的工作,并且只有在成功构建之后才能提交。
简而言之,您的问题已为人所知并得到认可,并且存在一系列工具和实践来解决这个问题。但不的做法包括禁止基于构建结果的代码拉取。
答案 2 :(得分:1)
如果您的CI服务器通知所有开发人员,即不仅仅是那些在构建中断时破坏了构建的开发人员,那么您的开发人员可以通过观察失败的构建电子邮件来避免陷入困境,并等到“构建已修复”的电子邮件进入出。如果开发人员需要更新(可能在休假之后),他们可以回到上一次良好的修订版。大多数CI软件都支持这一点我知道Jenkins提供了“最后一次成功构建”的链接。如果你想要一个网页来显示这个,就像@forsvarir建议的那样,你可以轻松地抓住这个页面。
答案 3 :(得分:0)
即使我使用SVN,因为它允许许多开发人员多次结账,无论谁检查文件,都需要检查并与之前的版本进行正确比较。
假设在下一个版本中,如果代码中断,我们可以轻松地将其还原..
答案 4 :(得分:0)
如果这确实是一个例外,最简单的方法是建议开发人员在CI服务器网页中找到上次成功构建/部署的修订号,并建议在出现问题时返回此修订号。然后可以修复问题而不会过多地打扰其他问题。