Test automation process refactoring
What is CI/CD (For the person who is not familiar with it)
CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment. CI/CD is a solution to the problems integrating new code can cause for development and operations teams.
Specifically, CI/CD introduces ongoing automation and continuous monitoring throughout the lifecycle of apps, from integration and testing phases to delivery and deployment. Taken together, these connected practices are often referred to as a “CI/CD pipeline” and are supported by development and operations teams working together in an agile way with either a DevOps or site reliability engineering (SRE) approach.
Our pain points in current test automation process
- Low code readability
We need plenty of time to realize the code in Jenkins because this process is to make the decision for which automated test should execute while we do some changes to our service. So it’s difficult to maintain by people who are not the author.
- Low efficiency
Based on point one, it needs to go through the whole process to determine the corresponding automated test. Therefore, it takes lots of time to run itself as soon as we commit the code change.
- High maintenance cost
Because we use the CI tools called Jenkins previously, which is separate from our source control system Gitlab, but GitLab has its own CI feature, I just wondering why don’t we use it instead of Jenkins, to reduce the cost that we need to maintain between Gitlab and Jenkins to run the pipeline.
Our solutions (correponding to the problem above)
- Modularity - divide each job into a specific YAML file / template - extend the YAML files we’ve modulized / documentation (use readme and Notion)
- One to one Mapping to reduce decision time - set a fixed variable in our service, and it will trigger the following test case
- All in Gitlab - Integrate our codebase and CI/CD pipeline
What is Gitlab CI/CD
1. Introduction
Gitlab is a source control management tool that we could use to do version control. Once you push your code to its server, it would be permanently stored, and anyone who clones this repository could have permission to collaborate.
Otherwise, it also contains a feature called Gitlab CI/CD, including continuous Integration, continuous delivery, and continuous deployment respectively.
2. How to quickly setup
a. Create a file called .gitlab-ci.yml (Major file to execute CI/CD pipeline)
b. Design your stage (ex: build、test、deploy), for each stage it could contain several jobs (ex: build-job1、test-job1、deploy-job1 …)
c. The pipeline would run regularly after you committed the code to your repository every time
d. After running the pipeline, Gitlab would choose a runner to execute your process
3. Some interesting methods in Gitlab CI/CD
- resource group: It is used to restrain the job that should be executed in order. Whatever it is oldest first, newest first, or random. So this method could make sure that each job would wait for the other job to release to the resource.
- Hidden job: It could be inherited by the job who extends it, so we could use this concept to design our global-used job. (if your CI process in each project is very similar, you could use hidden jobs to construct your template)
Conclusion
There are so many CI tools on the Internet, just think about which tool would be more convenient or the usefulness is higher, and then implement the CI/CD process into your SDLC, I think it could speed up your process and make sure the quality of the products.
