将SVN设置为Best Suit Dev - ＆gt; QA - ＆gt;刺

Question

如果已经提出这个问题我很抱歉，但我找不到针对这种情况的答案：

对于我们的Web应用程序，我们有3个系统：dev，QA和production。现在，第三方正在维护代码，但很快就会掌握在我们手中。我们将为每个阶段提供单独的构建环境。此外，我们使用RAD进行代码开发，因此实际上会有一个主要步骤，test / sandbox。

理想情况下，我们想以某种方式隔离每个阶段的存储库，以便我们从DEV检出，进行一些更改，在本地测试它们，然后将它们检入DEV。如果Dev上的一切正常，我们将检查QA，依此类推。

我们是否应该为每个存储库设置单独的存储库，或者这将属于“分支”，我们在dev，QA和prod中有一个单独的分支。你能提供实现理想路线的最佳方法吗？

如果还有其他问题，请告诉我。

由于 克里斯

Answer 1

使用分支和合并

我们执行以下操作：

当我们发布时，我们创建一个当前发布分支。我们在发行版之间修复错误，然后将它们合并回我们的主干。

我们在主干上开发，当我们准备发布时，我们建立了QA分支。我们测试并修复它，然后推出它，它成为我们当前的发布分支。

Answer 2

查看Scott Cowan的博文：

http://sleepoverrated.com/archive/2007/12/buildknowledgepromotingyourbuild/

他有一篇关于将代码推广到不同环境的精彩文章。它将包括编写一些构建脚本，但将改进该过程。它将允许它也是一些自动化的东西。

Answer 3

您应该有一个可以在部署过程中检出或导出的存储库。

我们也有类似的设置。开发人员查看本地工作副本并在其开发环境中进行开发。当我们准备好部署到舞台，或者你所谓的QA时，我们会对该环境进行svn导出（通常是头部，但我们总是跟踪具体的修订）。

在QA过程中，我们继续在开发中开发并部署到QA。

最后，当我们准备好生产时，我们会将正确的修订从存储库导出到生产环境中。

效果很好！

[编辑：至于'这个分支' - 你所描述的可能更像是跟踪修订。然而，分支是管理不同开发线的非常重要的技术。这不应该与每个阶段（开发，舞台，现场）的不同分支相混淆，必然是这样的。

Answer 4

如果您正在使用轻松确认的任务处理单个开发流，则此工作正常。但是，对于多个开发流以及任务被拉出或延迟的可能性，它将更具挑战性。然后，您需要在应用程序中使用某种时间依赖性。您还可以使用功能分支之类的功能，一旦构建功能，它就会合并回主干。

Answer 5

我们有类似的架构。在SVN中，我们有3个分支，trunk，PREPROD和PROD。每当新功能准备好尝试时，它就会被合并到PREPROD分支中（仅使用特定的修订版号，仅针对特定文件），如果它通过QA，它将被提交并合并到PROD分支中。在PROD分支中提交更改后，它们将自动部署在所有生产服务器中。除了测试新功能时，PREPROD和PROD相同。

Answer 6

我们为每个错误修正，功能或任务都有一个开发分支，并且涉及的项目往往有多个子分支。

最初，只需一行代码修复就可以创建一个新的分支，但它允许将主干合并到分支中，然后进行回归测试，最后合并回主干。

理想情况下，这意味着合并到trunk中的任何内容都不会破​​坏构建，这意味着您不会害怕提交代码来构建脆弱的构建。

我经常在一个问题上使用多个分支，测试不同的解决方案，同时仍然获得SCM的好处。

我们还标记特定版本或版本，允许基于已知良好代码进行快速部署。

我们的很多基于Web的系统使用svn：externals指向特定版本的依赖项，例如库和供应商代码。部署是从外部进行的，而不是直接结账或导出。