您最喜欢使用SVN的Web应用部署工作流是什么?

用于开发的主干,以及用于生产物料的分支(生产)。

在本地机器上,我有一个虚拟主机指向主干分支,以测试我的更改。

任何对主干的提交都会触发一个提交钩子,该钩子执行SVN导出并同步到联机服务器的dev url-因此,如果站点是stackoverflow.com,那么这个钩子会自动更新dev.stackoverflow.com

然后我使用svnmerge在本地签出中将选定的补丁从主干合并到生产。我的本地计算机上又有一个虚拟主机指向生产分支。

当我将合并的更改提交到生产分支时,SVN导出挂钩再次更新生产(实时)导出,并且站点是实时的!

当我在一个小的开发团队(小意思是我,另一个程序员和老板)工作时,那是一片混乱。然而,我们发现分配一种“门卫”类型的流程对我们很有用。

门卫是在应用程序上完成最多工作的人(在本例中,我从一开始就开发了2个项目,他有4个)。

基本上,当他必须处理我的项目时,他会通知我他正在做工作,我会确保存储库是最新的并且是可构建的,然后他会下拉,做出他的更改,然后提交。他会告诉我已经完成了,我会拉下来,建造和部署。如果有数据库更改,我们有一个数据库更改文件夹,其中包含所有可以更正数据库的脚本。

很明显它有很多洞,但是这个过程对我们很有效,并且阻止了我们在彼此之间建立。

我对普通的标签/分支/主干组织没有任何问题。

一般正在进行的开发发生在主干中。

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

合并对仍然与主干相关的发布分支的更改。

当一个新版本准备好部署时,它将从主干中被标记,然后从该标记创建一个分支。新的发布分支与当前版本并行签出到服务器。当需要切换时,路径会发生变化(“mv appdir appdir.old&mv appdir.new appdir”)。

支持产品发布的开发人员然后SVN将他们的工作副本切换到新的分支,或者从中进行新的签出。

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

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

一个简单的主干分支包含最新的代码,然后在我们上线时切断一个分支。这似乎很有效。当为实时系统剪切的当前分支失败时,您可以很容易地转到上一个分支。此外,很容易修复当前活动的分支上的错误,而且由于分支在剪切新分支时有效地死亡,因此只有一个真正的分支需要处理(然后将修复从那里合并到活动分支)。

我们不使用分支来准备与Web相关的东西;只用于测试需要很长时间(阅读:一天以上)才能合并回主干的实验性东西。主干,以“持续集成”的方式,表示(希望)工作的当前状态。

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

我不会说这是一个完美的方法,但它很简单(因此适合我们相对较小的员工),相对安全,而且工作也很好。

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

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

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

为了部署到生产中,我们正在将SVN导出到Staging。当这令人满意时,我们使用一个简单的rsync来展开到生产集群。

我强烈推荐这本书(目前是粗略的) Continuous Delivery 它描述了基于持续集成原则(以及其他原则)管理软件交付的完整过程。

我非常不喜欢分支和合并的方法,因为它可能会变得非常混乱,而且非常浪费,因为您最终会将时间花在那些实际上没有任何新价值的活动上。您已经开发、测试和修复了一次代码,为什么要创建一个场景(将代码复制到另一个分支),需要您重新进行这项工作?

无论如何,避免分支和合并的方法是从主干中构建可部署的人工制品,并在通过测试、分段等时推广已构建的人工制品(而不是源代码)。这样,您就100%确信要投入生产的产品与已测试的产品相同。

如果您有不同的特性,可能需要在不同的时间表上发布,那么改变实现方法(使功能可配置,或者更好的是模块化)可以帮助您保持单一的开发主干。

我们使用发布分支——这对我们来说似乎比我们所做的功能分支更有效。

不要为不同的环境创建不同的分支。

我个人在本地工作(开发),添加/修复特性,当我认为它已经准备好的时候,我将致力于主干(生产)。在生产服务器上,我只是执行SVN更新。

我的工作环境和你现在的情况类似。我的任务是找到一个更好的解决方案,它按照下面的路线运行。

活动分支表示处于当前状态的服务器。

任何开发工作都应该在从Live获取的分支中完成。这可能是一个人半小时的工作,也可能是一年多团队的项目。只要喜欢,对live的更改就可以合并到这些开发分支中。

在一件作品上线之前,来自Live的更改会再次合并,并被标记为一个潜在的发布。此版本在登台环境中进行测试,如果通过测试,则从标签中获取新的Live。

如果能更好地工作的话,可以将多个工作合并到一个版本中。

这意味着用live更新开发分支是相当简单的,如果开发中的一部分工作被丢弃,那么要做的整理工作就很少了。

要从一个项目工作改为另一个项目,开发人员只需SVN将其本地工作环境切换到另一个分支即可。

正如您所描述的,我们在系统中遇到的一个问题是,dev可以很快地用prod过时,因此您不需要针对live进行开发,而且在开发阶段之前很难发现交叉依赖关系。上述解决方案解决了这些问题,同时仍然保持相当轻的重量。