在我目前的工作中，主管的做法是只检查生产就绪代码。最近我参与的项目涉及 3 个不同的开发人员的工作，其中一些文件重叠。这意味着手动集成更改，尽管有些更改需要一天时间然后才完成。我想看看这是否是一种常见的做法，并获得有关如何改变这种做法的建议，因为我知道很多时候我的意见在宏伟的计划中意义不大。
osp70
问问题
731 次
11 回答
4
您可以使用各种方法来处理这种情况，具体取决于您的源代码控制系统。
私有分支：允许您在去的时候签入和处理代码，并在适当的时间来回合并。
搁置集/打包变更集：允许您存储变更集并将其发送到各处以供审查 - 确保它们在签入前已准备好生产。
至于这是否是一种合适的工作方式，我们不允许未经事先审查就签入主要分支机构。要通过审查，您的代码必须通过各种自动化工具，然后必须为同行评审员所接受。对于“生产就绪”的一些定义——就是这样。因此，我们会做与您一样的事情。但是，我们使用私人分支来确保在此过程中仍然可以进行签到，并且其他签到不必干扰。
如果生产就绪意味着在集成环境中进行了测试，那么听起来您可能需要暂存分支或类似的东西。
于 2008-09-04T19:59:30.287 回答
2
签入的代码应该进行单元测试，但对我来说，“生产就绪”意味着它已经通过了集成和系统测试。在代码冻结之前你不能这样做，所以我不知道你在每次签入之前如何做到这一点。
于 2008-09-04T19:52:49.087 回答
2
首先从 VSS 切换到更可靠且功能更丰富的东西。请参阅如何说服公司切换其源代码管理
然后应用已知的良好做法：
现在，此时您还不能“准备好生产”：您仍然需要几周的时间来测试和修复，然后才能进行部署。减少时间对您来说很棒，对您的客户也很棒，所以投资于：
- 高质量的自动化验收测试。
于 2008-09-13T21:14:30.030 回答
1
在更改完成和测试后，拥有一个可以让非“生产就绪代码”签入的 repo 测试分支不是一个好主意吗？
主干不应该签入破坏构建并且不通过单元测试的代码，但分支不必有所有这些限制。
于 2008-09-04T19:57:56.157 回答
0
我个人不会赞成这样做，因为有时这是与经验不足的开发人员一起捕获问题代码的最佳方式（通过在他们正在处理的情况下查看它），并且当您“尽早且经常签入”时，您可以回滚到您之前所做的更改（正如您正在开发的那样）如果您认为您之前所做的一些更改实际上是一个更好的主意。
于 2008-09-04T19:57:43.223 回答
0
我认为这可能是我们使用的版本控制、VSS 以及缺乏学习分支的时间。我真的很喜欢夜间签到以帮助开发并避免“陷入困境”的想法。我可以看到他对树干有抵抗力，但可能会构建一个开发 SS，并且当代码准备好生产时将其移至生产 SS。
于 2008-09-04T20:08:23.293 回答
0
从实践中我看到，生产质量这个词被用作“吓人”，以确保人们害怕打破树顶，老实说，这并不是一件坏事，因为如果可能的话，树顶应该始终有效。
我会说最佳实践是你应该只在树的顶部合并不同的（即单独的）功能组件。如果您对相同源文件的增量有显着重叠，我认为这“可能”表明项目管理在某处发生了故障，并且这些开发人员应该在进入之前将他们的更改合并到单独的集成分支主线资源。个别开发人员说他们对他们的东西进行了单元测试是无关紧要的，因为他们测试的东西已经改变了！
试图解决你的主线代码线上的集成问题将不可避免地拖延其他不相关的提交。
于 2008-09-04T20:09:51.527 回答
0
假设您在一个集中的版本控制系统（例如 Subversion）中工作，并假设您有一个“主干”的概念（最新的运行良好的代码所在的位置）：
如果您在“功能分支”/“实验分支”中处理新功能，那么提交远未完成的代码是可以的。（功能完成后，您将表现良好的结果提交到“主干”中。）
但是，如果将非编译/明显不工作的代码提交到“主干”或“发布分支”中，您将不会赢得人气竞赛。
The Pragmatic Programmers有一本书叫做Pragmatic Version Control using Subversion，其中包括一个关于分支的建议部分。
于 2008-09-04T20:10:17.033 回答
0
提早入住和经常入住有两个主要原因 -
1 - 它可能更容易集成代码
2 - 万一你的电脑爆炸了，你几周的工作还没有结束
于 2008-09-04T20:14:51.450 回答
0
@bpapa
每晚将工作文件夹备份到服务器将防止丢失超过一天的工作。
@tonyo
让我们看看我们完成编码后的第二天就完成了需求文档。这是否告诉您我们的项目管理？
我们是一家小商店，所以虽然您认为改变很容易，但这里有一些不屈不挠的旧方式。
于 2008-09-04T20:20:51.017 回答
0
我特别喜欢的一种方法是在软件仓库中有不同的生命周期版本。也就是说，例如，有一个开发版本的代码，开发人员可以在其中签入正在处理的代码；然后你可以有一个 beta 版本，你可以在其中为你的代码添加 beta 修复；然后是生产版本。
这种方法有明显的开销，例如您将在本地机器上拥有更大的工作空间，您需要有一个迁移过程才能将代码从一个阶段移动到下一个阶段（这意味着进行与迁移相关的集成测试时代码冻结），并且根据项目的复杂性，您可能需要使用工具来更改设置、环境变量、注册表项等。
所有这些都是设置起来很痛苦，但你只做一次，一旦你把一切都准备好，在代码的不同阶段工作就变得轻而易举了。
于 2008-09-04T22:50:42.077 回答