禁止开发人员因为每周构建而提交代码

Question

我们的开发团队（约40名开发人员）每两周进行一次正式构建。我们有一个过程，在“构建日”，每个开发人员都禁止将代码提交到SVN。我认为这不是一个好主意，因为：

1. 构建将花费数天（甚至数周的不良时间）和BVT。
2. 人们不能按照他们的意愿提交代码，但他们无法工作。
3. 人们会将所有代码都放在一个巨大的包中，所以常见的很难写。

我想知道你的团队是否有相同的政策，如果不是，你怎么处理这种情况。

由于

Answer 1

1. 选择修订版。
2. 查看该修订版的代码。
3. 构建
4. ???
5. 利润。

Answer 2

通常，构建是由标记的代码构成的 如果定义了标签（并且没有移动），那么每个开发人员都可以提交他/她想要的内容：构建将从固定和定义的代码集继续进行。

如果需要对正在构建的代码集进行修复，则可以从该标签定义分支，在合并回当前开发分支之前，可以进行小修复以实现正确的构建。

“开发工作”（如带有调整的构建）不应该阻止其他开发工作（每日提交）。

Answer 3

第1步：svn copy / trunk / your / project / goes / here / temp / build

第2步：在/ temp / build

中按摩您的来源

步骤3：在/ temp / build中执行构建。如果遇到错误，请将它们修复到/ temp / build并重新构建

步骤4：如果成功，请svn move / temp / build / builds / product / buildnumber

这样，开发人员可以随时办理登机手续，也不会受到每日/每周/每月/每年构建的干扰

Answer 4

听起来令人沮丧。你们有没有理由Continuous Integration？

如果这对您来说听起来太极端，那么肯定会花一些时间来学习分支在SVN中的工作原理。我认为你可以说服团队在分支机构上开发并合并到主干，或者将“正式构建”提交给特定的标签/分支。

Answer 5

我参与过类似政策的项目。我们需要这样一个政策的原因是我们没有使用分支机构。如果允许开发人员创建分支，那么他们可以在该分支上进行他们需要的任何提交而不会中断其他任何人 - 在每周构建期间，策略变为“不合并到main”。

另一种方法是将每周构建拆分到一个分支上，这样无论检入什么（并且可能合并），每周构建都不会受到影响。

正如VonC所建议的，使用标签也是一种很好的方法。但是，您需要考虑当标记文件需要针对夜间构建的修补程序时会发生什么 - 如果开发人员已经检查了该文件的更改，那么该文件已被标记，并且开发人员的更改不应包含在每周构建中？在这种情况下，无论如何你都需要一个分支。但是，剥离标签也是一种很好的方法。

我还参与过让分支变得疯狂的项目，并且试图找出任何特定文件发生的事情变得一团糟。可以在同一时间范围内将更改提交给多个分支。最终需要解决合并冲突。这可能是一个令人头疼的问题。无论如何，我的偏好是能够使用分支机构。

Answer 6

我们为每张票或新功能创建一个分支，即使票很小（例如只需要2个小时来修复）。

在每次迭代的每个编码部分结束时，我们决定在下一个版本中包含哪些票证。然后我们将这些票证合并到主干和发布软件中。

在该流程中还有其他步骤，在将故障单合并到主干之前，由每个故障单分支上的其他开发人员执行测试。

开发人员可以随时通过从trunk创建自己的分支进行编码。请注意，我们是一个只有12名开发人员的小团队。

Answer 7

Kevin和VonC都很好地指出，构建应该从代码的特定版本中进行，并且不应该阻止开发人员提交新代码。如果这在某种程度上是一个问题，那么您应该考虑使用另一个使用集中式AND本地存储库的版本管理软件。例如，在mercurial中，就像在svn中一样有一个中央存储库，但开发人员也有一个本地存储库。这意味着当开发人员进行提交时，他只提交到他的本地存储库，其他开发人员将看不到更改。一旦他准备好为其他开发人员提交代码，那么开发人员就会将更改从他的本地存储库推送到集中存储库。

这种方法的优点是开发人员可以提交较小的代码片段，即使它会破坏构建，因为更改仅应用于本地存储库。一旦变化足够稳定，就可以将它们推送到集中存储库。这样，即使集中式存储库已关闭，开发人员也可以拥有源代码控制的优势。

哦，你会以全新的方式看待分支机构。

如果您对mercurial感兴趣，请查看此网站：http://hginit.com

Answer 8

哇，这是一种可怕的发展方式。

上次我在一个非常庞大的团队工作时，我们在3个时区有大约100个开发人员：美国，英国，印度，所以我们可以有效地进行24小时开发。

每个开发人员都会检查构建树并处理他们必须处理的内容。 与此同时，将会出现持续的构建。构建将从提交的代码中复制并构建它。任何失败都会返回到最近的提交者，以获取该版本的代码。

结果：

• 很多构建，其中大部分编译好。然后，这些构建启动了自动烟雾测试场景，以发现在测试priot期间未发现的任何意外错误。
• 早期发现构建失败，及早修复。
• 很早就找到了虫子，很早就找到了。
• 开发人员只等待最短的时间提交（他们必须等到提交的任何其他开发人员完成提交 - 这个要求使得构建服务器有一个点，他们可以抓住源代码树以获得新的构建）。

大多数开发人员都有两台机器，因此他们可以在另一台机器上运行测试时处理第二个错误（测试非常图形化，会导致各种焦点问题，所以你真的需要一台不同的机器来完成其他工作）。

高效，持续的开发，没有像您的场景中那样的死区时间。

公平地说，我认为我不能在你描述的地方工作。以这种非生产性的方式工作会破坏灵魂。

Answer 9

我坚信，您的组织将受益于持续集成，您可以经常构建，也许每次签入您的代码库。

Answer 10

不知道我是否会因为这样说而被枪杀，但你应该转向像GIT这样的分散式解决方案。 SVN对此很可怕，而且你无法提交的事实基本上阻止了人们正常工作。在40人这是值得的，因为每个人都可以继续自己的工作，只推动他们想要的东西。构建服务器可以执行它想要的操作并构建而不会影响每个人。

另一个例子，为什么Linus说得对，几乎在所有情况下，像git这样的分散式解决方案在现实生活中最有效。