views:

138

answers:

2

Where I work we have this really simple system for working on code. We have our live application servers and a development staging server which exactly duplicates the live environment. Every product/site we have exists in version control (CVS) and to develop, you check out a CVS module to your local machine, edit the code.. commit it back into CVS and then update the stage site to see your changes. When your changes have been tested and confirmed by a project manager, one of two people sanity-check the changes and push them over to the live server. It's worked like this since I started.

We know this is bad and we've known for years now. We're currently planning a major overhaul of all our development processes and I'm handling most of the software stuff (code reviews, unit testing, refactoring, etc.) and the development environment is being handled by someone else (my boss), who so far doesn't seem to have done anything. This issue is going to come to a head soon and I want to be fully prepared for when it does.

So do you do all your work on a local server before commiting the changes back to a central repository? Or do you have sandbox areas on a development server and work on your changes/bugfixes on a new branch of the project? Or something completely different?

I'm interested in the entire workflow from receiving a feature request or bug report from a project manager right through to your change making it into the live code base.

+1  A: 

I'd definitely recommend developing and testing your work on a local server if at all possible. Having to commit to version control to see your changes as you described adds an extra unnecessary step to your develop-test-debug cycle.

Simon Lieschke
+1  A: 

In a previous job the flow went like this:

  • received feature request
  • feature reviewed, spec'ed out etc. and decided that the work was to be done
  • checked out latest version of the code
  • made the change to the latest version, tested it locally
  • checked code back into CVS
  • tested code on test server
  • once the feature had been verified working etc. only then was it tagged with a version number and then released as a patch or whatever

So basically the work was all done locally, and merged with any other changes that might be being made by other developers. These changes didn't tend to conflict as you were aware what others in the team were doing/working on.

Ian Devlin