testing, staging, deployment processes

S. Dale Morrey sdalemorrey at gmail.com
Wed Sep 21 10:24:31 MDT 2011

And if you are really agile make sure to use git.  I've found that git
is much more conducive to an agile workflow in an office setting than
SVN is.
When I was working in arizona we increased productivity by 75% and
reduced reworks by 50% simply by switching to git since it matched the
workflow much better.  On the otherhand if you are a large org with
waterfall, SVN fits the typical model much better.

Just make sure your software development model matches your
organizations style and accountability models and not the other way

Too many projects fail when an agile company tries to do it the
waterfall way and vice versa.

On Wed, Sep 21, 2011 at 9:35 AM, Lonnie Olson <lists at kittypee.com> wrote:
> 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.
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */

More information about the PLUG mailing list