颠覆 - 异步开发周期...两个中继？

目前在我们的企业，我们有一种情况，我认为这不是很常见，或者至少我没有在互联网上发现类似的情况。我的问题是，我们有可以根据多个需求进行演变的软件，并且这两个软件在发布日期不一定相同。颠覆 - 异步开发周期...两个中继？

我们有一个开发周期，所有软件都在“DEV”环境中开发，然后处理到SQA，因此可以在“LAB”环境下进行测试;如果一切正常，那么这个软件就会移到“PROD”环境。我在这里面临的问题是，我不能使用一个单一的树干，我也不知道单个分支如何工作。

例如，可以说我有要求A和B，一个要今天发布，另一个要从今天开始发布。两者都已经达到LAB环境，但是今天发布到PROD环境只需要包含A，因为我们的商业用户尚不需要B（并且它不能提前发布，因为它会向其他系统引入一些错误）。在不同部门开发的这两个要求（他们对不同的需求作出响应）。在这种情况下，我的问题是，我不能拥有一个开发人员可以合并的主干，以便在“DEV”环境中查看这两个更改，然后使用相同的主干来提供“LAB”环境，因为它的源代码尚未排定发布。

我想我还应该提到，每个分支都有一个单独的开发环境是不可能的，因为这个软件基于PL/SQL（Oracle），而我们当前的测试数据库大小约为350Mb，所以拥有不同的对于每个需求来说都相当昂贵并且难以管理。

任何建议或类似的经验，将不胜感激。

问候

来源

2009-01-23 Patricio Téllez

我建议如下：

产品-1/
- 躯干/
- 分支机构/
  - 特征分支机构/
    - REQ-A/
    - REQ-B/
  - 预实验室/
  - 实验室/
  - 刺/

开发者开始为新的显影对各个功能分支的要求。然后，您将已经决定包含在环境LAB /中的功能分支重新整合到预实验室/，您可以在其中整合来自trunk /的新功能和错误修正的更改。

只要您知道这些工作（需要一些时间，因为从多个来源合并的任何集成步骤），您可以合并从实验室前/实验室到实验室/的所有更改。当你限制自己只从预实验室/实验室/合并到实验室时，这种合并将始终是干净的，即一次鼠标点击即可。

在主干/您可以合并所有功能分支和错误修复，但取决于您的项目结构和软件开发过程，这可能需要进一步讨论。

一定要使用Subversion 1.5，因为这种合并会让你迷失在地狱与旧版本。

来源

2009-01-23 13:56:45 gimpf

这听起来像你对我可以从使用分布式VCS（git的，反复无常，商场等）

来源

2009-01-23 13:45:19 JesperE

大声笑....一些Windows粉丝男孩 – 2009-01-23 13:56:59

分布式VCS应该如何由Windows粉丝提出？但实际上我不明白为什么DVCS能够解决组织问题。像GIT这样的应用程序，合并过程会更容易，是的，但这不能回答这个问题。 – gimpf 2009-01-23 13:59:50

Windows粉丝男孩？你失去了我。 – JesperE 2009-01-23 14:11:37

根据您最后一段你已经有了相当多的泡菜中受益。我相信最好的做法是按功能进行分支，并在需要/释放时将功能合并到主干中。我真的不知道是否有提高你的情况第二最佳实践（但我没有那么聪明）...

来源

2009-01-23 13:55:25

嗯，就我所知，你是对的，但有些过程人员喜欢特殊的樱桃采摘程序，而开发人员经常有足够的理由来开发全集成主干。 – gimpf 2009-01-23 14:01:52

在大多数情况下，您需要测试启用和禁用功能的结果应用程序，以便您可以选择在发布时启用或禁用的内容。

问题是，如果您创建了一个包含两者的测试版本，然后完全删除一个部分，而不考虑您的版本系统，那么最终可能会创建一个您不知道的集成问题，已经将其推送到生产服务器。

无论你做什么，你仍然需要测试你将提供给客户的确切产品。

然后一个版本应该是什么将被测试，而不是生产什么。测试版本将会生产什么。在这一点上，它只是为每个版本或功能创建分支并合并需要的问题。

合并操作并不一定适用于所有内容。如果提交完成，您应该能够轻松地在分支之间合并您需要的功能（comits和/或文件）。另外要注意的是，SVN只能够保留合并分支的历史，因为1.5/

来源

2009-01-23 13:56:59 Loki

颠覆 - 异步开发周期...两个中继？

回答

相关问题