Difficulty: Beginner
Estimated Time: 15 minutes

In the previous Katacoda scenarios, all the services were deployed in a single host which is the simplest setup to verify a System Under Tests (see Run CNTT Kubernetes Based Reference Conformance). Here, you will rather span the different services accross multiple hosts leveraging both XtestingCI and Ansible.

Finally you will deploy a Jenkins agent which is the classical solution to share the common builds accross multiple servers or to execute the test cases as closed as possible from your System Under Tests.

As already mentioned, switching from Jenkins to Gitlab CI becomes as simple as writing 3 Boolean values in a text file.

To illustrate the deployment models supported by XtestingCI:

  • it's been successully tested vs centralized Jenkins in Orange
  • it's used to generate all 3000+ Functest jobs without deploying any service.

Try it, you will love it!

Distribute your Continuous Integration toolchain

Step 1 of 5

XtestingCI design in a nutshell

XtestingCI supports multiple deployment models such as all-in-one (in Docker or in Kubernetes), centralized services (e.g. OPNFV toolchain) or a mix of both.

It follows the KISS principle, by spliting all deployment and configuration steps and by leveraging urls for any configuration action. The same operations can be applied whatever the services are deployed via Docker, via Kubernetes or via any other way out of XtestingCI.

XtestingCI defines lots of variables to finely select the services or the steps you want to execute. For instance, jenkins_deploy decides if you install Jenkins or not, jenkins_configure (in addition to jenkins_url) if you configure it. The same model is generalized for all the services.

The default configuration setups the following services in a single host but you're free to change it at your convenience; it's just about setting booleans and urls:

It's worth mentioning that all steps and urls are calculated as much as possible for the best user experience.