在我当前的工作中，主管的做法是仅签入生产就绪代码。最近，我参与的项目由3个不同的开发人员进行工作，文件重叠。这意味着尽管有一些更改要花一天的时间，然后手动完成，但仍要手动集成更改。我想看看这是否是一种常见的做法，并获得有关如何更改这种做法的建议，因为我认识到很多次我的看法对宏伟的事情没有多大意义。

解决方案

回答

签入的代码应该进行单元测试，但是对我来说，"生产就绪"意味着它已经过集成和系统测试。在代码冻结之前我们无法执行此操作，因此在每次检入之前我都看不到如何执行此操作。

回答

我个人不赞成这样做，因为有时这是与经验不足的开发人员捕获问题代码的最佳方法(通过在他们进行工作时对其进行查看)，并且当我们"经常检入"时，我们可以回滚到之前所做的更改(在开发过程中)，如果我们决定早先进行一些更改实际上是一个更好的主意。

回答

在更改完成并测试之后，让仓库的测试分支可以签入非"生产就绪代码"，这不是一个好主意吗？

主干永远不要签入破坏构建并且不通过单元测试的代码，但是分支不必将所有这些限制都放在适当的位置。

回答

我们可以使用多种方法来处理这种情况，具体取决于源代码控制系统。

私有分支：允许我们在运行时检入和处理代码，并在适当的时间来回合并。

搁置集/已失效的变更集：允许我们存储变更集并将其发送到周围进行审核，以确保在签入之前已准备好进行生产。

关于这是否是一种适当的工作方式，我们不允许未经事先审查就可以签入主要分支机构。要通过审核，代码必须通过各种自动化工具，然后同行审阅者才能接受。对于"生产准备就绪"的一些定义就是这样。因此，我们会像我们所做的那样做。但是，我们使用专用分支机构来确保在进行过程中仍可以进行签入，并且确保其他签入不会受到干扰。

如果生产准备就绪意味着要在集成环境中进行测试，那么听起来我们可能需要暂存分支或者类似的东西。

回答

我认为这可能是我们使用的版本控制，VSS以及缺乏学习分支的时间。我真的很喜欢每晚登记入住的想法，以帮助开发并避免'Going Dark'。我可以看到他对主干有所抵触，但也许正在构建开发SS，并且在代码准备好投入生产时将其移至生产SS。

回答

从实践中，我已经看到"生产质量"一词被用作"吓ener者"，以确保人们不敢破坏树顶，老实说，这不是一件坏事，因为树顶应该尽可能地工作。

我要说的最佳实践是，我们只应在树的顶部合并不同的(即单独的)功能组件。如果我们在增量变化上与相同的源文件有很大的重叠，我认为此"可能"表示该行的某个地方项目管理已崩溃，并且那些开发人员在进入目录之前应将其更改合并到单独的集成分支中。主线来源。一个单独的开发人员说他们对他们的东西进行了单元测试是无关紧要的，因为他们测试的东西已经改变了！

尝试解决主代码行上的集成问题将不可避免地拖延其他无关的提交。

回答

假设我们正在集中式版本控制系统(例如Subversion)中工作，并假设我们具有"主干"概念(最新运行良好的代码所在)：

如果我们在"功能分支" /"实验分支"中使用新功能，则可以提交尚未完成的代码。 (功能完成后，我们会将行为良好的结果提交到"行李箱"中。)

但是，如果将未编译的/显然不起作用的代码提交到" trunk"或者" release branch"中，我们将不会赢得人气竞赛。

实用编程人员有一本书，名为《使用Subversion进行实用版本控制》，其中包含有关分支的建议的部分。

回答

提早入住并经常入住的主要原因有两个：

1它可能使集成代码更容易

2万一计算机爆炸了，工作周数还没过去

回答

@bpapa

将工作文件夹每晚备份到服务器将防止丢失超过一天的工作。

@tonyo

让我们看看需求文件在编码完成的第二天就完成了。那能告诉我们我们的项目管理吗？

我们是一家小商店，所以尽管我们认为更改很容易，但这里有些与旧方法没有冲突。

回答

我特别喜欢的一种方法是在仓库中使用不同的生命周期版本。例如，有一个开发版本的代码，开发人员可以在其中检入正在处理的代码。那么我们可以拥有一个Beta版本，我们可以在其中向代码添加Beta修复程序；然后是生产版本。

这种方法存在明显的开销，例如，我们将在本地计算机上拥有较大的工作空间，需要将迁移过程放置到适当的位置，以将代码从一个阶段移到另一个阶段(这意味着在执行与迁移一起进行的集成测试时冻结代码)，并且根据项目的复杂性，我们可能需要具有更改设置，环境变量，注册表项等的工具。
所有这些设置起来都很麻烦，但是只需要执行一次，一旦全部准备就绪，就可以轻松地在代码的不同阶段进行工作。

回答

首先从VSS切换到更可靠和功能更丰富的产品。请参阅如何说服公司切换其源代码管理

然后应用已知的良好做法：

• 经常检查
• 经常整理他人的更改，以简化合并
• 使用快速的单元测试，以确保每个更改都满足最小要求
• 要求签入的代码始终生成并始终通过测试。

现在，我们现在还不会"准备就绪"：我们仍需要几周的时间进行测试和修复，然后才能进行部署。节省时间对我们和客户来说都是很棒的，所以投资于：

• 高质量的自动化验收测试。