2

I am using SVN for source code management on a Classic ASP app that I develop/support. I maintain several versions of the app as required by my company:

  • Discovery/playground version - where I do all the work. My Working Copy
  • Dev/Test versions (no access to these sites/servers)
  • Live version (no access to these sites/servers)

Here is when I run into trouble:

  1. Work is done on Project A and is committed
  2. Project A is promoted to Dev/Test using an export from the log
  3. There is a problem with Project A and it is stalled in Dev/Test
  4. Project B comes along, is prepared and committed
  5. Project B now builds on Project A, but there are parts of Project A not ready for prime time

Short of just "be careful not to screw anything up," is there anything I can do to make sure that parts of projects can stall in the development process without holding up everything?

The necessity of a web server in the process seems to be causing me problems. I know that I can branch Project A when it goes to Dev/Test, and then merge it back to the trunk when it is live. Also that way I can revert my playground from before the branch and do Project B without anything from Project A having a chance to go live accidentally. However, then I can't play with Project A on my playground site. Do I have to spawn a new playground site for each branch?

I know that this is probably too specific to my situation with all its constraints, but I'm hoping somebody else has experienced something similar to my situation.

Thanks!

EDIT:

Here is my current solution: Maintenance fixes - changes that could go immediately to production - can get made in WC and committed to the trunk. Anything that has dependencies on a project gets branched. Working copies along the test path can be switched to point to that branch to test a project. Branches have to be kept up to date, and we can use commit hooks to keep people notified. When a branch is ready to be deployed to production, it gets merged back to the trunk and deployed.

This makes sense and would work, right?

Don Zacharias
  • 1,544
  • 2
  • 14
  • 31
  • How many copies of the "Live Version" exist in production? One? More than one? – braveterry Feb 25 '10 at 22:12
  • 1
    It sounds to me like you would potentially need a playground site per branch. If cutting new branches is too expensive (whether that's at the VCS level or in terms of setting up playground sites) that is intrinsically an argument that you (corporately) should consider changing your setup so it becomes cheaper - though I appreciate this can be hard ... – crazyscot Feb 25 '10 at 22:21
  • @braveterry - 2 exported copies of the project live in production, on load balanced servers. @crazyscot - Before I typed it earlier, I hadn't really thought of creating a new site each time we branch. But it might make sense. Thanks both! – Don Zacharias Feb 25 '10 at 23:07
  • Sounds like you have a good starting strategy. Remember to merge any production fixes in the trunk back down the other branches so they have the fix too. No doubt after using it for a little while you'll find out which bit of the branching and merging is taking the most time and look to adapt and optimise if possible. If you're putting the thought in now it's going to pay off long term. It's never set in stone, ours evolves every now and then when we realise there's a better way. The biggest thing I've learnt is that every system is different and one size certainly doesn't fit all. – Dave Anderson Mar 02 '10 at 10:19

1 Answers1

1

We control our code base with one instance of SVN and use another to control the environments and the contents of the web servers for each testing stage and eventually production. Having the history of what has been on each environment has saved us a number of times. Keeping your log messages meaningful will definitely pay off.

I export from the automatic build sent to our Dev server onto a checked out version of the System Test files and then commit the changes to that. Updating the servers in the web farm is just a case of updating to the HEAD revision on all the boxes. Staging is updated using an export from System Test and then Production is finally updated from a Staging export. Some parts of this are scripted but having manual oversight is convenient. Probably the hardest bit is ensuring the config files are correct for each environment but if you aren't changing it you don't deploy it.

You will probably still want to get to grips with feature branches or release branches and the necessary strategies to recombine the source. You may need to bug-fix something in Production you never expected no matter how good your testing strategy.

One thing to note is not using client version 1.6x with a 1.5x SVN server as this is playing havok with our merge processes until we upgrade see; http://ferventcoder.com/archive/2009/06/10/subversion-1.6-tree-conflicts-and-the-incompatibility-of-subversion-1.5.aspx

EDIT:

Each server in our deployment environment has the TortoiseSVN client installed so that the sysadmins have a GUI for updating the checked out repository.

I have also made them some scripts that use the SVN command line utilities to update a few repositories on the servers with an automated job. This allows our content team to commit files to their local copies of the server resources folder and then this updates every hour. They only have access to a that specific set of folders which we control with the auth file on the SVN server.

We have two separate machines that actually have SVN server installed which are backed up daily. One is for repositories of source code and the other one for the eventual builds that are deployed in each environment. It does mean we have a complete duplicate repository for the deployment in each environment but storage isn't an issue.

Community
  • 1
  • 1
Dave Anderson
  • 11,836
  • 3
  • 58
  • 79
  • So Staging and Production don't have SVN installed, right? I have thought of using this approach but even then it would take some campaigning in my company. As it stands now I commit my code, export changed files, then zip them up and hand them off to a sysadmin to install in each environment. Thanks for the great advice! – Don Zacharias Feb 25 '10 at 23:13
  • Thanks Dave! See my edit to my question...I have thought about this some more and have a potential solution that I'd like feedback on. – Don Zacharias Mar 01 '10 at 19:01