If you are familiar with the DevOps culture, you know that one of the main pillar is the automation of processes. As well as testing your code as often as possible! In this article we’ll present you how you can use continuous testing to gather automation and tests 👇🏻
Quick definition of CI/CD
The Continuous Integration and Continuous Deployment are two processes implemented in DevOps. We can say that the CI is the integration of the changes your team can do in your code as soon as they are ready (continuously in short). The CD is the continuity of CI: the automation of deployment.
In other words: CI/CD is the automation of the integration and the deployment of your code! It improves your time to market, and helps your developers to focus on their code (they can spot mistakes as soon as possible). Not forgetting your customers! They’ll be happy because they can access your new feature faster.
What is Continuous Testing?
Now that we recall what CI/CD is, let’s focus on Continuous Testing. In DevOps, automating the tests is mandatory to help you maintain your code quality and avoid side effects while developing. With it, you’ll obtain better and faster results without losing too much time.
Continuous Testing is the addition of tests in your integration pipeline. They can be located in different stages. At Go2Scale, we mainly use the Static_tests and the Dynamic_tests’ ones!
As we said, there are many types of tests. Let’s focus on two of them: static tests and dynamic tests.
Static tests are the tests you can do on your code without a running environment. It’s an exploration of the code itself, and it doesn’t depend on the user’s action.
In opposition to static tests, dynamic tests allow you to test the behavior of your code. You need a running environment to perform your dynamic tests: you can for example use a testing environment, that would be built especially for your tests, and would be destroyed when you’ll merge.
The tool: R2Devops
How it works?
In the job’s documentation, you’ll find an include link you can directly add in your .gitlab-ci.yml file, in your pipeline. Many jobs are ready to use, others might require a bit of configuration. In any case, you can adapt generic jobs to fit your needs and test your code in the fastest and safest way possible. Plus, the community and the support team will answer your questions and help you implement them. ✌🏻
The power of community and open-source
You can’t find the job you need in the library? You can add it following three simple steps. First, fork the hub. Then work in the issue you want, and then merge! All the steps are explained in detail in our contribution guidelines. Congrats, you are now part of R2Devops community. 🥳