Continuous Delivery: How to Have the Reliable Software Releases to Production at Any Time

Software development has seen a steep outlook and approach difference to keep up with the current market trends and consumer needs. While the traditional waterfall approach was more sequential and planned, it has setbacks in terms of satisfying customer expectations of the final product. 

img source

The agile methodology then came as the perfect answer as it ensured functionality/feature installments to be delivered at the end of short development cycles or sprints. Soon it became the way of life.

However, to take Agile to the next level, it is essential to test the software almost around the same time as it is built. This method of “Shift left” or “Early testing” drastically boosts an accuracy of the software and makes it less error prone.

With this came a need for CD and CI processes to be intricately carved into Agile. It is these processes that provide the needed momentum for the build, test and release activities to function seamlessly.

What is Continuous Delivery?

Martin Fowler of ThoughtWorks defines Continuous Delivery as “A software development discipline where you build software in such a way that the software can be released to production at any time.”

Based on this, here are some obvious conclusions:

• Software being built is heavily dependent on a process which has to be thorough, accurate and repeatable.
• Since the software should always be production-ready, it is imperative that it has to be more user-centric. How do you do this? Take feedback from the users as early as possible.

At the heart of CD lies Continuous Integration which enables the users to always have a build with the latest code changes. This means that developers must put in their code changes frequently, implying frequent builds. Thus, CD consumes Continuous Integration and is a superset of it.

Implementing Continuous Delivery:

Below is a general high-level overview of CD implementation.

#1) Automation: Processes where accuracy is the need of the hour certainly demand a high degree of automation. This is also in line with basic software quality principles that recommend investing in automating tests for tasks that are repetitive in nature.

Continuous Delivery almost thrives on and encourages automation in every possible area, whether it is gathering requirements or slightly difficult, deployment. Setting up automation help is the first step to achieving the desired reliability for CD.

#2) Version Control System: In a fast paced project methodology there would be several people working on the same code or project asset simultaneously. This necessitates a version control system in place to make it easier to track any changes and view the modifications by a team member.

#3) End to end ownership: CD completely breaks free from the shackles of working in silos. This means a developer’s responsibility doesn’t end at checking in his code. Likewise, a QA engineer doesn’t stop at testing scenarios, opening bugs and retesting them at just the code level. Developers, testers, project managers and everyone involved has to collectively strive for the correct functioning of the delivered software.

#4) Quality Metrics: Measuring success and establishing benchmarks are instrumental in achieving the needed success for a CD process. When analytics and metric collection are in place, problematic areas will easily show up. The recovery can then be identified based on the said problems.

#5) DevOps: This is probably the most important and fundamental thing to focus on when implementing a CD process. DevOps brings the unification of two isolated entities in SDLC, development and operations.

Right from setting up environments, configuring them, managing a part of the build process and testing build deployments DevOps drives a big change in perspective. This kind of collaboration ensures rapid deployment. Therefore, it is safe to say that it forms a stepping stone for a successful CD process.

#6) Enhancements and Improvisation: Identify how the CD process can be continuously improved, easily maintained and kept up to date. In case of any failures anywhere in the process, it is absolutely better to nip it in the bud than have a temporary fix or workaround.

Continuous Delivery Pipeline

Below is a diagrammatic representation of the overall working of the CD process.

(Click on image for enlarged view)

Please note that:

• Every juncture in the pipeline, starting with check-in to production deployment, has an arrow pointing back to the previous block. This only goes to reiterate how much the CD process is heavily reliant on feedback.
• Say a developer checks new code into the source control, CD process kicks in where a build is spun and sanity tests are triggered. Only if the build is deemed to be a “good build”, it is passed on to the next Quality check stage.
• This is where the QA team comes into the picture and runs the required tests. They could be basic functional verifications or non-functional stress, load, performance tests, etc.
• If at any point there is a failure or noncompliance, it is flagged and will have to be fixed for the CD pipeline to proceed further.
• Finally, after that particular build is deemed to have the quality approval, it is deployed to production.

Role of QA in CD: Continuous Testing

From the CD pipeline above, we can see how Quality Assurance surfaces in the whole scheme of things. Now let’s get a deeper understanding what CD means from a QA perspective and how a whole new approach to QA has to be embraced.

In a traditional testing model, there is a time gap between a developer checking in the code and tester receiving the build containing this code. However in CD, new code gets integrated quite frequently and continuously. Therefore, it is an implicit understanding that the testing has to be accelerated for it to keep up to being “continuous”.

How is this possible?

The answer is obvious and what we’ve been discussing – Automation! Test Automation is the key to successful testing in a CONTINUOUS DELIVERY process – the more, the better; on all levels.

------------

Secondly, function drops may happen within a couple of days due to being delivered in small installments. This means that there may not be adequate time for full test planning. The delivered installment may not even have a GUI at the moment. Therefore, the testing approach has to be re-factored and has to undergo a drastic change.

What does this imply to a tester?

The strict role definition of a developer and tester needs to be overcome almost blurring the lines between their skills. Testers have to be familiar with what is being developed right from the beginning, gain the required skills and likewise, developers will need to know how to test.

Factors that form a reference framework to enable continuous testing

#1) Applying reasoning and questioning:

In addition to testers upgrading their technical skills and getting involved as early as possible, a tester has to apply analytical reasoning about the product being built. This means testers must have the ability to:

• Look at the bigger picture
• Understand the real business usage
• Decipher and determine if the captured requirements are in the right direction
• Gauge the environment and setup needed to facilitate testing of scenarios identified
• Decide how different tests need to be carried out – functional, nonfunctional, accessibility, security, etc.
• Figure out how to maximize automation at all

This takes us right to the next point, strategizing test effort.

#2) Test strategy creation:

Deriving the model that ensures extensive testing to filter out any potential issues at the various level of development will ensure a steep quality rise. This is defined as “layering of tests” and includes the development arena too.

The more layers you add, the higher the quality is.

Let’s understand this better with an example:

Consider the continuous testing model below. Now whenever a code change happens, it will pass through the layers.

• Typically, development will run some automated unit tests before committing their changes to ensure that their code is in a suitable shape. In this model, sometimes development also borrows happy path tests from QA and runs them additionally. This constitutes the first block in the model.
• After a change is committed in version control, CI runs extensive automated tests in the next layer.
• Now, if there are any failures in the previous step, it is a good idea to add another layer before the code is passed on to the test team. This explains the dashed box in the third layer. Let’s call it feedback box. Based on the failures in the previous step, one can run some manual tests to check sanity, analyze the coverage of the automated tests and add additional tests to maximize coverage here.
• The next layer is where QA takes over. Validating functionality, performance tests, etc. are included.
• After the previous layer establishes some confidence in terms of the stability of the features and that most bugs are fixed, the next layer to include acceptance tests can be added to establish further confidence.
• Finally, when the software is deployed to production, it should again be monitored proactively for any bugs that might come up.

#3) Improvising the process:

In a CD environment, you have to keep improving the entire testing process in order to have an edge. This can be as small as having a good communication channel or as eminent as improving test scenarios, test coverage, test tools, etc.

#4) Upgrading technical skills, test tools usage:

It has become necessary for testers to take their role to the next level and upgrade their technical knowledge by understanding the architecture, the code and component dependencies. It is also an absolute must for testers to have coding knowledge so that they can add more value to automation. Upgrading skills must also be extended to the usage of test tools which will help the automation and general testing effort in CD.

Continuous Delivery Tools:

Since automation forms the crux of CD (not just functional test automation, but an end to end automation of the pipeline), there are tools used at every stage of the process, up until deployment. These tools, such as Version control, unit testing, CI, build automation, quality check etc, help accomplish the objectives of each stage in a comprehensive way.

Here is a list of some continous delivery tools .

Benefits of CD:

After the above discussion, it is automatically understood that there are many benefits to be derived from CD.

Here are the most striking ones:

• Less Error Prone: Since small pieces of code get integrated frequently, the chances of any error being missed are reduced by a great extent.
• Quick Feedback/ Resolution time: Because of early feedback integrated into CD, there is higher product quality in general. This also helps in delivering a product that is actually useful to the end user, thereby being more customers
• Fast time to market: CD helps in coping up with an ever changing market and consumer needs through frequent and quick releases. The turnaround time to convert an idea or concept into reality is remarkably fast.