In this two-part article series, we will focus on Continuous Delivery (CD) and Continuous Integration (CI), starting with an at length discussion on Continuous delivery today.
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.
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 You Will Learn:
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:
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.
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.
Below is a diagrammatic representation of the overall working of the CD process.
(Click on image for enlarged view)
Please note that:
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.
#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:
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.
#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.
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 .
After the above discussion, it is automatically understood that there are many benefits to be derived from CD.
Here are the most striking ones:
To embrace Continuous Delivery, a huge change in perspective is required in organizations following the Agile process. While it is not very easy to implement, staying focused on the benefits certainly paves the way to make it a reality.
About the Author: This is a guest article by Sneha Nadig Yadav. She is working as a Test lead with over 10 years of experience in manual and automation testing projects.
In next article, we will understand what is Continuous Integration. It is the real meat behind the CD process and is the reason for which a Continuous Delivery process is possible.