[tl;dr This post discusses why state-of-the-art technologies and techniques which brings together agile software delivery with operational considerations are strategically key to business success.]
Continuous Delivery is a subject that makes many operations folks break out in a cold sweat..the concept of being able to deploy change as soon as it is ready rather than on fixed deployment schedules is surely a recipe for disaster.
In most cases, it is: the act of taking a traditional monolithic application build, and moving it from test to UAT to production is often a very painful, labour intensive process, with many gates and controls. Because applications typically aren’t build with an operational perspective in mind, most of the creative coding goes into the business functionality, and not into the so-called ‘non-functional’ requirements such as ‘operability’.
The net result is that it’s a lot of work to deploy change, and hence it has to be planned well in advance.
The solution is automation: automation of building, testing, configuration and deployment.
Such automation requires significant investment, and so is generally only worth the effort when a significant number of teams can benefit from the automation. This in turn depends on standards: there is little point in building a highly automated toolchain for Java when most folks want to do C++, for example.
But the investment pays off, in the ability to respond rapidly to business needs, to quickly make change and be confident that nothing critical breaks, and to provide operations folks with key tools to manage and configure running applications without involving the core development teams.
Continuous delivery may only be an aspiration: it may not be necessary to deploy several times a day, even if you can. But the act of preparing for it makes the whole process much more efficient and massively reduces change-related risk.
The seminal book on this topic, ‘Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation’ by Jez Humble and David Farley covers all the topics very well, and dovetail nicely with related strategic themes of Enterprise Modularity and Lean Enterprise.
The question of Standards always raises its head: in my mind, Standards are in basic conflict with Innovation..although sensible standards can provide the constraints that allow genuine innovation to thrive (as, in general, innovation is a supply-side response to one or more constraints in meeting demand).
When it comes to solution standards (i.e., specific languages, libraries, tools, infrastructure, etc), one of the key drivers for identifying standards should be standards that allow automated toolchains to be built, according to Continuous Delivery principles. This generally means specific languages, specific code repositories, specific package dependency management, specific build repositories and tools, specific test frameworks, configuration engines, deployment tools, etc, etc.
In short, to achieve continuous delivery, firm technical standards need to be in place for the most frequently used architectures. For projects deviating from the standards, it must be understood that additional investment will be required to enable continuous delivery.
As each domain will have its own unique non-functional requirements, the level of toolchain automation appropriate needs to be agreed as part of the domain’s target architecture – and with it, the relevant technical standards the domain wishes to adopt. Short-cuts to deliver change which do not use the automated toolchain process needs to go through an exception process: technical debt in toolchain automation is usually not a sustainable option.