Updated: November 2018 / Updated to actual status of Auto DevOps.

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.

So..you 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 feature Auto DevOps comes to play.

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.. automagically!

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;

GitLab.com

I assume version 11.4 some screenshots are made with version 10.5, which was the actual version of the initial blogpost. So screens may differ a bit, but are still look-a-like.

I assume version 11.4 some screenshots are made with version 10.5, which was the actual version of the initial blogpost. So screens may differ a bit, but are still look-a-like. cloud.google.com to use Kubernetes

SpringBoot version 2.0.0

MacOs with Git installed

I assume you already signed up for both GitLab and cloud.google.com.

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” — GL10.5

Create on GKE — GL10.5

Sign in and select “Create Kubernetes cluster on Google Kubernetes Engine” — GL10.5

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).

Specify cluster size — GL10.5

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. — GL10.5

When finished a public IP adres appears

IP adress visible in Kubernetes settings page — GL10.5

Point a wildcard DNS to this IP

My DNS entry (Dutch provider transip.nl)

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. — GL10.5

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”.

Screen for configuring Auto DevOps — GL 11.4

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@gitlab.com:wBlogs/blog-springboot-autodevops.git

git clone https://github.com/spring-guides/gs-spring-boot.git

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.

MAGIC IS HAPPENING… MAGIC IS HAPPENING..!

The result

Now quickly go to your project page.

GitLab pipeline is running — GL10.5

Click on the pipeline / commit icon..

Multiples stages in the pipeline.— GL11.4

Click on the pipeline instance number

All stages created by auto devOps! — GL 11.04

You wil see a full pipeline containing several build jobs:

build execute maven build and dockerize the application using docker image gliderlabs/herokuish

execute maven build and dockerize the application using docker image gliderlabs/herokuish codequality do a code analysis on the code using codeclimate

do a code analysis on the code using codeclimate sast execute security scan on code using gemnasium

execute security scan on code using gemnasium sast:container execute vulnerabilities scan on docker using clair

did look succesful but actually failed when opening the log :-(

execute vulnerabilities scan on docker using clair did look succesful but actually failed when opening the log :-( test execute test part of your code

execute test part of your code production deploy the application towards production

deploy the application towards production performance do basic 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.

What else comes with Auto DevOps

Committing to a merge request executes the build and tests, creates a preview environment. After preview you’re able to clean up this preview environment.

Merge request: A full pipeline with dynamic temporary review environment to review your changes. — GL10.5

Merge request: Link to temporary environment, results of the various scans and performance metrics. — GL10.5

When Promethius is added to the K8s cluster, GitLab will also monitor the performance of your application.

Merge request: Performance metrics — GL10.5

Advanced features for production releases like Canary releases, down-side; these are now premium (paid) features.

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). — GL10.5

Conclusion & my advice

GitLab did a great job in helping engineers increasing the quality of their application and running the, application in containers. I’m impressed!

If you follow these steps your setup is ready within the hour!

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 when using Auto DevOps you start from the get-go with quality in mind, like you should ;-).

But boy… magic really happens, magic is nice for fairy tails… 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, does it get altered?

Do these scan tools share your code to external parties?

Does the exact same thing happen the next time?

What is the quality of the build chain, container base images, scanning libraries?

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 your project and play around.

Gain knowledge on the steps which get executed by Auto DevOps. Know the tools which are used, and verify if they suit your needs.

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.

Updates

This post was initially written in March 2018 and is updated November 2018.

Changes: