CI/CD Pipelines: A Basic Overview

Imagine a typical development cycle.

Let’s say a developer creates a series of awesome new features for a given system. The developer, excited to implement their incredible game-changing features, adds their updates to the project and creates a staging/test build. The developer then sends this new build to a tester, who then verifies the expected functionality of the SUT with all the new changes, either via running automated or manual test scenarios on the new build.

But now let’s say our handy testers find a few new defects related to some older existing features; the tester would then log these defects on the system indicating the discovered issue. The developer is now tasked with determining the root cause of the defect in the system, which could be related to any one of these newly integrated changes, and once the developer believes the issue is resolved they add their changes to the next scheduled update. This process repeats itself over and over each time a new feature is added to the system.

But how can we improve this process, and more importantly how do we prevent new defects from being introduced to the system in the first place?

What are CI/CD pipelines?

One way to improve this development process is to implement the concept of Continuous Integration. When we’re talking about Continuous Integration or CI, we’re really talking about having all of our development cycle steps working together in a cohesive manner. With the typical development cycle mentioned above, there are several steps between implementing changes and testing these changes, but with CI we can interrupt this process by building a pipeline to perform all these actions auto-magically! If we were using Jenkins (a common CI/CD pipeline server tool) a very basic pipeline file might look something like this with each pipeline stage clearly labeled:

In a CI process, each time a developer is ready to add their changes for a given feature, they can push their changes to the code repository which in turn kicks off the CI pipeline to immediately build and run any automated regression/smoke tests on the system with the new feature. If any of the automated scenarios were to fail, the results would be delivered to the team indicating the cause of the failure, and because we’re now dealing with incremental changes rather than a series of changes, the root cause is much simpler to determine! The developer no longer needs to spend as much time hunting around to find the cause of the issue, as there would considerably fewer changes at each step of the process.

Once our automated tests have been completed successfully, a new CI build is created giving manual testing an opportunity to confirm the functionality of the newly added feature. This also allows for a degree of confidence in testing, knowing our automated regression/smoke tests were successful, as well as facilitating communication between the QA team and the development team as they can discuss the functionality of the new feature more directly using this created CI build. This keeps everyone within the whole team involved at each step during the development life cycle. Once the new feature has been verified using the CI build, we can then begin the deployment process. 

Continuous Delivery (CD) is the other aspect of the CI/CD pipeline. When we’re talking about CD, we’re talking about getting new builds in the hands of customers frequently and incrementally. Using a CI/CD pipeline development process, we can get changes out to production efficiently by testing each change as it’s built as mentioned above. Apps are constantly being updated with new features, and new bugs are being found all the time, using a CI/CD pipeline methodology can allow for well-tested smaller changes to reach production much more expeditiously with confidence these changes are not introducing a flurry of new defects. 

So how do they work with automation?

CI/CD pipelines work intimately with our automation test suite. A huge advantage CI/CD pipelines have over other development methodologies is the immediate triggering of the automated test scenarios giving direct feedback to the entire development team with every change to the system. Without developers building the automation tests in tandem with their updates, it’s unlikely the automated scenarios in the test suite would handle any new features directly. However, it can help prevent new defects on older features from appearing by running regression/smoke tests frequently. It also provides developers with immediate feedback when they are creating their changes instead of waiting for a nightly or weekly automation test run or waiting for a manual tester to verify the new update. A CI/CD pipeline helps to integrate the automation seamlessly into the development process, ensuring the automation scenarios are executed with every single update to the system. CI/CD pipelines require some setup to get the most benefit, however, once the pipeline has been developed with integrated automated test scenarios, a CI/CD pipeline can drastically improve the development process, and get quality products into the hands of customers efficiently with fewer defects.

For related reading on Continuous Integration, check out these blog posts:

• An Introduction to Continuous Integration
• Will Continuous Integration (CI) and DevOps Mean the End of the Traditional QA Skillset

If you need a reliable testing team to work alongside your developers, we’re happy to chat.