SVN Web开发周期问题

Question

The organization I currently work for uses SVN for developing PHP applications. Our development cycle started out simple, doing a commit updates the web root using the post-commit hook in order to see changes right away. Than we ran into an issue with development features getting in the way of bug fixes and holding up the fixed files from being moved to production and sometimes causing issues on the prod server.

So I introduced a "release branching" schema that means all full releases are copied to their own branch, so all changes made to production needed to occur in this branch and "long term" development occurred on the trunk. The idea when this first started was to only do fixes and make the developer responsible for moving their own updates back to the trunk, but after five instances of developers blindly merging changes causing data loss, and constant development of "immediate release items" on the release branch this methodology was abandoned.

Know I am faced with a branch that is way out of sync (since some people did not "get" the trunk/branch concept and were developing on the trunk) with changes merged into the trunk from a private branch creating the potential of more lost code when merging all the changes from the past month back from the current release branch.

I have the chance to start over and enforce a proper development/release cycle of web development. SVN seems to be move geared toward "release" development (binary applications), where in this case we can go a full year without moving the full package to production.

With that background, here is my question: What Web Development SVN cycle and/or schema would you recommend for this situation? Does this require a complete methodology overhaul or am I just missing something simple?

Thanks for any ideas!

Answer 1

Here's our typical development cycle; we're "psuedo agile"; and run on a 2 week release cycle.

All projects begin on a branch from the trunk. No exceptions.

Once the project is finished, and clears code review, the developer is given the green light to merge that branch into the trunk. That way; no code that hasn't been thoroughly vetted makes its way onto the trunk. We use CruiseControl for continuous integration, so after a commit to the trunk, if any tests fail, the developer is responsible for fixing them. These fixes go on the trunk.

One week prior to the next release; we create a release "tag" (essentially another branch) and send it over to QA. If you haven't merged your code back to the trunk at this point, it's not going out with the next release. (Important note: this release "tag" is never merged back to the trunk. ever.) As QA finds bugs; they're assigned back to the developer. When the developer fixes them; their changes must be committed to both the release tag and the trunk.

When release day comes; we release everything on that tag. In the case of post release fixes; we follow the same guidelines as when we're in the QA cycle, that way if someone merges in a new project to the trunk after the release tag is cut; it's not getting inadvertently released with the emergency fix.

Lather, rinse, repeat...

This might not answer your question per se; but hopefully this serves as a good outside point of view of how you might want to set up your development process. This wasn't our original process, but rather what we've come up with over the last year or two, and in my experience, this is leaps and bounds ahead of the way we used to do it before.

If you'd like any clarifications on this; just leave me a comment and I'll update as necessary.