TL;DR faster deployment cycles need leaner organisational structures and less systems in your DTAP environment, not more.

The fast pace of software engineering is on us. Books like Continous Delivery tell us that releasing each week, each day, even each hour is becoming reality and having your business wait for a month, a quarter or a year is simply not acceptable anymore.

Kent Beck, author of several books on better software development like Extreme programming
also shows some common software practices that change when the release cycle of the software gets accelerated.

Here’s an extract of the video http://www.youtube.com/watch?v=KIkUWG5ACFY.

The first described changes are from Annual to Quarterly:

Would there really still exist software that is used by customers that is only released yearly? The only software that is released so uncommon are probably desktop operating systems and than only the initial versions of those. We all know we regurlarly get updates pushed of OS’es, not only on desktops, but also new OS’s on our tablets and mobile devices.

Still, a lot of practices need to be in place to get from annual to quarterly releases.

• Automated acceptance tests: it’s impossible to have a testing team test a full month on all the features anymore. There must be some form of automation to reduce the same manual tests every quarter.
• Refactoring: There is no time to rebuild entire components of your software. That’s way to costly. Refactoring must be in place to continually enhance the build software and keep earlier proven code in place.
• Continuous Integration: long integration phases between frontends, midoffices and backends can’t be done. Integrate continuously.
• Subscription: receiving yearly sells for the software is not feasible anymore with shorter release cycles. There should be other ways of receiving money for the build software so that the software can be regurarly polished.

  

  

  When software is to be released each month or even each week, there are much more changes an organisation has to swallow.

  • +Developer testing: Developers have to take responsibility on the delivered quality of the code and can not rely on a separate Q/A department anymore. All changed code is to be tested.
  • +Stand-up meetings: plannings are becoming daily, that is why longer estimations are not feasible anymore.
  • +Cards on a wall: teams need to visualize their process. Scrum is a good candidate.
  • +Pay per use: letting customers pay each month for an upgrade of the software will not work anymore. This is probably why license fees for software became popular. Having a webshop and letting customers pay for the software ‘as a service’ is the more common and logical thing to do, that way software is what it should be: just a tool to meet an end.
  • -Q/A Department: No separate Q/A departments and no separate test-phases anymore. Filing bugs, waiting for the developers to be available, etc etc it’s just too cumbersome and direct communication is so much more effective. Bugs or misunderstood features are extremely expensive and should be avoided by having cross functional teams working in an informative workspace.
  • -Multiple deployed versions: can’t maintain multiple versions. Just have one version that is continuously being improved. This also leads to configurable software. For example building one framework to support multiple different configurations of your software as opposed to having multiple different versions of your software. This way at Travix we are able to support different configurations for different websites like budgetair.fr, budgetair.co.uk, cheaptickets.de, vliegwinkel.nl, frontends that are all build on the same underlying configurable framework. Having software switches is common.
  • -Design document: the hand off between designers/architects who write wanted features in documents simply does not adhere to one of the core agile practices: The most efficient and effective method of
    conveying information to and within a development
    team is face-to-face conversation.

  • -Change requests: communication overhead is too long, too much overhead.
  • -Separate analysis team: software can only be written by developers if they understand what is to be build themselves. Having separate analysis teams without developers is therefore not useful.
  • -Build team: The software must be continuously build for each change and anything that breaks is to be seen and understood by the original contributors.

  

  I have personally not seen daily releases myself, although I count quick bug-fix releases to these. In those cases it is clear that different enterprise teams like scrum teams and operations get together during the day to analyse hot issues and decide on how to enhance the software, prevent this kind of mistake a next time (usually getting an automated test in place, how come it was not there?) to manage risks. When going for continuous delivery, eventually a separation of departments between development and operations is more an obstacle than a help.
  Kent Beck mentions that in-between systems like a separate staging environment are therefore going to dissolve in that process.

  The effects of acceleration will eventually lead to the Dev Ops movement.

  More reading…or watch this video on Channel 9:
  Continuous deployment the dirty details on Channel 9.