Allure Testops is built upon the idea of automation as a service. It means that using automated tests should not be an arcane specialized skill; rather, it should be a simple function, available to the entire team, and to management. Implementing this idea has taken a lot of work, and a very important part of it is providing comprehensive integrations with CI servers. This enables launching tests on the side of Testops and receiving the results there, effectively controlling the entire testing process from just one screen.
The fact is, Allure Testops has more integrations with CI servers than virtually any other tool - here is a list of everything we've got:
Perhaps the only exception is Katalon TestOps - however, that one only works for Java, whereas Allure Testops is polyglot (by the way, achieving that has also taken a lot of work). Testomat has 6 integrations versus the 10 of Testops, and nowhere near the same level of functionality.
Which brings us to the second point. Quantity isn't everything. Most of the time, when people say they've integrated with a CI tool, they mean a one-way integration, often written through webhooks. Not the case here.
Two-way
Allure Testops provides two-way integrations. You can both initiate test runs from within the tool, and receive test results there. Which means that for a lot of roles, you don't ever need to visit the CI.
There are plenty of advantages here, for instance, controlling everything from a single space is always easier, and also, you'll have to pay for and manage much fewer users in your Gitlab or Jenkins.
Zero configuration
The general rule for all Allure integrations is that they should work out of the box - once the installation is complete, you don't need to fiddle with anything to run the tests. This applies both to language integrations, frameworks - and to CIs. For particulars, you can take a look at how to set up the Jenkins integration.
API vs webhooks
Tools that use webhooks to receive data from tests run into serious bottlenecks. If each of your tests sends a HTTP-request when it's executed, and you've got tens of thousands of tests - that's quite a few requests.
We've got clients that have millions of tests - imagine the load if they were executed that way. And what if the network fails during transfer?
In Allure Testops, test results are saved to the file system, and then a parallel process transfers them. This solution is faster, more stable, and has plenty other advantages. For instance, you can prioritize what you're sending - first the results, then the attachments. If the client's system isn't high-end, they won't need to endure the long wait for attachments just to see if the tests have failed or not.
Conclusion: two-way, across the board
Full-scale, two-way integrations across the board mean that the complexity of administering continuous testing is hidden behind one interface that controls the entire process. The whole thing becomes more stable and reliable. In short, this is automated test automation done right.
