testing, staging, deployment processes

Wade Preston Shearer wadeshearer.lists at me.com
Tue Sep 20 19:34:48 MDT 2011

I am considering ways to improve our testing, staging, and deployment processes. We have multiple sites being worked on by multiple developers. I would like to hear how others (especially large teams) are doing it.

Our current process works like this:

1. developer writes code, tests, and then commits to trunk

2. developer submits a push request to the "push-guy"

3. push-guy updates beta server (working copy of trunk) with files in request and returns note to developer

4. developer checks code on beta server and returns note of success

5. push-guy rsyncs files to staging server and returns note to developer

6. developer checks code on staging server and returns note of success

7. push-guy rysncs files to production cluster and returns note to developer

8. developer checks code on production server(s) and returns note of success

This works well for a single developer, but once you have multiple developers submitting requests, testing, and verifying, it gets really hard to manage. And, it gets especially difficult when you have certain files that are found buggy and shouldn't be pushed with the rest of the updates.

To help clarify things and provide ways to roll back easier, we have been considering implementing a beta branch and a stable tag. This would allow us to be okay with trunk being unstable and only merge over files that should be deployed. The beta server would be a working copy of the beta branch and the staging server wold be a working copy of the stable branch. We would then rsync from staging to the production cluster.

This doesn't help much with management of things though (submission of items for deployments, testing, verifying that it's been peer-reviewed, tested, etc.) and merging adds a lot of extra steps (merge, commit, merge, commit).

What are you doing? What systems have you heard of large teams using?

More information about the PLUG mailing list