SVN web development cycle issue

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

This is always hard, whatever system you use. I doubt there's better solutions than the one you used before. Perhaps spend more time on educating your colleagues on the concept?

Answer 2

I back up Bart on this; the issue is training. You need to get your colleagues using SVN properly before your projects become too complex to otherwise manage. Your branching scheme sounds okay from your description but it is true that one person not following the plan will break it for everyone else.

Again, do it now before your projects become more complex.

Answer 3

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.

Answer 4

I can't tell if you're already using these but I highly recommend development branches. Each new feature/bug has its own branch which is copied off the trunk (or branch) that it is to eventually be merged back in to. All development and check-ins for that feature take place on the devel branch. Once the feature/bugfix is complete, the trunk is then merged into the development branch FIRST and then after basic testing and verification has been performed (standard testbed?) the development branch can then be merged into the trunk with the knowledge that everything should be in there.

The key being merging of the trunk into the devel branch to pick up any new trunk changes and then testing of the devel branch before back merging to the trunk. If every change has its own branch then developers get into the swing of things rather quickly.

AND as others have already mentioned, education of the staff. NO exceptions to education of the staff and no exceptions to each change having its own branch. Copies in SVN are cheap and easy so there's no real excuse for an exception.

Answer 5

The first order of business would be to educate your staff on how SVN works, and the methodology behind it. No matter how elegant you make your scheme, if they can't follow it, they won't.

I myself do everything in 'Feature' branches. My layout is like this:

branches/
    [feature branches]
    stable/
tags/
    [all of our releases]
trunk/

Anything that touches more than a few files, or major work, gets done in a feature branch. Small bug fixes or quick work is done straight in trunk. Throughout development, the branches are all kept in sync with trunk (trunk is merged into the branches every few days).

When release time comes, we take all the features slated for release and merge them into trunk. One feature branch is merged, checked, and if good, moved into the stable branch. Wash, rinse, repeat for all the feature branches.

Once stable is complete, it is tagged as a release, and our build system can now build Production based on the new tag.

If we need to do emergency fixes that go straight into production, the tag is checked out, corrected, and a patch is generated. The patch is applied to trunk, and then fed into Stable and any new feature branches.