INSIGHT
Agile teams need agile infrastructures
Agility, DevOps and Continuous Delivery creates new dependencies between software development, application life-cycle management and IT Service Management (ITSM). These innovations therefore come with new requirements on the infrastructure as well as on related ITSM teams. Agile teams need agile infrastructures.
The technology stack for Continuous Delivery has become a highly complex piece of “machinery”. It includes everything from source code management via build systems and artifactory repositories, to automated testing and deployment staging, from development and test environments to production. Each element must be optimally controlled.
If “happy hackers” are left to deal with these challenges on their own, the solution will be geared towards the needs of a specific software project or team. To create repeatable deployment channels for re-use across your portfolio, ITSM experts must participate from an early stage.
In fact, today software packages increasingly constitute an infrastructure universe of their own. If developers package applications in Docker containers there will be an impact on ITSM. The impact will be greater still if you deploy containers via a Cluster Management solution such as Kubernetes. You achieve auto-scaling, service discovery, load balancing, rolling upgrades and the like, and thereby automate what previously required a manual ITSM procedure.
To support such scenarios, you have to establish a well-oiled and fine-tuned production line. From the first stages of system development to the final stages of service delivery, you must achieve automated quality assurance. And this is not possible unless your ITSM team works closely with your developers. Without a well-informed and actively involved ITSM team, agile development will rarely reach its full potential.
It is about people, organization in addition to technology
The transformation to Continuous Delivery impacts not only your developers and ITSM staff but the entire IT domain, its management, the DBAs, the business analysts, the user experience designers, the quality assurance experts – all the different competencies involved in the production of your software solution. If your current engineering, QA and operations work in isolated silos, there will be cultural barriers as well. While developers focus on churning out new features – i.e. to achieve change – your operations team strive to keep systems stable – which means avoiding change by all means.
The goal of your cultural revolution is to achieve repeatability and to shorten the cycles it takes to deploy new features into production.
From Continuous Integration to Continuous Delivery
The shift was introduced in the 1990s with Continuous Integration and test-driven and agile software development. By breaking down feature lists into a backlog of manageable tasks, agile development models strive to complete functional versions of their software at the end of every sprint. Sprint cycles typically last a week or two, sometimes more. This means Development can hand-over a new version of the software at the end of every sprint to your QA and/or Operations teams.
By and by, Continuous Integration evolved with more automation. By enhancing build systems such as Jenkins or TeamCity developers automate unit testing and functional testing on-the-fly. With such features in place, a vision of Continuous Delivery seems within reach.
However, most organizations were and are still not ready for this change. So far, only the first part – Development – has become truly agile. Between Development, QA and Operations, most organizations still have solid walls. This leads to a continued waterfall model between development and production stages. Every error found during Integration testing generates yet another sprint iteration of one, two or more weeks.
Release management still important
Continuous Delivery means you are potentially able to release new versions every day, as developers check in their code changes. However, this is rarely what you would like to happen.
A release needs to meet other criteria as well. You need to consider the organization’s marketing strategy, possible contractual constraints and other non-technical aspects. Continuous Delivery simply means you have the ABILITY to release every time developers check in their code into the trunk.
In Continuous Delivery nirvana you furthermore must collect data and provide metrics to control your flow of new features into production. Measurable quality and sufficient meta-data help your non-technical teams determine by when a continuously delivered piece of software is ready for release.
At Ductus we have been successful in synchronizing our system development and IT service management teams into new engineering practices to achieve a faster and more secure service delivery. We are happy to share our experience with you.