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.
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
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…
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 (which currently runs version 10.5)
- 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”.
- 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
- 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).
- When finished a public IP adres appears
- Point a wildcard DNS to this IP
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”
- 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”.
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;
git clone firstname.lastname@example.org: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
git add -A
git commit -m “Go Auto Devops”
Please note that “blog-springboot-autodevops” is my GitLab project and should be replaced by yours.
MAGIC IS HAPPENING… MAGIC IS HAPPENING..!
Now quickly go to your project page.
Click on the pipeline / commit icon..
Click on the pipeline instance number
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.
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.
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.
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.