使用subversion部署CFML应用程序的策略？

Question

我们的团队使用SVN来跟踪我们的日常开发。但是，在部署到QA和Live时，我们不确定该怎么做。

听说詹金斯，但不确定我们是否想要处理学习的开销，除非它真的能帮助我们实现我们想要的东西。

如何使用分支或标记：

• 易于恢复到最后的工作状态
• 跟踪正在部署的内容，何时以及正在部署的内容
• 如何将更新推送到QA，然后再推送到

现在，每个开发人员都会将所有内容都提交给Head。因此Head虽然稳定，但不能保证稳定。

使用符号链接？ IIS虚拟文件夹？指向一个版本而不是覆盖直播？或者Live应该是SVN的导出？

有什么建议吗？谢谢！

我有点害怕SVN中的分支/合并，因为如果SVN说错了什么，我们常常卡在那里。

有多种合并方式，如果开发人员选择了不正确的方式，那么svn就会被搞砸了，在SVN中撤消它似乎很容易。

我们现在不想使用Git ......

Answer 1

首先，Jenkins是一个自动构建服务器，由于ColdFusion应用程序没有编译，因此它本身不会对svn产生任何帮助。我确信CF应用程序有一些引人注目的功能，但就像你说的那样，学习曲线可能不值得付出努力。

我们拥有与您相同的dev / QA / Prod tiers，并且svn非常适合我们的需求。这个过程是这样的：

1. 开发人员使用Subclipse或TortoiseSVN检查HEAD分支
2. 开发人员向HEAD签入功能。
3. 系统管理员在功能需要测试时检查HEAD到QA服务器
4. 如果HEAD通过QA，则会创建一个分支以进入生产阶段。这个分支只是经过质量保证审核的HEAD的副本。我们将分支文件夹命名为prod_2_7_2012或类似名称。
5. sysadmin使用svn将项目签出到生产服务器。有时完全出口＆amp;如果svn不可用，则完成覆盖。
6. 开发人员使用subclipse / tortoise查看prod分支。他们现在在开发环境中拥有2个应用程序副本。
7. QA检查了prod分支。
8. Devs可能只会对prod分支进行紧急错误修复，这将由QA审核。
9. 如果修正了错误修正，则使用svn update或export更新prod。
10. 错误修正也适用于HEAD并提交给HEAD。这种重复工作，但减轻了合并的麻烦。
11. 当HEAD中的新功能准备好生产时，重复该过程并存档旧的prod分支。

没有合并。

Answer 2

最好的办法是研究所有推荐的分支和合并最佳实践。 这是关于策略的MSDN文章，但有更多的意见： http://msdn.microsoft.com/en-us/library/ee782536.aspx

最好的办法？找出最适合您的团队并使用它的东西。一旦弄清楚了自己想做什么，就要找出构建和部署策略。

最简单的模式是使用Main进行开发，在Main的每个版本上进行分支。这样，您的新开发和错误修复就会分开。从Release发布反向集成以在需要时获取bug。

Answer 3

还有一个小问题是经常提交和更新。一旦开发人员在处理某个功能（假设有单元测试）或错误修复时，他们应该提交所有单元测试。在我看来，他们应该更频繁地更新。

由于陈旧的存储库，解决一堆冲突没有什么能够扼杀生产力。

Answer 4

我的团队使用/ trunk应该能够随时发送到生产的方法。我们在单独的分支中进行所有开发（功能开发和错误修复），并在发布新版本时从主干创建标记。这些标签一旦创建就永远不会改变。

只有在针对该功能完成测试并且整个项目的所有单元测试通过后，才会将分支合并回主干。在开发过程中，我们通常每天从/ trunk合并到我们正在工作的分支机构，以保持我们的开发分支机构赶上/ trunk。

我已经看到了从标签到生产服务器获取代码的几种不同方法。我们目前采取的路线是使生产服务器只是一个工作副本（签出到特定标签）并配置Apache不提供.svn文件夹中的文件。这样，当新版本出现时，就像对新标签执行svn switch命令并重新启动我的应用程序一样简单。此外，它使SVN中的所有内容保持整齐分离，因此如果某些内容超出您的质量检查流程，您就可以轻松回滚到之前的代码。

不要害怕合并。如果你跟上它并且不让它在合并之间持续数周就会萎靡不振，这没什么大不了的。