Integrating Automation Testing Into Continuous Delivery And Continuous Integration Process

We just had the opportunity to experience the development of the system by implementing CI/CD principles, and there was a feeling that it was much easier and faster. That could help in the delivery of a workaround and send them quickly to make feedback quickly. Using Jenkins for CI/CD – Data Insights So, let us get to know CI/CD a little better in this article.

Continuous Integration (CI)

It is a process used for automatically integrated software collection, possibly by one or more developers. Finally, the software we develop in small pieces and the software which is already complete must be combined into one large piece to ensure that no parts will damage other parts.

As it is developed by multiple programmers, it is possible that there will be a bug to fall out of any part. So how do we prevent it, so that script that automatically tests the compatibility of each piece by beginning testing from unit testing? That, almost always, is the responsibility of the development team. In the world of development, the build server is often used to help achieve the target. In other words, the integration will start when the source code has changed in the central repository. We will perform code checks after the changes made to check whether they work together from Compile testing. Some continuous delivery tools are:

1. Top Overall – Buddy.
2. Software Containers – JBoss, Tomcat, HUDSON.
3. Build Tools – Ant, Rake, Maven.

Continuous Delivery and Continuous Deployment (CD) always come up with questions about how different it is. Continuous Deployment is done in every step up to the deployment and production is carried out entirely automatically. Continuous Delivery is the task in the deployment pipeline that will start from compile, building to test procedures such as acceptance tests to all automated. The process of deployment, production must be approved or made first from Business, which is manual.

Also read: Tools For Continuous Integration

Continuous Delivery and Continuous Integration

But we both deploy to Staging Environment and deploy to Production Environment as manual One-Click Deploy. As part of the system test kit. The QA will select a test case set that could be the smoke test, regression test when it comes up for each component. Continuous delivery can be thought of as a factory too. To write automated scripts testing, we use Git through the source tree to manage the source code in the automated test case, and use Jenkins in the config, and instruct to run automation testing series in each environment. Continuous Integration tools enable you to stick to your team’s quality criteria by operating tests every time you push a recent commit and reporting the conclusions to a pull request. 

When Do We Use the CI/CD Processes?

We use automation testing in the process of CI. In other words, every change in one of them is a test. Of course, automated testing is unit testing, integration, and functional testing. This explains since developers start development. Our system development team divide the environment into 4 parts:

Local, Alpha, Staging, Production has the following steps: 

1. Developer: When the feature development is complete, they build, test, and run on their machine (Local) to make sure the system works properly and ensure that things change do not affect other parts.

2. Then, you must pull the latest source code from the repository of the system to determine if changes are made. Merge the developer’s machine first, then build, test, and run again.

3. When the central repository is changed, the CI system must build, after that, we will forward it to the run unit test first. If it passes, it is to be forwarded to the continuous delivery system to deploy to the alpha environment.

4. When we deploy the source code to an alpha environment, it will trigger the automation testing in the level of the smoke test.

5. After the smoke test is finished, if the run has detected any errors, it will not pass on to the continuous delivery system to the deployment to staging. The QA will investigate what caused the bug in the system. If there is a bug, it provides developers to make edits and deploys to re-test. New Loop and Loop will go on.

6. The case after the smoke test runs through all the pipeline of continuous delivery systems to deploy to the staging environment. When we deploy the source code to staging, it triggers to run automation testing in all the levels of regression testing. QA will test to meet the requirement for staging the entire environment that will be deployed by fixing the bugs that QA encounter or that reoccurs from the regression run test.

Pros & Cons

Pros: We can test it frequently, knowing the state of the system at any time and always receives feedback on the system. We can see the progress of development whether it’s good or bad.

Cons: if the writing of a test script is bad, it may cause the system to block the deployment, such as when we run the test. After the failure, we know that the failure is from writing the wrong script, not from the system. 

Finally, I hope that all of this will be enough for you to deploy to the team or the system development process of yours. It’s not entirely right to use it to match your work. If you have any further questions regarding automation testing with the ci/cd pipeline, please feel free to address them in the comments section below.

Also Read: Continuous Integration And Continuous Development