更好的发布管理策略？
我在一家制作网络工具的公司工作。作为我工作的一部分，我接受了该产品的发布工程任务（这是我以前从未做过的事情）。我已经使用 SVN 设置了以下系统（抱歉，在有人建议切换到 GIT 或 perforce 或无数其他选项之一之前，我们不能使用另一个存储库！）
Trunk 是始终位于生产服务器上的内容 有 2 家分店随时营业 1) 维护版本。此内容每周三发布 2）冲刺分支。这是每周发布的（周三，该周的维护分支）
在发布之前，我将那周的分支合并到主干中。
我发现运行 svn merge 时，它通常会在合并时产生大量问题。因此，我们改为每周举行一次手动合并会议，该会议需要 10 分钟到 1 小时不等，其中我实际上将系统上的 2 个目录进行 winmerge，并询问每个开发人员“这是您的更改吗？我们应该使用哪个版本的代码保持？”
这个系统绝对不理想。
有人可以建议更好的东西吗？
I work for a company that makes a web based tool. As part of my job, I was given the task of release engineering for this product(something I had never done before). I've setup the following system using SVN(Sorry, we can't use another repository before someone suggests switching to GIT or perforce or one of the myriad of other options!)
Trunk is what is on the production servers at all times
There are 2 branches open at any given time
1) Maintenance release. This is released every Wednesday
2) Sprint branch. This is released by weekly(on Wednesday with that weeks maint branch)
Prior to release I merge that weeks branches into the trunk.
I have found that when running svn merge, it usually creates a ton of problems when it merges. We have thus switched to a manual merging meeting once a week, which takes anywhere from 10 minutes to 1 hour, where I literally winmerge the 2 directories on my system and ask each developer "was this your change? which version of this code should we keep?"
This system definitely is NOT ideal.
Can someone suggest something better?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您的主干分支应包含所有最新的开发代码，其中包括新的和未经测试的功能以及来自其他分支的任何代码。将所有代码合并到此分支中非常重要。
当您准备好（或认为您准备好）进行测试时，请在主干分支上创建一个稳定分支。仅使用此分支来测试和修复错误。不要在此处向您的应用程序添加任何新功能或改进，否则可能会破坏您现有代码的稳定性。不要忘记将此分支中所做的更改合并到您的主干分支中。
当您准备好发布时（测试已完成），请从稳定分支创建一个发布分支。如果在生产中发现错误/问题，这是您发布到生产中并维护/支持的分支。与稳定分支一样，不要向该分支添加任何新内容。该分支通常被标记以便在生产中识别它。不要忘记将此分支中所做的更改合并到稳定分支中，以便从稳定分支创建的其他发布分支可以从所做的任何错误修复中受益。
分支层次结构将如下所示：
使用此层次结构，您的开发团队可以在主干分支中自由开发，而稳定和发布分支允许维护应用程序的当前和以前版本。
Your trunk branch should contain all of the latest development code, which includes new and untested features and any code from other branches. It is very important that all code gets merged into this branch.
When you're ready (or think you're ready) for testing, create a stable branch off of your trunk branch. Use this branch for testing and fixing bugs only. Do not add any new features or improvements to your application here, or it might destabilize your existing code. Do not forget to merge changes made in this branch into your trunk branch.
When you're ready to release (your testing is complete), create a release branch off of your stable branch. This is the branch you release into production and maintain/support if bugs/issues are found in production. As with the stable branch, do not add anything new to this branch. This branch is usually tagged in order to identify it in production. Do not forget to merge changes made in this branch into the stable branch, so that other release branches created from the stable branch get the benefit of any bug fixes made.
The branch hierarchy will look like the following:
Using this hierarchy, your development team is free to develop in your trunk branch, while the stable and release branches allow for maintaining current and previous versions of your application.
“在任何给定时间都有 2 个分行营业”这句话对我来说很麻烦。至少在我的实践中，分支是为了在发布之前稳定或修复错误而创建的，而且它们通常是短暂的。
我的问题是 - 你用后备箱做什么？它不应该是生产中的内容，而是生产应该运行标记（因此发布）的版本。
据我所知，您的合并问题是自己造成的。
The statement "there are 2 branches open at any given time" is troublesome to me. At least in my practice branches are created for stabilization before a release or for bug fixing, and they are usually short lived.
My question is - what do you use the trunk for? It should not be what is on production, rather production should be running a tagged (therefore released) version.
Your merge problems are self-inflicted, as far as I can see.
首先，对不起！我不羡慕你的地位。
我曾在一家国际银行工作，为《联邦卡法案》进行网页重新设计。和你的情况一样，只是规模可能大得多。我们有 3 个人除了按照非常相似的时间表进行发布管理之外什么也不做。使它可行的原因是（在几周内我一次处理了几百个文件）是开发人员合并到主干，然后将主干作为副本部署到生产环境......我们没有直接检查进入生产。因此，从发布的角度来看，您可能会帮助开发人员签入他们的工作（进行“更新”或回答“这是正确的版本吗？”真的有什么区别）但是您并不是盲目地选择哪个更新应该上线，这似乎是一个大问题。当然，开发人员可能会抱怨一点，但处于这个位置确实还不错。如果您愿意回答可能出现的任何问题，应该没问题。它适用于我们在全国 4 个地点工作的 1,200 多名开发人员。
这给你带来的另一件事是测试时间。如果代码在上线之前没有合并，如何在更大的系统环境中进行测试？我当然希望答案不是它没有经过测试！
First of all, SORRY! I don't envy your position.
I worked for an international bank doing web redesigns for the Federal Card Act. Same situation as you, only likely on a far larger scale. We had 3 people that did nothing but release management on a very similar schedule. The thing that made it do-able (in some weeks I worked with a couple hundred files at a time) was the fact that the developers merged to trunk, then trunk was deployed to production as a copy....we didn't check directly into production. So, from a release standpoint, you might be helping corral developers to get their work checked in (what's the difference between doing a "update" or answering "is this the right version?" really) But then you're not blindly choosing which updates should be going live, which seems like a major problem. Sure, developers might complain a bit, but having been in that position it's really not too bad. And if you make yourself available to answer any questions that might come up, it should be ok. It worked for the 1,200-odd developers we had working in 4 locations nationwide.
The other thing that this buys you is time to test. If code isn't merged before it goes live, how can it be tested in the context of the bigger system? I sure hope the answer isn't that it's not being tested!
这种情况下理想的分支策略是。主干的最新开发，对于每个版本都从中切出一个分支，并将其称为维护版本分支。但是，在您的情况下，维护发布发生在主干中。最新的发展发生在分支机构。
将分支策略放在一边。以下是改善当前状况的一些建议。
正如您所说，与生产相关的更改首先发生在主干中，我认为这将是最小的。那么为什么不经常将每个与生产相关的更改合并到这几个其他开放分支中呢？我想说一天一次，也可以更频繁或更频繁。你就能更好地判断。这也能让开发人员更好地了解生产中发生的变化，减少冲突。此外，如果存在冲突，这将由分支上的开发人员自己处理。
你可以想出某种框架
应该能够定义哪些分支需要在主干中进行提交。
可以有一个提交后挂钩脚本，它将检查提交是否在主干中，并立即与分支进行 svn 合并，看看它们是否存在冲突。
如果合并成功，则提交更改。否则，将信息邮寄给您和提交该信息的相应开发人员（这取决于您希望如何处理此问题）。
The ideal branching strategy for this scenario is. Latest development in trunk and for every release cut a branch out of it and call it a maintainance release branch. However in your case maintainance release happens in trunk. Latest development happens in branch.
Keeping the branching strategy aside. Here are some suggestions to improve the current situation.
As the you say production related changes first happens in trunk, I assume it would be minimal. So why not you merge every production related change into these couple of other open branches on a frequent basis. I would say once a day, it can also be more frequent or less frequent. you will be able to better judge. This would also give better heads up to the developers the changes happening in production, reducing conflict. Also if there is a conflict this would be handled by the developers themselves on the branch.
You can think of coming up with some kind of framework
Should be able to define which are the branches which requires the commits made in trunk.
There can be a post commit hook script which will check if the commit is in trunk and do a svn merge right away with the branch and see if their is a conflict.
If the merge is successful, then commit the changes. Else mail the information to you and the appropriate developer who committed it(it depends on how you would want to deal with this).