Amplify your testing with more configurations!

View the Project on GitHub STAMP-project/camp

What is CAMP?

CAMP (Configuration AMPlification) takes as input a sample testing configuration and generates automatically a number of diverse configurations. The generation is guided by predefined features and constraints, and utilizes a set of reusable pieces. The current version of CAMP is focused on the Docker environment, and the input and output configurations are specified as Dockerfiles or docker-compose files.

If you try CAMP, feel free to:


Quick start

The fastest solution is to use docker to run CAMP and all its dependencies in one container, using the following command:

fchauvel@debian$ docker run --name camp \
             -it \
             -v /var/run/docker.sock:/var/run/docker.sock \
             -t fchauvel/camp:latest bash
root@9dd7e1f061ce:/camp# cd samples/java
root@9dd7e1f061ce:/camp# camp generate -d .

The Docker image include all samples available on Github.

Here are the three main CAMP commands:

CAMP Inputs

CAMP requires two inputs:

  1. The CAMP Model, which is a YAML file that describes the pieces that can vary in the orchestrations. These may be service providers, feature providers, version or other numerical configurations.

  2. A template orchestration that illustrates how the components listed in the CAMP model are bound and configured together. So far, CAMP only supports the Docker technologies and the orchestration must be a docker-compose file.

From there, CAMP will generate, realize and execute alternative configurations, each with alternative variations.


In the samples directory of the repository, there are two examples, XWiki and CityGo.

How does CAMP work?

CAMP extracts from the input Docker specifications an abstract configuration model, and tries to synthesize new models based on the features, variables and constraints. The figure below illustrates the approach: Alt text The new models will then be translated back into Docker specifications. These specifications can be executed in the same way as the original input, and therefore to replace the original testing configuration during either the manual testing or in a continuous integration pipeline.