Path To Continuous Test Automation Using CI/CD Pipeline
Introduction to CI/CD
Continuous Integration and Continuous Deployment pipeline has become the primary approach in Software Development Life Cycle(SDLC). As a matter of fact, CI/CD pipeline tools have evolved a lot in the past few years. However, still developers, QA and other technical peeps find challenges in implementing an effective CI/CD pipeline. As the name suggests, it allows developers to deploy code continuously and detect bugs at an early stage and avoid integration issues rising due to frequent source code commits. This article would further highlight the in-depth coverage of CI/CD pipeline with the introduction to different CI/CD tools available and also few salient points for QA to implement a productive CI/CD pipeline. Before moving forward, let’s clear the basics towards CI/CD pipeline.
What is Continuous Integration?
When a product is in the developing stage, the technical team frequently code, build, test and deploy features. Continuous integration has been typically adopted to automate this usual process by developing a script with a motive to detect a change automatically in the shared repository. Changes can be easily detected using periodic monitoring, polling or by using a push out mechanism like webhooks.
As soon as the changes are detected by the CI tool, the CI platform automatically pulls a copy of updated code in the CI workspace, builds it, performs unit testing and compatibility checks to identify code loopholes at an early stage. Continuous integration has been majorly adopted to ensure integration of bug free code.
What is Continuous Delivery?
Continuous Delivery is the process of delivering bug free features in a safe and sustainable manner to the staging or pre-production environments. This stage of CI/CD pipeline elevates the advantages of continuous integration by increasing the scope of automation testing beyond unit testing.
As soon as the pipeline surpasses the continuous integration operation, the continuous delivery operation gets triggered to verify application updates across multiple dimensions (non-prod environment) before deploying to customers. This process makes delivery predictable and ensures a stable state of code even when developers are constantly making changes to it.
What is Continuous Deployment?
Continuous Deployment further amplifies the reach of continuous integration and continuous delivery. It is said to be the final stage of CI/CD pipeline. With continuous delivery, the continuous deployment enhances a test driven approach to validate the application on different environments and roll out deployments automatically.
With continuous deployment, every change that passes all the stages of the pre-production environment is released to the customers i.e. production environment. Developers can freely focus on building software and in just one click they can see their work go live once the build is successfully released.
Elements of a CI/CD Pipeline
Let’s categorize the CI/CD pipeline in its own sub-tasks for better understanding:
- Change/Update in code
- Initiate Build
- Build
- Validate Build Results
- Automated Testing
- Determine Test Results
- Deploy to Staging Environment
- QA Testing
- Deploy to Production
- Smoke Test
These processes can further vary from team to team and company to company.
CI/CD Pipeline For Test Automation
In an agile model where development and testing are parallely proceeded wherein the goal is to detect application issues in an early stage to expedite the bug free release of a build. The process of test automation further reduces the testing efforts and also reduces the amount of time used to get blown in manual testing.
Automation testing always has a place in CI/CD pipeline which can improve team agility towards automation. At this point of time, it is important to be clear that automating a CI/CD pipeline and integrating test automation are two different things. Once test automation is integrated with the CI/CD pipeline, testing then becomes a foremost part of the pipeline as mentioned above in the CI/CD elements.
Teams can tackle a wide variety of tests using CI/CD pipeline like smoke testing, regression testing, api testing, load testing, cross browser testing etc. Amongst this, smoke testing is mostly integrated in pipeline with a goal to perform smoke testing as soon as a new build is deployed on a particular server.
Ultimately, the purpose of adopting CI/CD pipeline is to generate fast, accurate and reliable outputs for the entire development cycle. Hence, it is important that the pipeline smoothly covers the below factors:
- Speed
Continuous integration and deployment is majorly endorsed to get instant feedback. If the developers have to wait longer for the build to be verified by QA, the flow can be considered as disrupted. In such cases, developers have to wait for one build to get verified before moving forward. Hence, CI/CD processes must be configured in a way where the build can be released at a fast pace without compromising with the product quality.
- Accuracy
Adopting CI/CD pipeline for automating the deployment process is a great start. However, it would not be functionally beneficial unless and until the pipeline results are not accurate and transperent between the deployment process.
The more accurate the pipeline is, less human intervention would be required for monitoring the pipeline process starting from integration to deployment.
- Reliability
Maintaining a reliable CI/CD pipeline enhances the quality and speed of building and deploying new updates significantly. Reliable pipelines can further ensure a stable output with the same input without any errors in runtime. In a case where the workflow changes, the pipeline must remain reliable and resourceful to support the new updations.
- Comprehensive
A powerful CI/CD pipeline needs to cover as many possible aspects to deploy a build in a seamless manner. Just a single error can make the entire pipeline process a disaster. Once the pipeline is thoroughly set up and the development team gets a comprehensive response, the pipeline can be further optimized with the required configurations for flawless integration and deployment.
Most Preferable CI/CD Tools
Nowadays, we have a lot of CI/CD tools available in the market which makes people confused to select the one that is most suitable to the project requirements and within the budget. To make the selection easy, we have listed below few top most preferable CI/CD tools with their features:
- Jenkins
Jenkins is Java based, open source CI/CD tool. Along with continuous integration, its scope can be extended to continuous delivery. Setting up jenkins is quite easy as it just includes the installation of a WAR format file. Once installed, it can simply be started from the terminal. Jenkins pipeline is implemented using DSL (Domain Specific Language). It is said to be a widely used CI/CD tool as it is an open source tool and has been utilized since long in a market.
Features of Jenkins:
- Enables real time testing and reporting
- Compatible with Linux, MacOS, Windows
- Variety of plugins available to build an in-house ecosystem
- Can easily be integrated with cloud based platforms such as AWS, Azure, Google Cloud, etc
- Since it is an open source tool, it is affordable for startups
- Possible to accomplish complex CI/CD requirements and leverages parallel work performing
- CircleCI
CircleCI is another CI/CD platform that is preferable by many, it offers upto 1500 minutes of free build time per month. For small projects that have very little development activity can easily take advantage of CircleCI for multiple code repositories. CircleCI Cloud is a cloud based offering while CircleCI Server is an on-premise solution. Setting up CircleCI is easy as it uses YAML syntax for its pipeline configuration.
Features of CircleCI:
- It is easy to set up, maintain and integrate with version controlling platforms like GitHub, Bitbucket, etc.
- It supports a wide variety of programming languages
- To reduce the build time, the build can be splitted and balanced across multiple containers
- It leverages parallel testing where tests can be run in parallel against different executors
- The CircleCI server which is on-premise offering, can be easily integrated with multiple third party platforms such as AWS, Google Cloud, and other cross browser testing platforms
- CircleCI Orbs, a reusable snippet of code, helps in automating the monotonous processes and accelerates the pipeline configuration.
Download a Free Poster of the Popular CI/CD tools and their features
- CodeShip
CodeShip is a platform that implements and optimizes CI and CD in the cloud. It helps small and growing teams in developing from simple traditional web applications to modern microservice architectures by achieving fast, secure and frequent code delivery.
It is a demanded CI/CD platform as it offers the capabilities of testing, build and deployment directly from version controlling platforms such as GitHub. In its freemium plan, it allows 100 builds per month for unlimited projects. With it’s pro plan, it allows developers to choose which steps should run sequentially or in parallel and how many concurrent builds to run simultaneously.
Features of CodeShip:
- With CodeShip, developers can have a high control over CI/CD pipeline and can customize the environment and workflow anytime required.
- Seamless integration with third party platforms like notification tools, on-premise SCMs, security scanning tools, etc.
- Offers straightforward UI which makes setting up a pipeline super easy.
- CI/CD process can be sped up by declaring caching per service, preventing the docker image from building everytime from scratch.
- Debugging can be done from CI itself using SSH.
- Supports parallel test pipelines for which implementation is done in codeship.yml
4. GitHub Actions
GitHub Actions was introduced just a few years back (2018) and has become a good competition in the CI/CD market. Using GitHub Actions, we can easily create a custom SDLC flow within the GitHub Repo. The workflow can be designed with different Git actions and can further be triggered automatically based on certain events. With GitHub, you can now not only continue maintaining the code in shared repositories, but also build, test, and deploy the code right away using GitHub Actions.
Features of GitHub Actions:
- Create, share, reuse, and fork repositories within or outside teams
- Freemium plan offers 2000 build minutes per month for all private repositories
- Fully integrated with GitHub repositories, making the pipeline just from a single place
- Docker support can be added to perform multi-container testing
- Offers multiple CI templates, though customized templates can also be created
Core Points For QA To Implement CI/CD Pipeline
Reliable and robust CI/CD pipelines are highly dependent on the automated framework running behind the scene. The results for test automation matters a lot for a stable delivery on a regular basis. Hence, it is important for QA to implement a pipeline that can extract as much value out of CI/CD tools as possible.
Implementing an effective CI/CD pipeline is no more a headache now. As we have discussed above, there are a lot of CI/CD tools available in the market offering various resources and integrations to configure a seamless pipeline. Below are a few core points that the QA will need to implement to breed a fruitful CI/CD pipeline:
- Choose the right CI/CD tools for your projects.
- Document your CI/CD pipeline elements.
- Utilize an effective testing workflow with test automation tools.
- Identify which processes CAN and SHOULD be automated.
- Identify weak points that lead to crashes and update processes.
- Promote collaboration between developers and testers.
Developing a CI/CD pipeline for either small or large scale projects, the motive has always been to achieve improved performance, efficiency, ROIs, and reduced cost within an expected value of time.
Published on Java Code Geeks with permission by Ramit Dhamija, partner at our JCG program. See the original article here: Path To Continuous Test Automation Using CI/CD Pipeline Opinions expressed by Java Code Geeks contributors are their own. |