Globus Automation Magic
Submitted By Jenkins User Stefan Martinov
A digital agency in Munich finds a better way to serve clients through faster and more accurate builds using Jenkins.
Organization: German Digital Agency
Industry: Webshop / Webstore
Programming Language: Go
Platform: Android, iOS, Docker or Kubernetes, Linux
Version Control System: GitHub
Build Tool: Docker, Go
Community Support: Jenkins.io websites & blogs
Mornings in the office were much easier with improved stability,
release consistency, and a shorter release cycle.
Background: Working at a small digital agency, we solve problems for international brands as well as national SMEs and smaller, regional companies in Germany and Switzerland. For these clients, we wanted to have more reliable release cycles, to avoid issues with “works on my machine”, to automate time-consuming tasks, and move them out of the developer machine. We also wanted to improve security, and to give control to devs what to deploy where, as well as to have metrics & monitoring & notifications if something goes wrong with builds
Goals: Automating deployments, code validation, and various other automation.
Solution & Results: Firstly, we had the challenge of deploying a larger application to our stage/production environment. That was automated with bash scripts only and only some people actually had the experience of deploying the whole environment. Progressively it took more and more time until one person was spending 50% of his work time deploying the application to the stage environment. So, we started to automate steps one by one, so that at the end of the first iteration cycle, we had a completely self-service deploy system.
After that challenge, we wanted to verify that we can automatically test if all features were buildable so that developers didn’t have to merge in all the items in the common branch. We used the multi-branch feature that we build and tag all the containers so they’re tested, verified, and built. After each push they would be built and ready to be deployed.
We then started automating common tasks, such as cache reload, as well as running backups. The good part about running backups on Jenkins is that we’d see immediately if something is wrong since we did a Jenkins/Slack integration.
Later, we integrated Jenkins build & test validation through GitHub-actions since we already had everything set up. This helped us validate the builds easily by using Jenkins-CLI through GitHub-actions. We also integrated with BrowserStack that we run nightly full deployments and run unit, integration, and end-to-end system tests on the whole platform, so that we know a valid release is waiting for us in the morning.
- ThinBackup – Really nice to have a small backup for disaster recovery. Remember there are 2 kinds of people: those who do backups and those who will start doing backups.
- Blue Ocean – Since presenting results has never been so fancy.
- Google OAuth Credentials Plugin – Since someone else already set the correct permissions
- Jenkins Declarative Pipeline – Way easier to read
- Slack Notification Plugin – Gotta get those errors in a good place
Results were as follows:
- Improved stability and consistency of releases.
- Improved build times due to multi-threaded builds on server machines.
- The release cycle was shortened since we always had a tagged release ready in the morning.
- Improved developer confidence that their changes won’t completely break the application.
- Improved self-servicing of automated tasks such as forcing updates and clearing cache for non-tech people.