A faster and safer approach to software releases that can transform business capability.

Part 1: What is it?

The hype around Continuous Delivery (CD) is rampant and can sometimes be biased by technologists who may struggle to convey business benefit. To be clear, CD is an enabler for the business as a whole to be faster, more responsive and more accurate in generating customer digital experiences. It is not a new set of tools for the techies – rather it is a new way of working across a business.

CD has the ability to unleash a business to achieve success at an unprecedented scale and speed, but like any new venture, the benefits and outcomes should be measured against the core mission and objectives of an organisation.

If you’re a “Head Of” or a CxO, the importance of bridging the value gap between business and IT is unavoidable. In the simplest terms possible, this blog explains the concepts of CD and how it aligns business objectives with the technical solution. If considering or currently experiencing a continuous delivery journey, then part 1 of our blog gives a robust definition around CD, whilst part 2 helps brace for impact.

Traditionally, IT teams helped speed up business capability, but now its commonly the bottleneck. The industry drive to improve customer experience (CX) quicker and pressure from ever increasingly competitive marketplaces puts more pressure on the bottlenecks and a greater focus on “work-arounds”.

A common thread in business goals is improving customer satisfaction and being “the best” in an industry or niche market. Following lessons from Toyota manufacturing, bottlenecks should be addressed as a priority. Continuous delivery addresses the bottleneck that IT can present.

The CD approach helps reduce the cost, time, and risk when changing software. It allows more incremental updates to end-users. It does this through automation of building, testing, and releasing of software with greater speed, accuracy and frequency.

‘If it hurts, do it more frequently, and bring the pain forward.’ ― Jez Humble

Ultimately, customer satisfaction increases. Delivering software faster means being more responsive to customer requests, who then become a key driver for prioritising work. Businesses can validate ideas faster to small user groups before it becomes mainstream. If there is an issue, it can be quickly resolved, turned off or users can be automatically redirected to an updated solution.

When the bottleneck of IT is minimised, the pressure is dispersed back to the rest of the business. Customer services further embrace how IT can improve customer self-service. Marketing experiments are more common and improve the impact of campaigns. There is more monitoring to be leveraged by compliance and insights. Information security can have automated checks. IT teams are happier because they are providing more value to the business and are less focused on repetitive tasks or bugs – they become less of a constraint and more of an enabler of innovation.

If an issue is discovered in production, diagnosing the problem should be easy through system logs. Defining a solution should be the major human focus – coding a fix takes much the same amount of time as previous – but the major benefit of CD comes from deploying the change and having confidence that the fix has worked and not broken anything else. It improves the quality of releases. Having a full automated regression test done on every code commit identifies issues sooner.

“To successfully implement continuous delivery, you need to change the culture of how an entire organization views software development efforts.” —Tommy Tynjä

The concept is not new, however the past few years have seen a large spike in the alignment and understanding of what a good CD implementation looks like. Larger companies at the forefront of disruption have proven the existence of technical tools that align with the concepts of CD. In recent years, this has trickled into the mainstream and proven itself on a smaller scale too.

Continuous Delivery (CD) aims to reduce the lead time for reliably releasing software at any time. The key enablers are:

  • Decomposing work into very small deliverables
  • Automation of builds, deploys and testing
  • Monitoring everything

The key constraints commonly encountered are:

  • Aligning a business with the concepts of CD
  • Lack of commitment to laying the foundations
  • Finding and shaping the right skills

CD usually encapsulates Continuous Integration (CI) but there is a distinction.

CD aims to deploy reliable software faster. A theoretical goal of CD can be continuous deployment where new code is automatically deployed to production. Whereas CI aims to improve overall quality and make deployments safer. The concepts are tightly coupled.
CD = Faster
CI = Safer
Faster

If business leaders believe that “every company is a software company”, they will search for ways to heighten its software development capability. Implementing the concepts of CD challenges the business-as-usual mindset.

Going faster materialises in the following ways:

  • Tighter customer engagement. Businesses that move faster can respond more quickly to customers; responding faster can increase uptake, market share and customer loyalty.
  • Time is money. Moving faster reduces the lead time between the conception of an idea and its implementation. Increasing speed can decrease operational cost per idea.
  • Progress becomes apparent. Stakeholders become more engaged and trusting. The common phrase from developers, “It’s done, but I just need to…..” shifts towards “It’s done and is ready for….”. It’s a subtle shift but when compounded it makes a huge difference.
  • Congestion is more obvious. As throughput increases and the exact same path is more heavily trodden, inefficiencies can be highlighted. Using the right metrics combined with a constraint investment and willingness to improve will encourage people to speak up to address bottlenecks.

“The earlier you catch defects, the cheaper they are to fix.” ― David Farley

Safer

Insanity is going faster without considering safety. Shortening lead times only works if customer experience and quality is high. The business may release more of the wrong thing or create more bugs for customers. Safety first, speed second.

Safety materialises in the following ways:

  • Reduce manual intervention. People can be less predictable and accurate than scripted interactions. Focus on automation. Automated tests, infrastructure, builds and deploys are a key focus. Automate test coverage reports, load testing, security reviews and disaster scenarios. The tasks done periodically because of overhead become trivial to execute, so can be done more frequently, often hourly. The more frequently tasks are repeated, the more likely issues can be discovered before customers. Frequency correlates with quality.
  • Reduce the size of changes. The more that is bundled into a deployment, the higher the risk of failure and the more difficult it becomes to isolate problems. A decoupled microservices architecture is a key enabler for small deployments. A primary workflow in continuous delivery is having all automated tests run on every code commit. Issues become inherently isolated within a small, known and obvious area.
  • Fail at the earliest opportunity. In a CD environment, new code can be in a QA environment within minutes of a code commit, but there is no point waiting minutes if that code is not correct. A primary workflow in CD is to run unit tests at the time of building the code, so that failure has an opportunity within seconds instead of minutes.
  • Plan for recovery. As Jez Humble says, “Mean Time To Recovery (MTTR) is more important that “Mean Time Between Failures (MTBF)”. Embrace the need for speed in all aspects including recovery. Build resilience into the system and test it regularly. Expect things to go wrong and be OK about it – learnings will not be isolated to the tech. Ensure that system and user monitoring is paramount and is the responsibility of everyone. Some businesses have the “always go forward” mentality, so when an issue occurs, everybody works to fix the problem – others simply revert. Either way it must be a premeditated decision.
  • Reduce the failure footprint. Release fixes and new functionality to a small customer base. Confirm it works before widening the footprint. A/B testing is a useful tool to target a certain demographic, device type or persona before embedding change.
  • Separate deployments from releases. Small production deployments become more frequent with CD, however the changes are not forced onto the customer. Some businesses will still prefer some manual testing, however this should not bottleneck production deployments. Feature toggles (also called feature flags) allow new functionality to be deployed but turned off. With the flick of a switch, that new code can be toggled on for customers. Toggling off also provides an easy abort option if the proverbial hits the fan.
  • Keep it green. When the system builds (many times a day), if any automated build or test steps fail, the pipeline becomes red and blocks any new code being promoted to other environments. That is; a red pipeline should prevent anything from going into production. If you have a production issue and a red pipeline – your MTTR is impaired. The open source Connect build/deploy/test workflow called “submit queue” launches on a branch of code and all automated tests must pass before it is merged to the pipeline. Keeping a green pipeline is essential for maintaining a low MTTR. When the master pipeline does become red, it’s essential to automatically notify the entire team. Ensure every technical person has the skills and the mentality to investigate and help resolve the issue.

“A phased approach to continuous delivery is not only preferable, it’s infinitely more manageable.” —Maurice Kherlakian

Faster and safer is the aim, but a perfect technical implementation can still be perceived a failure. Aligning business objectives at the start of the CD journey will set a focus for the team and an understanding for the rest of the business.

Faster and safer is just the start of the conversation, but how that materialises within a business is where the rubber hits the road. It’s not easy, there is a lot to it. Each element is simple but bringing it all together and capitalising on the benefits won’t happen overnight. It creates a platform for constant improvement and it becomes a never ending journey of improvement albeit with a steep learning curve.

“IT performance predicts organisational performance.” – Nicole Forsgren

Read Part 2 of our Continuous Delivery blog series which discusses how to define the objectives of implementing CD, what expectations to set and what to consider when determining if CD is the right tool for the job.

If you need help with implementing Continuous Delivery in your business, we can help. Get in touch with our team today.