Continuous Delivery and Integration: Rapid Updates by Automating Quality Assurance

Over the last 10 years, continuous delivery has become one of the most discussed development practices. Making software updates rapidly, as soon as they are ready is the theory. While this once sounded like magic, the breakthroughs in automation engineering make frequent updates possible.

The idea of continuous delivery was developed and shared by Martin Fowler, Chief Scientist in ThoughtWorks. He described the background of the practice this way: “Every developer integrates with everybody else’s work frequently. […] And, if something has failed, nobody has the more important job than fixing the backstage”.

So, lets explore continuous delivery and integration in technical, operational, and business terms.

Evolution of development practices that led to frequent software updates

Waterfall. All development stages from planning to production deployment and maintenance follow each other. Waterfall has proven its inefficiency for products where constant updates are needed. It hasn’t allowed for quick reaction to customer feedback quickly because of lengthy development cycles. Today waterfall is mostly used for short, fixed-cost projects, that won’t have enough time to age before the release date.

Waterfall has a conservative, non-flexible nature

Agile. Agile is a philosophy defined by core iterative development. There are many agile methods, but most of them entail short engineering cycles that include all main stages: planning, development itself, testing, and deployment. Each cycle takes one or two weeks. The idea behind Agile is shipment of the product as quickly as possible and incrementally update it based on customer feedback. Agile methods remain the mainstream in modern software development as they support product adaptivity to the constantly changing market and customer needs.

In agile development, each iteration takes 1–2 weeks

Continuous delivery. You can find multiple interpretations of continuous delivery. We consider it an evolutionary development of the Agile principles. The method doesn’t require short release iterations and simply allows the commitment of new pieces of code when they are ready. This way, developers can update the product multiple times per day, continuously delivering the value to users. This is achieved by a high level of testing and deployment automation.

In CD, builds are created multiple times per day

Business value of continuous delivery

In 2014, Mark Warren, European Marketing Director in Perforce said that 65 percent of software developers, managers, and executives practice continuous delivery in their companies, while 28 percent report using it across some of their projects. Eighty percent of respondents were working on software-as-a-service (SaaS) products.

The ubiquity of continuous delivery adoption is likely to be higher now, as we see increasingly more software providers embarking on the SaaS model. Cloud-based services are the main field for the practice adoption as these products can receive customer feedback immediately and just as immediately respond with fixes and updates.

So, what are the main reasons to consider CD?

Time-to-value proportion. The velocity of development is high and the time gap between proposing a new feature and its delivery is significantly reduced. So-called “integration hell” is mitigated in this case. The team spends less time on debugging and more time on developing new things. This also means a shorter feedback loop, the time between user interaction and updates.

Maximum automation. Continuous delivery is only possible when testing and deployment stages are automated. Thus the only time-consuming aspect is the programming itself. We’ll talk about technical details in a minute.

High quality and low risk. As every update undergoes several stages of automated verification for deployment, the number of possible mistakes and bugs is significantly reduced.

Data-driven management. The strategy also allows for constant monitoring of data related to development. You get visibility on your processes and eventually insights on improving your existing workflow and eliminating engineering bottlenecks.

Reduced cost. One of the main disadvantages of long release cycles is the cost of a mistake that keeps on growing as a bug stays in production. If it remains after multiple updates, the cost to fix it starts growing exponentially. Continuous integration reduces this cost by revealing bugs as early as possible.

Adoption framework: how to approach continuous delivery

  1. Following the core principles of the continuous delivery method: continuous integration and deployment
  2. A software engineering infrastructure that connects all product delivery aspects into a unified ecosystem
  3. Project repository with a minimum number of code branches
  4. Automated test outweigh the manual ones
  5. Use of production environment clone that exactly mimics real-life conditions

Continuous delivery is more complicated than these five aspects, but they define whether your organization is able to apply the practice. Let’s discuss these requirements in more detail.

1. Continuous integration and deployment

  • developers make code commits multiple times per day
  • each code piece passes through a set of automated tests to detect every error and bug as early as possible
  • the major priority for the development team after the issue is detected is to remove it.

Continuous deployment is another CD principle meaning that every validated feature can be deployed into production at any given moment. But continuous deployment, unlike CI, isn’t always necessary for CD. In the words of Carl Caum from Puppet, “Continuous delivery doesn’t mean every change is deployed to production ASAP. It means every change is proven to be deployable at any time.

The ability to deploy updates immediately mostly fits SaaS models, where developers have full control over the product that an end user faces. If you have client software, which is installed on users’ devices, it’s more common to bundle these updates and let users know that some changes are going to be applied. For instance, Facebook can practice continuous delivery in their development workflow, but your mobile app will ask permission to update itself.

2. Continuous integration infrastructure

  1. New code monitoring. Every time a new piece of code is committed to the repository (code storage), the CI-system detects this change.
  2. Packaging. The new code is automatically packaged for tests.
  3. Automated testing. Packages go through a number of automated tests validating that this new code works properly.
  4. Deployment. Once packages are accepted, the CI-system deploys the update on a production server. If deployment itself isn’t automated, the system ensures that packages are ready for in production deployment.

Due to high automation, this process can occur multiple times per day, revealing bugs earlier than if developers had been committing big chunks of code.

3. One mainline of the project in repository

To get all benefits of such an approach to deployment, the number of code branches in the repository should be reduced to a minimum. Traditionally, code branches from multiple developers merge into the main every so often, depending on the update scope. In CI, the software environment maintains the minimal number of branches and continuously sends the new pieces of code directly to the master branch providing quality assurance on the go.

The more code branches and versions of the same product you have, the higher the chances of conflicts between them.

4. Testing automation

Although full test automation is not a must, CI is worth adopting only if the number of automated test cases exceeds that of the manual ones. Fortunately, CI systems allow for integrating a large variety of automated tests, ranging from smoke testing to understand whether your product will simply launch after updates to security and performance tests. On top of that, your QA engineers can opt out of multiple programming languages to write these test scripts.

5. Production environment clone for testing

The main adoption challenges

The cost of automation

Microservices architecture

If your software product is a large monolith, it’s not a death sentence to continuous delivery. But it will make life for developers working within continuous delivery logic harder. The monolithic code might not be well understood and it becomes more demanding to reconcile the work of multiple development teams each working at its own pace.

Embracing DevOps culture

According to the 2017 InformationWeek survey, only 18 percent of tech organizations have fully adopted DevOps, and 32 percent plan to do this in 12 months. These statistics highlight two things: 1) A limited number of companies work on DevOps; 2) Mere DevOps use doesn’t necessarily mean that the corporate engineering culture works this way.

Integration challenges

Frequent deployment

Focus on bugs

Production environment capacity

Organizational culture

Continuous integration as a way to deliver value

Continuous integration is a way to perform stable and frequent deployment of high quality. As Martin Flower said, “Frequent deployment is valuable because it allows your users to get new features more rapidly, to give more rapid feedback on those features, and generally become more collaborative in the development cycle”. Continuous integration is a way to remove the wall between companies and their customers, creating client-oriented, useful software.

Being a Technology & Solution Consulting company, AltexSoft co-builds technology products to help companies accelerate growth.