Deploy Early and Often

I’m currently sitting on the sidelines of a project watching a bit of a train-wreck in action. The problem isn’t because the code is bad, or because the people delivering the project are poor developers, but rather because an important step was missed at the beginning of the project – deployment.

I am a firm believer that every project should, as its first step clear the throat of its deployment pipeline. You might think that it is important to deliver large wads of functionality early in the project, but it isn’t.

Experience tells me that you can have the best possible code base, but unless you exercise the deployment muscle regularly you are going to end up with a long and protracted deployment headache at the end of the project where you encounter every possible deployment issue.

Unfortunately it was too late to side step that for this project because predictably, the thing blowing out the schedule is deployment headaches.

By deploying early you force all the environments that your code is promoted through to snap to shape. My recommendation for teams starting out is that their first release should be light on features but heavy on work to make sure you can release within a few hours.

Of course having the right tools for the job can make this a bit easier and its one of the reasons that we developed TFS Deployer.

4 thoughts on “Deploy Early and Often

  1. Rory Primrose

    I totally agree.

    I think the same applies to reviews and testing as well. They are too often left until the end when they will delay either deployment or something undesirable gets signed off for prod because they do not have time to go through the “correct” process.

    The deployment issue you have mentioned is often identified as a technical issue but it (along with reviews and testing) is really a project management issue. It is probably a bit too easy to blame the techs for deployment problems, but the whole project process must allow them to adequately do their job in the first place.

  2. Steven Nagy

    This sits well with the Agile way. But unfortunately teams fail to identify that release management is something that needs a lot of attention. It might be worth coming up with a list of things that every team should do before they write their first line of code.

  3. Luke

    When in doubt, ramp your project up in the following team order:
    Testers
    Builders
    Developers

    That way you have a better chance of finding the nasty surprises earlier rather than later.

  4. Hyacinth Broadchest

    MSF is really good on this. The balanced team of six roles, one of which is Release Mgmt. It is a great model, and works really well when you have the right people in the roles.

    I once filled the programme mgr role in an MSF team on some quite big projects and the model was a huge plus.

    Only problem there was that the Product Mgr was the CEO, so when he stood up and started shouting the democratic, flat, role-based model tended to evaporate.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s