James

If you manage to set-up your environments in a way that your deployment process is almost all automatic, then you’ll reach a state of Deployment Zen.

The more you automate deployment, the more Agile you can be (fear of deployment makes it impossible to follow an Agile methodology where you are expected to release often – to any environment).

I think that the problem you describe has also to do with the divide between the development and deployment activities.
These are still looked at as separate pieces, and usually have different people working on each of them.
I think that’s one of the break points that limits the ability to automate the process.

At OutSystems we’ve been following the 1-click Mantra for a long time. When we include a new feature into the Agile Platform, we make sure it has zero impact on the deployment automation.
Today, deploying a web application (and rolling it back to a previous version) is really a 1-click activity.

Check this video to see how it looks like http://www.outsystems.com/evaluationcenter/DemoScreen.aspx?SelectedMovieFolderId=4506 (you’ll need to fill in a small form to see this one).

You can also take a look at this other video, which also shows the 1-click-deployment process in action and doesn’t need any sign-up http://www.outsystems.com/evaluationcenter/DemoScreen.aspx?SelectedMovieFolderId=4504

Let me know what you think!
Michel

I appreciate coming across posts like yours as it helps foster discussion around the software release process and configuration management. I’m biased to the version control and change management product for complex parallel, geographically distributed and Agile development known as AccuRev, as I am hte company’s corporate communications manager. One very simple low level feature this product provides is the ability to “Keep” a file to your local workspace as many times as you like before integrating with the team.

Let’s say you have just finished something and you aren’t ready to commit it just yet, but you want to version it. In AccuRev, you just do a Keep to create private versions. Do it as many times as you want. When you are done, you do the commit (we call it promote) and it is just as though you never had a private stream (branches in other tools) and it is just like you no longer have a private stream. So, most of the time you might do update/commit and then sometimes you will want update, keep, and commit. Some folks really like keep and they will have update, keep, keep, keep, keep, keep, and commit (and then perhaps
a bit more keep).

When you create private versions you can then do things like revert back to a prior keep, diff against prior keeps, annotate, see comments, let other folks see your private versions, access your private versions over the Web, and generally do all of the operations that are usually only done against public versions you can now do with your private versions.

If parallel development is becoming a tricky endeavor, or if you have remote teams that are always getting bogged down or you’re unable to reallocate resources or projects easily, take a peek at the tool sometime by reviewing the 2-minute demo at the link above on my name.

Thank you again for a great educational post.

Alex