Release management of microservices and infrastructure in 4 steps using Open Source tools
Microservices are becoming more and more popular, especially as the world moves to a cloud-based environment. As such, it is crucial for companies to understand how to effectively manage their microservice and infrastructure releases. In this article, we will discuss what release management entails in the context of microservices, including why you would want to undertake this process in simple 4 steps with a bonus step a the end . 😉
First things first, what are microservices
Microservices are small, independent pieces of code that can be combined to create larger applications. They often communicate through APIs and allow for the rapid development and deployment of new features by developers working in parallel. While microservice-based application architectures can offer some advantages over more traditional monolithic software implementations, they do come with their own set of unique challenges.
Why to adopt release management for your microservice soon as possible.
Effective release management is essential to the continued success of your system. In order to manage microservice releases effectively, you will need a well-defined strategy that includes automated builds and deployments as well as rigorous testing. Furthermore, for this process to be successful it must include effective tools for tracking changes in version numbers across all services within your system. Since microservices communicate through APIs, it is vital that all the services in a given system are held to high standards. An integral part of this process involves performing automated and continuous builds as well as deployments. To do so successfully, you will need to have effective release management with centralized control of you system and individual microservices version.
Make it flexible and scalable
It is important to make sure that your release management process can be adapted for changes in the future. This means making it as flexible and scalable as possible, so you do not have any surprises or issues down the road due to a lack of foresight when designing this workflow. It also helps to maintain version control across all deployments across multiple regions, which will help you to determine exactly which builds are deployed where.
👨🍳 For this recipe, you’ll need:
- Gitlab
- Docker containers
- A cloud provider, for this example we use AWS
With the right use of the ingredients above you can achieve the following structure, where every component of the system has to check in a centralised point of control which version for a particular microservice is allowed to be deployed to a specific environment and region.
Here is a list of steps:
Step one
Keep track of your releases in a single place, this can be something as simple as a yaml file in a git repository for version control. You’ll want to make sure that everyone on the team is informed and aware of updates which involve version changes. This part might require documentation or an internal wiki for example but you get the idea.
Step Two
In the same place, keep track of all your changes and releases. A simple git annotated tags combined with your ticket system will do. In the example below we use semantic versioning.
git tag -a v1.4.0 -m "my version 1.4.0 Ref#100"You can crosslink Gitlab issues in you commit messages, check the documentation for more details.
Step Three
Make sure your automated builds are effective and use the right tools for the job. In order to avoid version drift, it is essential that you apply changes in a way that makes them understandable by other developers who might be working on parts of your service.
Each individual microservice, will have a version checker step in its pipeline for each deployment, in this case the production deployments (check Gitlab environments and deployments for more) will only be triggered if a tag is pushed, and then the tag is compared against our release-manifest file, created on step one:
Step four
The version checker step, you can use a simple shell script from your central repository, same repository used to store our release-manifest.yml file to authorise or not you microservice deployment. This script will validate you versioned release-manifest file in each microservice pipeline and compare the authorized microservice version for deployment in that particular environment and region, here is a example:
🐳
Build your image from the Dockerfile provided and run this command in your pipeline:
You will have a step like this:
Bonus step! 🍾
If you want to have more automation, you can automate your microservices releases using Gitlab release-cli in the step before the version-checker:
Conclusion
In the end, effective release management is vital for microservices-based applications in order to ensure continued success and maintain a high level of quality going forward. In this article we discussed what it entails as well as some tips on how best to implement it effectively into your system’s current workflow from the very beginning.
Linkedin: https://www.linkedin.com/in/woltter/
Github: https://github.com/wvxavier
