Andrew Browne, Software Architect, SEEK
Continuous Delivery is the practice of delivering small software changes to production as soon as they are complete. These frequent small releases are made possible by ensuring that code is always in a deployable state and that all aspects of deployments are automated. What was previously a risky and time consuming task - releasing code to production, has become a predictable routine affair.
All changes including bug fixes, operational improvements or new customer features are released to production as soon as they are complete. Through this, feedback can be received sooner and the team can assess and learn from that feedback. This tighter feedback loop helps in creating a platform for rapid learning and iterative innovation on the product.
The large monolithic applications that share infrastructure across teams increase the risk of deployments and require cross team coordination. It is preferable to build smaller decoupled services that can be deployed independently of other systems. This allows a team to own their services end-to-end.
The effectiveness of teams is created through aligning service boundaries with team boundaries; we have built cohesive teams around services. Both the teams and the services are loosely coupled to the boundaries around them. By carefully designing services boundaries and implementing contract based testing between services, teams are free to make significant changes to their services while managing their impact on other teams. This is a key enabler for continuous delivery.
As we move to the cloud and have decoupled services, teams are able to manage not only their code but also their deployments and production environments. This means that teams are able to control their own infrastructure end-to-end.
This has gone hand in hand with encouraging a DevOps culture where automation is central to success. Teams manage their own automated deployments and the production infrastructure it deploys to. Building operations skills into the delivery teams also avoids one extra level of hand-off and one extra set of external gatekeepers who might otherwise become a bottleneck to continuous delivery.
When the team is in control of their own operations they can make decisions that they can support end to end. Teams that look after their own operations are empowered to make the best decisions about how to best solve their problems taking into account development, customer and operational impacts.
These approaches have allowed for a larger number of small technology experiments without a large amount of risk or cost. Enterprise wide decision-making is avoided by making local decisions about what is the best approach for that team and their problem space.
A strong culture of sharing enables good ideas to spread and allows the whole organisation to learn from things that have worked and just as importantly from those that have not. Many of our current practices around building and deploying software have started as a single team trying something different and spreading that knowledge to other teams.
Teams are also empowered to choose the tools that are the best fit for that team, rather than mandate a single set of tools. Teams take into account both the team’s knowledge and the requirements of the problem space they are working in when deciding what tools are best to use.
Continuous delivery allows teams to get changes to customers sooner. Decoupled services aligned to team boundaries allow teams to have complete control over all aspects of what they are building and DevOps allows teams to manage software delivery from code all the way through to production. The combination of these three initiatives has led to teams that are empowered to deliver higher quality software to customers faster, more frequently and with lower risk.