Imagine you are a developer and you have just pushed a change that breaks the build. The Continuous Integration system, Jenkins in our case, sends you an email to notify you about this failure. BORING! Here are six examples that you can use to spice up your alerting and motivate your Development and Operations teams to react to alerts faster.
So, you want to do rolling updates of your services in Kubernetes to achieve zero-downtime? That’s what we wanted to reach too, and what we’re doing now (mostly). Our journey involved quite a bit of research, filling of gaps in our lacking knowledge, learning from a multitude of mistakes, and a fair bit of trial and error. To make your journey more efficient, here is what we learned.
Recently Team Alfonzó, with help from the Build Team, took the next in adopting a new build infrastructure. We wanted to move away from Jenkins and the TOPdesk DockerHub registry, towards a more distributed infrastructure. Our Implementation Wizard project gave us the opportunity we were looking for to start making use of GitLab’s CI and Registry features.
How does GitLab compare to a Jenkins pipeline script?
If you have ever written a pipeline script for Jenkins you will probably find GitLab’s solution more refined and aesthetically more pleasing. Here – instead of Jenkins’ Groovy based DSL – you write a yaml file in which you list the build stages and specify the scripts that should run at each stage. Yaml syntax provides you with a sensible structure, while preserving the freedom you need to configure the build. Unfortunately it lacks the possibility to try out scripts without committing and pushing to the code base. You might want to be aware of this before unwittingly flooding the change history with CI-related experimental changes.
One year ago we set ourselves the task of doing Continuous Deployment on the SAAS environments running our application TOPdesk. Today we’ve improved our release rate from once every 6 months to once every week. These are the steps that brought us success.
Step 1) Set a clear and ambitious goal
In June 2015 we started out by setting a clear and ambitious company goal:
80% of our customers’ environments have to be updated weekly starting from May 2016.
Setting this goal really helped us to move forward in two ways. First, it changed the discussions from “Should we do this?” to “How can we do this?”. These discussions were much more fruitful and helped us resolve a lot of our problems. Secondly, it helped us align people throughout the organization. Doing Continuous Deployment is not a Development or Operations effort. It affects how you sell, implement and support your product. We’ve spent quite some time getting everybody on the same page.