在同一个项目的不同组件上工作的多组开发人员（不是共同的）的svn部署策略 [英] svn deployment strategies for multiple groups of developers (not co-located) working on different components of the same project

问题描述

我们的项目是一个支持数十个网站的内容管理系统。开发小组从一个位置开始，我们处理了一个相当标准的编码/部署策略。

我们编码了中继线，并坚持干净的中继线。每隔几天，我们将标记中继并部署到测试服务器。如果已经完成了，我们将部署到生产并继续前进。

这一切都很好，直到团队成长为止。我们经常面临的情况是，标记的修订在进行生产之前需要修复问题。负责开发这些修复工作的开发人员，我们有其他开发人员对中继线进行更改。一旦原始的开发人员的修复完成，新增的提交将不得不一路走来，进一步拖延构建，因为现在有额外的验证需要完成。

为了纠正这个问题，我们创建了一个严格用于发布的独立主干。人们将在主干线上工作，然后请项目经理或开发主管将其更改合并到发行中继线。

这工作了一段时间，直到团队得到甚至更大更多的不相交。我们拥有3至5人在4个地理位置工作的团队 - 其中一些在相同的组件上，其他组件具有不同的优先级和发布时间表。这是一个全职工作，并成为管理构建人员的噩梦。

为了解决这个问题，我们开始创建发布分支无论最新的生产标签是什么。人们只会到那里准备好测试并去制作。其他人会承诺，直到轮到合并。这就造成了构建经理和拥有该代码的人的合并和解决冲突的负担。

这个工作了大约一个星期，直到我们开始做几个高优先紧急发布。这实际上意味着我们会：

1. 在最新的生产标签之外创建一个分支


2. 添加将该分支的所有更改合并到该分支的所有更改


3. 将该分支发布到生产


4. 将该分支中所做的所有更改合并到常规发行分行。

这是每一天。有时候每天两次。

我已经尝试将这一点与一个开源项目联系起来，那里的开发人员遍布不了彼此，他们仍然似乎得到...但是，当新的稳定，经过测试，生产有价值的建筑物预计每周（或一天）数次公共消费时，这种比较会分崩离析。例如，如果Firefox的日常制作是一个错误的混乱，至少用户可以回到以前的版本或使用最新的稳定版本。对我们的用户来说不是这样。如果我们的发布不完美，他们将无法正常工作。

Backstory已完成，我现在提出了一个问题：

给定一个环境，...

1. 开发人员都在不同的组件上工作。


2. 某些组件的更改可能会在发布前等待一周，其他组件可能会等待一天的时间。


3. 应用程序是关键任务的，必须先对测试进行测试和更改。被释放。

...您可以推荐哪些建议或替代工作流程来推广更多的过程，其中绝大多数的负担不是一个人？

解决方案

组合维护和发行分支

我觉得你和我们的人有类似的要求。一个CI可以帮助您自动化，但并不能解决潜在的组织挑战。

所以你有两种类型的签入：

• 正常的非紧急代码（每隔一段时间释放一次）


• 紧急修补程序代码（发布后如果有事情发生通过没有足够的测试或客户X打电话，因为他希望按钮粉红色不紫色，他威胁要放弃合同：P）

两种情况都是不同的，你需要分开它们。你的方法已经接近一个答案，我认为，但你在做太多

让我介绍一下我们的工作：

存储库布局

  trunk（是我们的组件和全部项目）
 branches 
 | 
  -  1.0-stable-week-40 
 | 
  -  2.0-stable-week-42 
 | 
  -  3.0-stable-week-44 
标签
 | 
  -  1.0.0 
 | 
  -  1.0.1 
 | 
  -  1.0.2 
 | 
  -  2.0.0 
 | 
  -  2.0.1 
 | 
  -  3.0.0 
  

正如你所看到的，我们有一个主干开发工作。我们还建立稳定的分支机构，每两周发布一次准备和测试，我们会在所有版本上线时标记所有版本。

发布生命周期

在发布新版本之后，我们维护了分支（例如1.0），直到下一个主要版本被推出。
我们的政策是，在那段时间内，只有关键的修复程序可能会被检入该分支。他们只通过最少的测试，只需几分钟就可以通过从维护部门创建一个新的标签来发布。

在维护期间（1周后）发布），我们从我们的中继线创建一个新的分支，称为2.0。所有不太紧急的发展已经在行李箱中将自动在这个版本中。更多的东西可以添加carefuly，如来自当前活跃的维护分支的紧急修复（从1.0到2.0合并到中继线）。

另外一周过去了所有测试完成2.0分支被标记为2.0.0并发布，没有发生重大问题。 1.0维护分支将最终被放弃和删除。

这样我们可以从非紧急变更中分离紧急，并且具有相对无痛和稳定的版本。
你做的是几乎相同的，但是你从标签中分支，当你再次完成标签时。这有点多:)
从标签分支也是不好的风格。分支分支。

---

分支政策

如果您为每个分支机构写下政策，帮助团队，使他们自己做更多的事情，而不必让释放的人不断坐在他们的脖子上，诱惑他们的提交;）

我们的政策可以这样描述：

• trunk：

  
  
  
  
  
  • 不提交语法错误
  
  
  • 从维护收到合并
  
  
  • no direct
  
  



• 分支/ XX稳定

  
  
  
  
  
  • 可能会收到紧急修复
  
  
  • 应该始终释放就绪
  
  
  • 开发人员必须合并他的提交从这里到任何年轻的稳定分支
  
  
  • 如果没有年轻的稳定分支是可用的le合并到中继
  
  



• 标签/ *

  
  
  
  
  
  • 不提交
  
  
  • 用于部署
  
  

只要您尝试合并到一个方向，合并也不会成为心灵训练。 （你可能想要谷歌豆腐量表，但现在有点OT）。
看到合并由开发人员不断完成，而不是发布管理器来限制瓶颈。
虽然一个版本是现场的，并且主动维护接收修补程序，但我们已经开始准备下一个版本，将其与中继线中可能不稳定的更改隔离，并给予成熟时间。

您可能对代码保护和测试的持续时间或发布迭代的长度有不同的要求。 Adapt：）

Our project is a content management system supporting several dozen of our websites. The development group started off small and in one location, and we dealt with a fairly standard coding/deployment strategy.

We coded off of trunk and insisted on a clean trunk. Every few days we would tag trunk and deploy to the test server. If all worked out, we'd deploy to Production and move on.

That worked well for a while until the team grew. We frequently faced situations where the revision that was tagged had problems that needed to be fixed before going to Production. While the developer responsible was working on those fixes, we had other developers committing changes to trunk. Once the original developer's fixes were complete, the new commits that were added would have to go along for the ride, further delaying the build because now there's additional validation that needs to be done.

In an attempt to rectify this, we created a separate trunk used strictly for releases. People would work in the main trunk, and then ask the project manager or development lead to merge their changes into the release trunk.

This worked for a while until the team got even bigger and more disjoint. We have teams of 3-5 people working in 4 geographic locations - some on the same components, others on different components with different priorities and release schedules. This was pretty much a full-time job and became a nightmare for the person managing the builds.

In an attempt to work around that, we started creating "release branches" off of whatever the latest Production tag was. People would commit to there ONLY what is ready to be tested and go to Production. Others would commit to trunk until it was their turn to merge. That took the burden of merging and resolving conflicts off of the build manager and on to the person owning the code.

This worked for about a week until we started having to do several "high priority emergency" releases. This effectively meant that we would:

1. Create a branch off of the latest Production tag
2. Add the emergency stuff to that branch
3. Tag that branch and release to Production
4. Merge all of the changes that were made in that branch into the regular "release branch" that is sitting in QA.

This is every day. Sometimes twice a day.

I've tried to relate this a bit to an open source project where there are developers all over the place who don't even know each other and they still seem to get by... but that comparison falls apart when new stable, tested, production-worthy builds are expected for "public" consumption several times a week (or day). If Firefox's daily build is a buggy mess, for example, at least users can go back to a previous version or use the latest stable release. That's not the case for our users. If our release is not perfect, they can't work.

Backstory completed, I now pose the question:

Given an environment where...

1. Developers are all over the place and working on different components.
2. Changes to some components can wait a week before being released, others can't wait even a day.
3. The application is mission-critical and changes must be tested and stable before being released.

... what suggestions or alternative workflows can you recommend to promote a saner process where the majority of the burden is not on one person?

解决方案

Combined maintenance- and release-branches

I think you are having similar requirements like our people. A CI would help you automate but it does not solve the underlying organisational challenge.

So you have 2 types of checkins:

• normal non-urgent code (slated for release every once in a while)
• urgent "hotfixing" code (happens after a release if something slips through without enough testing or when customer X calls because he wanted the button pink not purple and he threatens to drop the contract :P)

Both cases are different and you need to seperate them. Your approach is allready close to an answer I think but you are doing "too much"

Let me describe you what we do:

Repository Layout

trunk (is our project with components and all)
branches
|
-- 1.0-stable-week-40
|
-- 2.0-stable-week-42
|
-- 3.0-stable-week-44
tags
|
-- 1.0.0
|
-- 1.0.1
|
-- 1.0.2
|
-- 2.0.0
|
-- 2.0.1
|
-- 3.0.0

As you can see we have a trunk for all the main development work. We also create stable branches for release preparation and testing every 2 weeks and we tag all releases when they go live.

Release lifecycle (generalized)

After a new release we maintain the branch (1.0 for example) until the next major release is pushed out. Our policy is that during that time ONLY critical fixes may be checked in to that branch. They go through minimal testing only and can be released in a matter of minutes by creating a new tag from our maintenance branch.

Halfway through the maintenance period (1 week after the release) we create a new branch from our trunk called "2.0". All not-so urgent development allready in the trunk will be in this release automaticly. More things can be added "carefuly" like urgent fixes that come from the currently active maintenance-branch (merge from 1.0 to 2.0 to trunk).

After another week passed and all testing was done the 2.0 branch gets tagged as 2.0.0 and released, given no major problems arised. The 1.0 maintenance-branch will be abandoned and deleted eventually.

This way we can seperate urgent from non-urgent changes and have relatively pain-free and stable releases. What you do is pretty much the same but you branch from a tag which when you'r finished you tag again. Thats a bit much :). Branching from tags is also bad style. branch from branches.

---

branch policies

It helps the team if you write down the policy for each of your branch-types enabeling them to do more on their own without having a release-guy constantly sitting in their neck and luring over their commits ;)

Our policies could be described this way:

• trunk:

  • no commits with syntax errors
  • receives merges from maintenance
  • no direct releases from this branch

• branches/X.X-stable

  • may receive urgent fixes only
  • should be "release-ready" at all times
  • developer MUST merge down his commit from here to any younger stable branch
  • If no younger stable branch is available merge to trunk

• tags/*

  • No commits here
  • used for deploy

Merging becomes also less of a mind-training once you try to merge into one "direction" only. (You might want to google for the tofu scale but thats getting a bit OT now ). See that merges are done continuously by developers and not release managers to limit the bottleneck. While one release is live and actively maintained receiving hotfixes, we allready start to prepare the next, isolating it from possibly unstable changes in the trunk and giving it time to "ripe".

You might have different requirements for the duration of code-incubation and testing or length of release iterations of course. Adapt :)

这篇关于在同一个项目的不同组件上工作的多组开发人员（不是共同的）的svn部署策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！