“Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should”, Jeff Goldblum quipped in Jurassic Park 20 years ago. Some people might say that the Agile movement is guilty of the same hubris. It is true that the unexpected consequences of an Agile development community are being felt both upstream in the PMO and with requirements engineers as well as downstream in the build, test and release teams.
The short, sharp, shock of iterative development means that there is continuous incremental, improvement in business systems. But are IT systems able to accommodate one part of the lifecycle marching to its own cadence?
Continuous delivery is one response to this problem. Depending on the complexity, churn in function and usability, churn in code, dependability of the development team, quality of the test bed and every other parameter that indicates (or mitigates) risk, more or less automation of the delivery process is possible.
Of course not every step in the delivery process can be automated. It is not uncommon for platform variances between DEV, TEST, DEVOPS and OPS to require intervention from release engineers. But we should try to eliminate those variances so we can eliminate human intervention. Testing and deployment platforms should not be different and the easy availability of virtualized and cloud environments means they can be stood up cheaply and in an automated manner, so there is no excuse any more.
The aim is to speed up deployment, improve time-to-value and ultimately reduce costs and increase revenues.
The DevOps movement is the champion of automating the release management process making it possible to push projects through, even faster, all the way through from development to production.
However, now is the time to step back and consider what policies, processes and procedures our software development should follow? Do we dive into all that is new and shiny or hold back and rely upon what is traditional and safe. For some organizations continuous delivery may not be appropriate for their development projects. Rather than saving on costs, it could lead to excessive rework, fixing problems that should not have occurred in the first place.
Pushing all projects to production automatically can mean running risks in testing and release because we lose human oversight. Release automation cannot solve all the issues.
To get the best out of continuous delivery and Agile, DEV teams have to set out how far through the development process each project should be automated. For projects that are not user-focused or that have no impact on users, steps like testing and UAT can be more automated through to production, and potentially even into the production environment itself.
For those applications that are high visibility and revenue generating, the continuous delivery method may be in place across development and testing but stop at UAT and release. From there, each of these individual projects may join part of a release train where multiple different releases are linked together to be put into production. These release trains can themselves be automated so that rework and downtime is reduced as well from the implementation and production side.
The main point to make here is that there is no “one size fits all” rule that fits each potential release. Agile by its nature leads to more individualised release projects coming through to production, and each of these can be graded to see how far the release process can be automated and how tight the controls are applied. Continuous delivery represents a potential to streamline processes and reduce costs. However, it has to reflect the reality of how agile works within the organisation as a whole.
In the end though, Mr. Goldblum also remarked, “God help us! We’re in the hands of the engineers!” By having the oversight of the whole process, we can ensure that the value created by agile is felt across the software engineering process, as well as the widerbusiness.