In the buzzword-bingo world of software development, a term that gets repeated a lot is “Continuous Delivery.” Unlike some other terms of art in software, this one means what it sounds like it means. Teams are pushing many small changes into production regularly – sometimes multiple times a day. But this simple term masks a lot of supporting behaviors that give real and powerful benefits to customers.
Why Continuous Delivery?
Put simply, continuous delivery and its more technical sibling “continuous deployment” is a better way to build software. It offers three key benefits:
- Faster feature development
- Less customer disruption
- Automated testing gives great coverage
The very first thing we built into our latest cloud platform – PureCloud — was automated tear-down and deployment for server updates. We quickly followed up on this with microservice updating across live systems. In big complex systems, you don’t want developers picking and choosing dependencies for their updates. Continuous delivery requires a very polished updating approach that automatically pushes code to higher deployments when it passes tests. Developers build contained deployable features that can be rolled out with little to no disruption.
For us, every build is a deployment. We have hundreds of deployments going on every day just for developers to see their new code at work. We constantly deploy new features by rolling updates across pools of cloud services with no interruptions for customers.
PureCloud platform uses this approach for updates and stateless context sharing to elastically grow our footprint for high-traffic or complex requests. This also allows for simple roll-backs when needed.
Continuous Delivery plays nicely with Agile approaches. “Agile,” another buzzword-bingo term, is about keeping teams productive. It copes with the myth of waterfall, date-based-planning for releases where you chop up functionality to make big deliveries and face big integration challenges at the end. This makes it impossible for teams to predict interdependencies and build complex feature sets that customers need to do their jobs well.
By breaking down complex work into small iterations, we can bite off big changes in small steps, deploying each step as we go. Smaller feature changes mean smaller tests, and smaller tests are easier to add to test automation. Automated testing keeps development teams from hearing “Stop development so we can manually test this.” Instead, teams take small tasks off the backlog and build them week-after-week. Continuous testing and feedback keeps teams moving forward.
In business terms, this means you can get the newest features to customers faster, which gives your company a critical competitive advantage.