您最喜欢的SVN Web应用程序部署工作流程是什么？

Question

我们目前正在使用一个有点复杂的部署设置，涉及远程SVN服务器，DEV，STAGE和PROD的3个SVN分支，通过补丁等促进它们之间的代码。我想知道你在小部署中使用什么开发团队的情况？

Answer 1

用于开发的主干，以及用于生产的分支（生产）。

在我的本地计算机上，我有一个指向trunk分支的VirtualHost来测试我的更改。

任何对trunk的提交都会触发一个提交钩子，该钩子执行svn导出并同步到在线服务器的dev URL - 所以如果该站点是stackoverflow.com，那么这个钩子会自动更新dev.stackoverflow.com

然后我使用svnmerge在我的本地结账中将选定的补丁从主干合并到生产。我在本地机器上再次指向VirtualHost指向生产分支。

当我将合并的更改提交到生产分支时，SVN导出挂钩再次更新生产（实时）导出并且该网站是实时的！

Answer 2

当我在一个小开发团队工作时（小意思是我，另一个程序员和老板），这是一个混乱的混乱。然而，我们发现分配“看门人”类型的过程对我们有用。

看门人是在应用程序上做了最多工作的人（在这种情况下，我有2个项目，我从头开始，他有4个）。

基本上，每当他不得不处理我的项目时，他都会通知我他正在做工作，我会确保存储库是最新的和可构建的，然后他会下拉，进行他的更改然后提交。他会告诉我它已经完成，我会下拉，构建和部署。如果有DB更改，我们有一个DB Change文件夹，其中包含可以纠正数据库的所有脚本。

它显然有很多漏洞，但这个过程对我们有用，并且让我们不能互相建立。

Answer 3

三个分支听起来像额外的工作。

可以通过在主干中使用不同版本的相关文件来处理环境差异。即database.yml＆amp; database.yml.prod。部署过程应该具有环保意识，只需将每个环境文件复制到默认文件即可。

Answer 4

我对常见的标签/分支机构/中继组织没有任何问题。

一般的持续发展发生在后备箱。

在适当的发布分支中维护生产中的版本。

合并仍然与中继相关的发布分支的更改。

当新版本准备好部署时，它会从主干标记，然后从该标记创建分支。新版本分支将与当前版本并行检出服务器。当需要切换时，路径是杂乱的（“mv appdir appdir.old＆amp;＆amp; mv appdir.new appdir”）。

支持生产版本的开发人员然后svn将他们的工作副本切换到新分支，或者从中进行新的结账。

Answer 5

一个简单的trunk分支包含最新的代码，然后在我们上线时剪切一个分支。这似乎非常有效。每当您为实时系统切割的当前分支失败时，您都可以轻松转到上一个分支。此外，很容易修复当前活动的分支上的错误，并且由于分支在切割新分支时有效死亡，因此只需要处理1个真正的分支（然后将修复从那里合并到现场分支）。

Answer 6

我们不使用分支来暂存与网络相关的内容;仅用于测试需要很长时间（读取：超过一天）的实验性内容才能合并回主干。主干以“持续整合”的方式代表了一种（希望）正在发挥作用的当前状态。

因此，大多数更改都会直接提交到主干。 CruiseControl.NET服务器将在也运行IIS的计算机上自动更新，并具有所有额外站点资源的最新副本，因此可以在内部对站点进行全面，干净的测试。测试后，文件将上传到公共服务器。

我不会说这是完美的方法，但它很简单（因此适合我们相对较小的员工）并且相对安全，并且工作得很好。

Answer 7

Trunk包含当前的“主要”开发代码库。

开发人员通常会为任何中长期项目创建一个单独的分支，这可能会影响主干代码库并妨碍其他开发人员。当他完成后，他将合并回主干。

每次我们将代码推送到生产时，我们都会创建一个标记版本。 / tags中的文件夹只是版本号。

要部署到生产，我们正在进行SVN Export to Staging。当这令人满意时，我们使用简单的rsync来推广到生产集群。

Answer 8

我强烈推荐这本书（目前正在大幅削减）Continuous Delivery，该书描述了基于持续集成原则（以及其他）的软件交付管理的完整流程。

我非常不喜欢分支和合并方法，因为它可能变得非常混乱，并且非常浪费，因为你最终花时间在实际上没有提供任何新价值的活动上。您已经开发，测试并修复了一次代码，为什么要创建一种情况（将代码复制到另一个分支），这需要您重做这项工作？

无论如何，避免分支和合并的方法是从trunk创建可部署的工件，并在通过测试，升级等时提升构建的工件（而不是源代码）。这样你就100％肯定了这个东西你投入生产就像你测试的一样。

如果你有不同的功能需要在不同的时间表上发布，那么改变你的实现方法（使功能可配置，或者更好的模块化）可以帮助你保持一个开发中继。

Answer 9

我们使用发布分支 - 这似乎比我们正在进行的功能分支更有效。

不要为不同的环境制作不同的分支。

Answer 10

我个人在本地工作（开发），添加/修复功能，当我认为它准备就绪时，我会致力于主干（生产）。在生产服务器上，我只是做了一个svn更新。

Answer 11

我的工作环境与您目前的情况类似。我的任务是找到一个“更好”的解决方案，并按照以下方式运行。

实时分支表示处于当前状态的服务器。

任何开发工作都应该在一个取自现场的分支中完成。这可能是一个半小时的工作或一年的多团队项目。通常情况下，对live的更改可以合并到这些开发分支中。

在一项工作上线之前，来自实时的更改将再次合并，并被标记为潜在版本。此版本在暂存环境中进行测试，如果通过测试，则会从标记中获取新版本。

如果效果更好，可以将多个工作合并到一个版本中。

这意味着让开发分支与实时保持同步是相当简单的，如果开发中的一项工作被删除，那么最少的整理工作就可以完成。

要从一个项目转到另一个项目，开发人员可以简单地将他们的本地工作环境切换到另一个分支。

我们所描述的系统问题之一就是DEV可以很快地与PROD过时，因此您不会在现场开发，并且在阶段之前发现交叉依赖关系并不容易。上述解决方案解决了这些问题，同时仍然保持相当轻量级。