Deploying Desktop-based Software Continuously

January 18, 2010

Of all the Lean Startup techniques, Continuous Deployment is by far the most controversial. Continuous Deployment is a process by which software is released continuously throughout the day – in minutes versus days, weeks, or months. While the biggest waste in manufacturing is created from having to transport products from one place to another, the biggest waste in software is created from waiting for software as it moves from one state to another: Waiting to code, waiting to test, waiting to deploy. Reducing or eliminating these waits leads to faster iterations which is the key to success (Boyd’s Law).

Last week, I wrote-up a detailed case-study which you can find on Eric Ries’ startuplessonslearned blog. In it I chronicle my transition from releasing software once a week to releasing software continuously.

Continuous Deployment makes releases non-events but the greatest challenge is getting comfortable with releasing all the time.

While it is somewhat easier to continuously deploy web based software, with a little discipline, desktop based software too can be built to flow.

My continuous deployment process is built on the following principles:

  1. Don’t push features

  2. Code in small batches

  3. Prefer functional tests over unit tests whenever possible

  4. Always test the User Activation flow

  5. Utilize automagic software updates

  6. Build in alerts and monitoring

  7. Build in application level diagnostics

  8. Tolerate unexpected errors exactly once

I often hear the belief that you need a massive team to pull off continuous deployment. I would argue that the earlier in the development cycle and the smaller the team, the easier it is to implement a continuous deployment process. If you are a start-up with a MVP, there is no better time to adopt a continuous deployment process than the present. You don’t yet have hundreds of customers, dozens of peers, or dozens of features. It is a lot easier to lay the groundwork now with time on your side and you need the smaller and faster build/measure/learn loops more than anyone else.

Read the detailed case-study on Eric Ries’ blog.

Related posts:

  1. 3 Rules for Building Features in a Lean Startup

Tagged as: continuous deployment, lean startup

  • Ok, I got Continuous Deployment working now. I update after every new feature now. Plus I'm using some new software.
  • Even when my application is working in development, a lot of times bugs show up when I deploy to production. A lot of null reference exceptions. It may have to do with permissions on production - I'm not really sure.
  • Why kill the hype?
    Sure, continuous deployment is an effective development strategy - but it kills the impact of 'launch hype'.

    Building momentum towards the next big software release generates hype - and hype is a powerful dynamic that can multiply marketing performance.

    Sure, if your pricing model is subscription based then continuous deployment is natural. But for every other desktop app that is not, you're going to want to leverage launch hype to help drive new sales.

    To solve the challenge (of implementing continuous development for an 'off the shelf' software product) we would need to achieve a certain harmony with the overall scope of the business model. And I think you can do that by implementing Continuous Development principals primarily for patches & updates.
  • Yes, there is an important distinction to be made between a software release and a marketing release. Continuous deployment addresses the former and doesn't dictate what is delivered and to whom. Patches and updates to live software are certainly fine as is delivering the next "marketing release" continuously to an internal audience till public launch.

    That said, other forces like the need for quick learning/feedback loops can override the potential impact of "launch hype" especially in a startup where a lot is unknown. I am not saying a marketing launch is not a powerful tool, but it's power is usually overstated. Personally I'd take a soft-launch is it lets me build the "right" product, than a big marketing launch that has low or no traction.
  • Ruang - What do you mean by debugging? Troubleshooting problems in production?
  • Thanks for listing the testing applications you use. The biggest problem I have with continuous deployment is the debugging.
blog comments powered by Disqus

Previous post:

Next post: