Continuous Deployment – Going for brilliant products

Continuous Deployment starts to be a very popular buzz word and especially the lean start-up scene seems to be taking both the hype factor out of it as well as enjoying the benefits that CD offers.

All the major web services like Facebook, Twitter, Google, Flickr, WordPress, etc; they all utilize CD, even though everyone has their own adaptation of it, they all share the same principles: deploy small, deploy often, learn and react. This simplification already gives us a hint on what’s it all about, it’s not about a cool engineering practice, it’s about speeding up your delivery, boosting quality and it provides possibilities for large enterprises to gain start-up style agility.

The web services development suits well for fast paced continuous integration and deployment since it is a rather new industry that has optimal setup to support efficient software development as well as such  competitive and adaptive market where you need to be fast and responsive. (Does lean and agile ring a bell) The web based services can be seen as forerunners in Continuous Deployment but are they the only one’s who can benefit from it?

“We can’t do that since we are so complex and we need to verify that the product still works after upgrade and we need to train our personnel for the new functionality” This must be the most common excuse why continuous deployment is not viable to some product or company. But looking at the already mentioned big companies using CD,  they do work in an environment that expects them to be accessible all the time, extremely reactive to: fixing any faults found and exceeding the new requirements from customers. Now I’m puzzled, how come there is something so complex that it requires that you make only big bang integration and fix faults mostly in planned releases that drop in here and there with slow and steady pace?

It’s good to point one more big benefit into the list “why CD?”; with Continuous Deployment the integration effort is very different when compared to big bangs, you can do software deployments as part of your normal operations, not as a separate integration project that requires (at least) system and configuration updates as well as possible staff training. Not to even mention the lead times that this setup creates. Waste, some might say.

Looking from that angle going for going for small changes that are deployed often sounds something like, umm awesome?

Taking into account that this world still hasn’t gone black and white, we of course need to adapt our thinking to suit the field of industry and deeply understand the customer view. Maybe it’s not possible for everyone to deploy a new version of the system into live use every second but is the only option slow paced big bang approach?

Deploy small, deploy often. Learn, Adapt.

Go for brilliant products.

This entry was posted in Agile Thinking, AgileTesting, All, CI, Continuous Deployment, Continuous Integration, Leadership, Lean, Transformation, Uncategorized and tagged , , , . Bookmark the permalink.

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