Tutum has recently unveiled its new building and testing capacities that the company believes will be a “huge step forward” in supplying developers with second-to-none CI/CD tools. The updated feature is the accumulation of months of planning and collaboration, a recent blog by the company reported.

The team at Tutum hope its design goals of creating a flexible, agnostic, automatable and locally replicable solution for build and tests, which mirror the goals for the Docker project, are met. This intention is also the reason they based their solution for CI/CD on the open source image tutum/builder.

Let’s dig a little deeper into the update. Tutum’s blog describes its tutum/builder performances as having the following capabilities:

·        Configure docker credentials using $DOCKERCFG.

·        Clone the repository using $GIT_REPO and checkouts the commit in $GIT_TAG.

·        Build the docker image specified by $DOCKERFILE_PATH.

·        Push the image to the image tag specified in $IMAGE_NAME.

However, just how does the organisation hone in on the right variables in order to automate builds in Tutum? The solution lies in the company’s new Repositories UI, which allows for the registration of Docker repositories (from Tutum Private Registry and/or external registries like Docker Hub Registry) with valid credentials (needed to configure $DOCKERCFG) which are then associated to Github repositories ($GIT_REPO).

Through this process, Tutum generates a webhook in your Github repository. This then hits the Tutum API for every commit and supplies the value for $GIT_TAG. DOCKERFILE_PATH and IMAGE_NAME, which are configured by the user for every image tag.

While this set-up would usually result in orchestration problems, Tutum has created a solution that involves the deploying of the tutum/builder image, using the “emptiest node” implementation strategy for Github webhook. These calls will then match your build settings. If any nodes are tagged with builder, only those nodes will be utilised for the build executions. Moreover, once the build container is finalised, Tutum is notified via our events container, which notifies the Tutum API for every docker event.

Additionally, build containers are automatically terminated after executing. However, before execution, the program collects build logs in the build associated Tutum action, allowing for easier troubleshooting should possible issues arise. If the image is pushed successfully, your CI/CD workflow can be finished using their autoredeploy flag or our redeploy triggers.

Tutum capitalises on established tools by permitting the user to define a docker-compose.test.ymlfile that tutum/builder will spin up. Tutum/builder assumes the user has a definitive sut (system under test) service on it, which is accountable for running tests.

Tutum is an excellent device for managing CI/CD workflows against existing tools. It simplifies the configuration automation process for build and tests from Github push events, while maintaining functionality in your own infrastructure.

Tutum gives the user full control of their resources, thus enhancing performance, reducing costs and creating a predictable build execution environment. Finally, using individual nodes, Tatum exploits its caching mechanism while building and pulling docker images.


If you’re looking for a new role in DevOps speak to Alex alex.orphanou@talentinternational.com

Alex o