As we all know, the enterprise standard for running tests is doing it remotely, on a server, to allow automated execution independent of any local environment. Historically, one of the most popular ways of hosting and launching tests has been GitLab.
GitLab CI/CD is a part of the larger platform of GitLab that stores code and provides version control. That code storage is where the YAML files for your pipelines are stored, so it all works nicely together. In turn, the CI/CD is used to launch a whole bunch of other functionality, like vulnerability scanning, releases, instrumentation, etc. The spectrum of functionality available for you in your repo is quite broad:
Allure Testops works with pretty much any popular modern CI/CD server, and GitLab is an excellent choice to pair with it.
The intent behind GitLab
- Convention over configuration. This is probably the thing that sets GitLab most apart from Jenkins. Jenkins gives you as many options as possible; GitLab tries to integrate best practices into the product. Everything should work out of the box, with complexity added later if needed. If this makes the workflow somewhat more restricted - that's okay as long as those restrictions are battle-worn. Limiting configuration is an actual conscious effort to encourage best practices; GitLab tries to educate its community this way. The idea is:
You should prefer well-considered choices based on current best practices. Avoid unnecessary configuration. Avoid configuration to support fragile workflows.
Avoid plugins. This is in stark contrast with Jenkins, whose architecture is built around plugins. As much of the stuff as possible will be provided out of the box; with Jenkins, you'll probably need to install plugins to get everything working even once. And unlike Jenkins, GitLab provides everything you'll need from just one interface, including the actual repo with your code.
Design for users, not intermediaries. Less configuration means people who maintain the tool might be less happy, but GitLabs creators say users' needs should be prioritized over those of admins. This means a low barrier of entry and a shallow learning curve.
Working by default. Because GitLab allows themselves to say what way of using the tool is better and what is prioritized, they can make each component work by default, out-of-the-box. You can run a pipeline with a full cycle of GitLab's features in no time - especially thanks to Auto DevOps.
Auto DevOps
Auto DevOps means that a default automated pipeline can be set up - yes, automatically.
GitLab was built so that you could get a fully functional CI/CD system really quickly. Say you've already got a working application, you want to run it remotely, and you're in a hurry. When you open up documentation, you've got like 150 pages staring back at you - a bit scary. A short manual gives you a "hello world" example; what you need is going to be more complicated. Auto DevOps is a magic button that generates a pipeline for you. If you've got a Kubernetes cluster, everything will be set up automatically - building, testing, security and license checks, and deployment.
This process isn't hidden in the backend; it works based on .yml files. Since that's also what the pipelines are, it's basically YAML building YAML. Which means the whole thing is fully configurable. GitLab uses its own syntax for the YAML files, and you have to know all the rules before you can write anything, so getting into it might not be easy. However, with AutoDevops, you might not need to. And, of course, there are also templates of pipelines for different use cases.
Allure Testops
GitLab, Jenkins, GitHub, and other CI/CD systems follow very different philosophies, but no matter which one you're using, Allure Testops will top off your testing stack nicely. The things our integrations do are pretty much the same for each of those systems: Trigger pipelines from Testops. Monitor the execution of tests live. Do selective reruns if necessary. Like GitHub, GitLab also works as an issue tracker, and Testops provides access to that functionality as well.
Setting up the integration
Our documentation page has an excellent guide on setting up the GitLab integration. The following are just the highlights.
GitLab has no plugin for Testops, so you must set everything up via allurectl.
You'll need to:
- authenticate Allure Testops for GitLab with a token
- add your Allure server instance information to the GitLab configuration
- configure a build job in GitLab (whether freestyle or pipeline) and add a command to execute the tests
- set up environment variables on both sides
Then, you'll need to set up the integration in Testops:
- add the required integration in Allure TestOps globally (you'll need admin privileges for that)
- add the required integration on the project level and provide credentials
Conclusion
If you want to get a running workflow quickly and spend as little time as possible maintaining it - run your tests in Allure Testops and host them on GitLab!
