使用 subversion 部署 CFML 应用程序的策略？
我们的团队使用 SVN 来跟踪我们的日常开发。然而，当涉及到部署到 QA 和 Live 时，我们不确定该怎么做。
听说过 Jenkins，但不确定我们是否想要处理学习它的开销，除非它确实能帮助我们实现我们想要的目标。
如何使用 Branch 或 Tag 来：
- 轻松恢复到上一个工作状态
- 跟踪正在部署的内容、部署时间和部署内容
- 如何将更新推送到 QA，然后推送到 Live
现在，每个开发人员只需将所有内容提交给 Head。所以Head虽然稳定，但并不能保证稳定。
使用符号链接？ IIS虚拟文件夹？指向一个版本而不是覆盖实时版本？或者Live应该是SVN的导出？
有什么建议吗？谢谢！
我有点害怕 SVN 中的分支/合并，因为如果 SVN 说有问题，我们经常会陷入困境。
合并的方式有很多种，如果开发者选择了不正确的方式，那么 svn 就会被搞砸，而且在 SVN 中撤消事情似乎很容易。
我们现在不想使用 Git...
Our team uses SVN to keep track of our day-to-day development. However, when it comes to deploying to QA and Live, we are not sure what to do.
Heard of Jenkins but not sure if we want to deal with the overhead of learning that, unless it would really assist us on what we want.
How to use Branch or Tag to:
- ease of reverting to last working state
- keep track of what's being deployed, when and what exactly being deployed
- how to push updates to QA, then to Live
Right now, every developer just commit everything to Head. So Head, although stable, is not guaranteed to be stable.
Use symbolic link? IIS virtual folder? to point to a version instead of overwriting for live? Or should Live be an export from SVN?
Any suggestion? Thanks!
I'm a little scared of Branch / Merging in SVN 'cause if SVN says something's wrong, we often stuck there.
There are multiple way of merging, and if the developer choose the incorrect way, then the svn will be screwed, and it does seem easy to undo things in SVN.
We don't want to use Git as of now...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，Jenkins 是一个自动构建服务器，并且由于 ColdFusion 应用程序不被编译，因此它不会比 svn 本身更有帮助。我确信 CF 应用程序有一些引人注目的功能，但正如您所说，学习曲线可能不值得付出努力。
我们拥有与您相同的开发/质量保证/产品级别，并且 svn 非常适合我们的需求。这个过程是这样的：
没有合并。
First, Jenkins is an automated build server, and since ColdFusion applications are not compiled, it will not help you any more than svn by itself. I'm sure there are some compelling features that are available for CF apps, but like you said, the learning curve might not be worth the effort.
We have the same dev/QA/Prod tiers as you do, and svn suits our needs just fine. The process goes something like this:
No merging.
最好的办法是研究所有推荐的分支和合并最佳实践。
这是关于策略的 MSDN 文章，但还有更多的观点：
http://msdn.microsoft.com/en-us/library/ee782536.aspx ？
最好做什么 找出最适合您的团队的方法并加以利用。一旦确定了自己想要做什么，就可以确定构建和部署策略。
最容易遵循的模式是使用 Main 进行开发，在 Main 的每个版本上进行分支。这样你的新开发和错误修复是分开的。从发布版本进行反向集成，以便在需要时发现错误。
Best thing to do is research all the recommended best practices for Branching and Merging.
This is the MSDN article regarding strategy but there are far more opinions:
http://msdn.microsoft.com/en-us/library/ee782536.aspx
Best thing to do? Figure out what best fits your team and use that. Once you have figured out what you want to do, then figure out your build and deploy strategy.
The easiest pattern to follow is use Main to do development, branch on each release from Main. That way your new development and your bug fixes are seperated. Do Reverse integration from Release to pick up your bugs when needed.
还有一件小事没有被注意到，那就是经常提交和更新。一旦开发人员在处理某个功能（假设有单元测试）或错误修复时获得通过的所有单元测试，他们就应该提交。我认为他们应该更频繁地更新。
没有什么比解决由于陈旧的存储库而导致的一堆冲突更能降低生产力了。
One more small thing that hasn't been noted is to commit and update often. As soon as a dev gets all the unit tests to pass when working on a feature (assuming that there is unit tests) or bug fix they should commit. They should update even more frequently in my opinion.
Nothing kills productivity like resolving a bunch of conflicts because of a stale repository.
我的团队使用的方法是 /trunk 应该能够随时发送到生产环境。我们在单独的分支中进行所有开发（功能开发和错误修复），并在发布新版本时从主干创建标签。这些标签一旦创建就永远不会改变。
仅在针对功能完成测试并且整个项目的所有单元测试都通过后，分支才会合并回主干。在开发过程中，我们从 /trunk 合并到我们通常每天工作的分支，以保持我们的开发分支跟上 /trunk 的进度。
我见过几种将代码从标签获取到生产服务器的不同方法。我们目前采取的方法是使生产服务器只是一个工作副本（签出到特定标签）并将 Apache 配置为不提供 .svn 文件夹中的文件。这样，当新版本出现时，就像对新标签执行 svn switch 命令并重新初始化我的应用程序一样简单。此外，它使 SVN 中的所有内容都整齐地分开，因此，如果某些内容错过了 QA 流程，您可以轻松回滚到以前的标签。
不要害怕合并。如果你跟上它并且不让它在合并之间连续几周萎靡不振，那没什么大不了的。
My team uses the approach that /trunk should be able to be sent to production at any time. We do all development (both feature development and bug fixes) in separate branches and create tags from trunk when we release a new version. These tags never change once they are created.
Branches are merged back into trunk only after testing has been completed against the feature and all unit tests for the entire project pass. During development, we merge from /trunk to the branch we are working in usually daily to keep our development branches caught up with /trunk.
I've seen a couple of different approaches to getting code from a tag to the production server. The route we're taking at present is to make the production server simply a working copy (checked out to a specific tag) and configure Apache to not serve up the files in the .svn folders. That way when a new version comes out, it's as simple as doing an svn switch command to the new tag and reinit'ing my app. Furthermore, it keeps everything neatly separated in SVN so you can easily roll-back to previous tags if something slips past your QA process.
Don't be afraid of merging. If you keep up with it and don't let it languish for weeks on end between merges it's no big deal.