Discovering Auto DevOps


For some time now, ASPgems has been researching new technologies that can open up a range of options when it comes to development. We decided to try Gitlab as a project repository and a continuous integration tool. This led us to want to investigate even more about the possibilities offered by this platform to develop.

One of these possibilities is Auto DevOps.

What is Auto DevOps?

Auto DevOps is a tool offered by Gitlab that allows you to quickly and automatically develop the continuous integration of a project. It automatically detects, builds, tests, deploys and monitors applications. All of this is reflected in automatic piping and environments that help to easily visualize errors.

Auto DevOps

All you have to do is upload the code to the repository and this tool will review everything for you. It also contains a lot of easy-to-use documentation.

Construction and testing

Before we start, Auto DevOps requires some tools to work:

  • Gitlab Runners. It is strictly necessary. These Runners can be both your own Runners and Gitlab’s public Runners. These Runners have to be configured to use Docker.
  • A base domain. Only if you want to enable the automatic deploy.
  • Kubernetes. Only if you want to enable automatic deploy.
  • Prometheus. Only if you want to enable monitoring.

First, the project must have a Dockerfile or use a Gitlab template in order to build all the necessary Docker images.

Later, we need to enable Auto DevOps in the project configuration.

Configuration -> CI / CD -> Auto DevOps

Once checked the option to use Auto DevOps, we must choose the deployment strategy that we will follow:

  • Continuous deployment until production. What is in master to production will be deployed.
  • Continuous deployment to pre-production and manual from pre-production to production. The code will be deployed from master to pre-production, allowing you to deploy to production manually.

Once we have decided the strategy, we can use Auto DevOps up to the test part, but we cannot deploy it automatically.


To start, we need a cluster of Kubernetes, either new or an existing one. This is very easy to do using Gitlab.

Operations -> Kubernetes -> Add cluster of kubernetes -> Create a new cluster with GKE / Add an existing cluster

In case of adding an existing cluster, we will need to introduce the corresponding information of our cluster to connect it to Gitlab.

Then, we will install applications inside the cluster. The possibilities are:

  • Helm Tiller. To manage Kubernetes.
  • Ingress. It gives a way to direct requests to services based on the host request or path, centralizing everything in a single entry point.
  • Prometheus. Monitors the project.
  • Gitlab Runner. Create a Runner inside the cluster.
  • JupyterHub. Allows multiple instances of a user’s server.

In this case, we want Helm Tiller, Ingress and Prometheus to be able to deploy our project automatically to production or pre-production.

Operations -> Kubernetes -> My_Cluster_From_Kubernetes -> Applications

Finally, we go to the Gitlab configuration to set the domain.

Configuration -> CI / CD -> Auto DevOps -> Domain

This domain is Ingress’s IP address mapped with suggesting below, something like

Testing Auto DevOps

Auto DevOps creates a pipeline and a separate environment for each branch of the project. This means that each branch will have its own revision environment, allowing you to see in real time all the changes uploaded to that branch.

As we can see in the image below, we have the production environment and a revision environment for a branch.

In addition, each time you upload the code you will have to go through all the pipeline analyses.

Pipeline Auto Devops

Another important possibility is monitoring, allowing visual control over each of the existing environments.

Monitorization of Auto DevOps


Finally, Auto DevOps can be modify from Dockerfile or Helm Tiller to buildpacks. It even allows you to adapt all the continuous integration to the needs of your project by copying and editing the Auto DevOps .gitlab-ci.yml.

If you liked this article or have any questions you can share it leaving your comment, or you can fill out the form on the right and we will contact you.