Continuous integration and continuous deployment (CI/CD) do not represent new concepts in our industry. They are key players in the development/testing process, yet many people do not “understand” the real impact it has on our daily work. In this article, we will dive into these practices and try to understand why everybody should consider them for each project.
A little bit of history
Let’s start with the most basic question: what is continuous integration/deployment? We’ll first define continuous integration.
The idea is that the code (or tests) developed should be integrated into the main branch as fast as possible as many times as possible in a single day. This means that the functionalities and tests developed should be as small as possible, though meaningful, to meet this requirement.
The first time this concept was introduced was in 1989 by Kaiser, G. E.; Perry, D. E.; Schell, W. M in their work: “Infuse: fusing integration test management with change management.”
On the other hand, CD stands for continuous deployment and can be used for continuous delivery as well. They are related concepts but have some differences nonetheless.
Continuous delivery can be seen as an extension of CI to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and can deploy your application at any point.
Lastly, if we mean continuous deployment, this goes a little further than continuous delivery and means that every change that passes all stages of the production pipeline is released to customers. There’s no human intervention, and only a failed test will prevent a new change from being deployed to production.
From all these, we can understand that the main idea here is to move forward, quickly, but meaningfully and incrementally by adding features and quality to the software we are developing… or testing.
What about QA?
When creating an automated regression suite (or any kind of automated testing suite), we usually have lots of tests, suites and features to cover. That means that the volume of tests we develop sprint after sprint will grow alongside the application. Taking the decision to implement CI to software testing can save the team, and the client, a lot of time, resources and will help us detect bugs in a faster and more efficient way.
Now, what exactly does it mean to apply CI/CD to software testing you may ask? Well, it means that the QA team should adopt the philosophy of these activities in the first place. We should have a pipeline configured so that every time we create a small set of tests we can rapidly push them to our main branch and integrate them with the already existing tests.
In the previous paragraph, I introduced a “new” concept without getting into it deeply, which was no mistake. A pipeline can be seen as the application of everything we defined so far. According to a blog from Semaphore: “CI/CD Pipeline: A Gentle Introduction,” a pipeline can gently be defined as:
“A CI/CD pipeline automates your software delivery process. The pipeline builds code, runs tests (CI), and safely deploys a new version of the application (CD). Automated pipelines remove manual errors, provide standardized feedback loops to developers, and enable fast product iterations.”
Where is the benefit?
By implementing this mindset, as well as the tools, there are a number of benefits to it, such as:
- We can accelerate the rate at which we deliver code (or tests).
- The new tests can be easily integrated into the already existing ones and discover errors.
- Tests can be run automatically as scheduled jobs during the night when the application may have less use and does not affect the team’s performance.
- It can execute specific tests on demand, and
- It has metrics of execution results available for the entire team and the client.
This means that when applying CI/CD we can expect major benefits in the entire development/testing cycle. Time and early detection of failures are the most important aspects here that would improve the overall quality of the product/service we are building.
It is important as well to keep the pipeline and the tests as updated as possible so that every time it runs, we are completely sure that the tests are evaluating the health of our code. In turn, this implicitly improves our confidence in what we are delivering to the client.
As there are a lot of tools available on the market – and most of the development platforms, such as GitHub, offer their own – we have plenty of choices that may suit our needs. This is a major benefit as well because we are not tied to any specific one. We can use free tools, however limited, like Jenkings. Or, in contrast, we can pay for one and adjust it according to available resources.
Also, having a pipeline integrated into our entire development/testing cycle will most certainly reduce the risk of bugs and issues being introduced into production stages, improving the quality of the product we are delivering to our clients, and the time spent fixing critical errors in those environments.
These are just some of the benefits we can expect when integrating our testing framework with CI/CD tools. Sadly, the downsides are not that pleasant and I will try to comment on them without scaring anyone (I will do my best).
The ugly part
There are a lot (and I really mean A LOT) of tools that can help create and implement pipelines. Most of them have come a long way to be as user friendly as possible. However, they still involve highly technical knowledge and not all of us are accustomed to using them or even configuring them.
Besides that, most of the available tools are paid or have very limited free options, which makes them not entirely suitable for our needs. If you don’t have the necessary budget, you may be able to use the free tools, as limited as they are, to improve and enhance your testing work nonetheless.
Configuring a pipeline can be a real nightmare. Most of the tools have guides and documentation that can help you set up everything you need. But trust me, you will spend some time, especially if you are new to this, troubleshooting and making changes until you get it right and can start using it.
This seems to be a very complicated process but do not despair my dear reader. I am writing a small and easy guide for you to set up a sample pipeline in some of the most used tools in a future article.
So, is it worth it?
At the end of the day, implementing CI/CD to your project will improve every aspect of your daily job if you keep that “push frequently, deliver faster” mindset. Once the configuration has been set, and it can take some time, the benefits are far greater than the problems caused by tools or any other impediment you may face.
The learning curve may seem steep but the products we create can be greatly affected and improved when implementing CI/CD as a standard within our teams and our company as a whole.