In this guide we’ll describe how to create a delivery pipeline that will:

  • build a Docker image with a web application
  • launch the application in a Docker container
  • run Selenium tests with Maven from a separate container

For the purpose of this guide we’ll use a Java project hosted on GitHub: https://github.com/buddy-works/node-maven-selenium-tests

Pipeline flow chart

On every change to the repository, the pipeline will perform the following tasks:

  1. Build a Docker image of web application
  2. Run 3 Docker containers:
    • container from the image built in the previous step
    • container with a Selenium server
    • container with Maven that will run the tests
  3. Depending on test results, the pipeline will:
    • [Passed] Push the image to the Docker registry & run the image on the server
    • [Failed] Notify the team via Slack

Pipeline configuration

First, we need to authenticate Buddy in the source code repository:

Next, we add a new pipeline and configure it to run on every push to the master branch:

A pipeline can also be triggered manually or on a time interval, on a pull request or a tag push, or using a wildcard that will define which branches can run it. For more information, check out out article on trigger modes in Buddy pipelines.

Actions

Now that we specified the target branch and trigger conditions for the pipeline, it’s time to add the actions that will run our tasks.

Build Docker image

On the actions view, look up ‘Build Image’ in the Docker section.

Define the Dockerfile and the context if it’s different than the directory with the Dockerfile. In our case, it’s front:

Configure Selenium tests with Maven

With the Docker image built and waiting, we need something to run the tests. Look up Maven in the builds & task runners section:

Enter the command that will run the tests, e.g. mvn clean install :

Now we need to add two microservices in the Services tab. Those are essentially Docker containers attached and linked to the main build container.

  1. The first should be the Selenium service for your type of browser. In this example we’ll use Selenium Chrome:
  1. Now, click ‘Attach another’ and select Custom service. Configure it to use the Docker container that we built in the previous step:

Make sure to set the port on which the application will work (in our case 80). This way Maven will not start the tests until the application has successfully started.

Configure Selenium details

Once configured, the action will run 3 interlinked containers: Maven, Selenium, and a custom container. In order to make it work, we need to configure the Selenium server to which the tests will connect and the address of the application that will be run.

In our application, we defined them in lines 23 and 30 respectively. The hostnames should reflect those entered in the services of the Maven action:

Variables like hostname can be defined in the pipeline as an environment variables. If a variable is not resolved in runtime, you can use the ‘Find & Replace’ action that will swap its values.

Push Docker image to registry

If all tests have passed successfully, the image can be pushed to a Docker registry:

Buddy has native integrations with Docker Hub, Amazon ECR and Google GCR. You can also push images to your own private registry:

You can find more information on building and pushing Docker images in our documentation.

Release application

The image is stored in the registry and ready to be released on the server. With Buddy, you can deploy it to a Kubernetes, Amazon EKS or Azure AKS cluster, or you can simply run docker-compose on your own server.

For more information on K8s, check out our guide on container orchestration on Kubernetes clusters.

Notifications

Letting your team know that the tests have failed – or your client that a new version is waiting for review – is key to any software development business, which is basically one continuous build-test-release operation. Buddy natively integrates with the most popular notification services, including Slack, Discord, and Telegram:

You can add two notifications with different messages: one in the primary section for actions that have finished successfully, and one in the on failure section sent whenever your tests or deployment have failed. This way you can keep the QA team informed whenever taking action is required.