GitLab’s Auto Devops: Java spring boot with quality control to production in minutes (using kubernetes)

This blog explains how to use GitLab’s Auto DevOps for a spring boot application. I will give a quick tour through it’s features and will explain when I would use it. just started developing a brand new application using spring boot, this awesome new app delivers the feature which is most wanted by all internet users…. “Hello World!”.

What it does? Well it says “ Hello” to the whole “World!”, awesome, now let’s bring this puppy to the public. But this app requires;

  • The best written code
  • Fully tested code
  • No vulnerabilities
  • Horizontal scalable

Of course the world cannot wait for you to figure this all out, this is where GitLab’s new feature Auto DevOps comes to play (Auto DevOp currently is in beta state).

What is Auto DevOps according to GitLab:

“With Auto DevOps, the software development process becomes easier to set up as every project can have a complete workflow from build to deploy and monitoring, with minimal to zero configuration.”

And the fun part it actually does work.. sort of… automagically!… but still with some beta hick-ups…

Some context

If you’re reading this blog, some of the software I used may already be outdated. So in this blog I’m using;

I assume you already signed up for both GitLab and

I won’t explain every small detail since I assume you can find you way around GitLab, git and other “basic tools”.

Setup google cloud

Let’s setup google cloud to use kubernetes, If you already have access to another cluster… that will probably work to.

  • signup, sign-in and create a new project (will take a couple of minutes).
  • Go to “ Kubernetes Engine” -> “Kubernetes clusters”.
opening again can take a couple of minutes, since it will prepare “ things” for you…
  • While opening this page Google cloud will prepare Kubernetes. When this is finished, GitLab is able to create a cluster.

Setup Kubernetes in your GitLab project

Although GitLab already has template project we will start from scratch since this template doesn’t have all the cool Auto DevOps feature.

  • Create a new project in GitLab
  • From main project page add kubernetes cluster
Click “Add Kubernetes cluster”
Create on GKE
Sign in and select “Create Kubernetes cluster on Google Kubernetes Engine”
  • Fill in the name of the desired cluster, I went cheap and modified “numbers of node” and “Machine type” (creation of the cluster will take a couple of minutes).
  • Auto DevOps includes a couple of services which can be added to your cluster (I’ve added them all);
    * Helm tiller (needs to be installed first and actually allows GitLab to easily deploy the other services), Ingres (to setup a load balancer), Prometheus (add monitoring of your app) and GitLab runner (to execute runner jobs on your cluster).
GitLab is already deploying these application to my single node cluster.
  • When finished a public IP adres appears
  • Point a wildcard DNS to this IP
My DNS entry (Dutch provider

Done! We’re close to the real magic!

Setup Auto DevOps

  • Go back to the main page of your GitLab project and click “Enable Auto DevOps”
Kubernetes button disappeared…up to the next step.
  • A huge settings page appears, don’t be scared, just fill in the domain name you’ve appointed as wildcard DNS entry and select “Enable Auto DevOps”.
Don’t forget to scroll down a bit and press save… did happen to me…

Done! Getting closer…

Now create a project and push it!

Let do this quickly (I assume you know git and spring boot), create project, put spring boot maven app in project and commit;

cd /yourprojectfolder/
git clone
git clone
cp gs-spring-boot/complete/pom.xml blog-springboot-autodevops
cp -r gs-spring-boot/complete/src blog-springboot-autodevops
cd blog-springboot-autodevops
git add -A
git commit -m “Go Auto Devops”
git push

Please note that “blog-springboot-autodevops” is my GitLab project and should be replaced by yours.


The result

Now quickly go to your project page.

GitLab pipeline is running

Click on the pipeline / commit icon..

Multiples stages in the pipeline.

Click on the pipeline instance number

All stages created by auto devOps!

You wil see a full pipeline containing several build jobs:

  • build execute maven build and dockerize the application using docker image gliderlabs/herokuish
  • codequality do a code analysis on the code using codeclimate
  • sast execute security scan on code using gemnasium
  • sast:container execute vulnerabilities scan on docker using clair
    did look succesfull but actually failed when opening the log :-(
  • test execute test part of your code 
    did fail :-(
  • production deploy the application towards production
  • performance do bacis performance test

In all these jobs GitLab uses (external) docker images which quickly analyses your project to determine which build, test or scan tool it should use.

As result, sast results in pipeline, and unfortunalty a failed test and no production release..

What if it did work?

Fixing this in a patchy way is pretty easy. Via the GitLab gui you can “add a file”… select template: .gitlab-ci.yml… Auto-DevOps. If you’ve added this file just comment the test phase by adding a dot (.) in front of it. (Oh I actually didn’t check if it runs the tests in the build phase).

Some of the following screenshots came from a different project.

Merge request: A full pipeline with dynamic temporary review environment to review your changes.
Merge request: Link to temporary environment, results of the various scans and performance metrics.
Merge request: Performance metrics
Release (merged to master): a staging environment to preview the change, canary environment to first release on a subset of your containers (and thus users).

Conclusion & my advice

If you follow these steps your setup is ready within the hour, unfortunately the setup didn’t work out-of-the-box. But as GitLab states; it is a beta so I expect it will work when Auto DevOps loses it’s beta state.

Screenshot of GitLab docs

Would I use it? ….It depends.

GitLab Auto DevOps is nice way to bootstrap a project. You can easily create dynamic test environments for each of your branches maybe you will even release to production. Auto DevOps add all kind of quality checks which I normally wouldn’t add for a new experimental project (especially small pet projects). But using Auto DevOps you start from the get-go which quality in mind, like you should ;-).

But boy… magic really happens, magic is nice for cartoons… but not for building and releases application on which your business depends.

If you’re running applications on which your business depends you should know what happens.

Auto DevOps really saves a load of tedious research and configuration, thats for sure. But I do have some concerns; 
What does happen with your code before it gets added to the container? 
Do these scan tools share your code to external parties? 
Does the exact same thing happen the next time?

With these automagically created steps you never know for sure, you simply have to trust all involved parties. Which is actually the same for dependencies (external software components) you use in your code when building software… but for that reason the SAST and SAST:container scanning tools steps where added.

My personal advice;

  • Start with auto DevOps, bootstrap yourproject and play around.
  • Gain knowledge on the steps which get executed by Auto DevOps.
  • Build your own build definitions (gitlab-ci.yaml) and remove the magic.
  • Make sure all the magic is gone before you add confidential code and before you release application to production.

Want to read more?

This is my first blogpost on medium. Let me know if you liked it, so I will get motivated to write even more. Things I can share on this topic;

  • build a GitLab CI for spring boot with less magic.
  • Adding SonarQube in your GitLab pipeline.
Like what you read? Give Wijnand Top a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.