testing, staging, deployment processes

Lonnie Olson lists at kittypee.com
Wed Sep 21 09:35:20 MDT 2011


On Wed, Sep 21, 2011 at 8:32 AM, Wade Preston Shearer
<wadeshearer.lists at me.com> wrote:
> What about for very agile web development? Our development-to-deployment cycle is generally quite short. If we are deploying new code every day, is a new branch and tag overkill?

>>> On Tue, Sep 20, 2011 at 6:34 PM, Wade Preston Shearer
>>> <wadeshearer.lists at me.com> wrote:
>>>> 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
>>>>
>>>>

Your process is pretty good, and fairly agile already.  Some minor suggestions.
* The developer checking code should not be the same developer that
wrote it.  Possibly a code partner idea.
* Use a beta branch, it simplifies the push-guy's workflow and
maintains a better record of changes.
* Use a staging branch, same reasons.
* Use release tags, or maintain good documentation on what versions
were released when, elsewhere.
* Automate as much of the push-guy's workflow as possible.

Benefits:
* Code partners make communication, code review, and testing fast and
efficient.  More agile.
* Branches keep good logs of what gets merged and when.  Quick
identification of blame means faster time to fix.  More agile.
* Branches make deployments (push-guy) simpler and easier to automate.
 Faster deployments, more agile.
* Very fast releases (daily or more) may be too expensive to tag w/
SVN, So good logs of deployment times and versions deployed, beyond
emails, are critical to make locating and fixing bugs faster.  More
agile.


More information about the PLUG mailing list