Efficient Release Management of Microservices Based Solution
Why microservices?
Microservices architecture is not a new technology on the market. No doubt you have already heard about it, or perhaps, your company even has already adopted it. Such a massive migration from monolithic architecture to microservices is based on the clear and powerful advantages of microservices:
- Agility. Microservices enable the creation of small, efficient, focused and empowered teams able to choose their technology stack and process. Such teams don't need to wait in order to deploy newly developed functionality to production. Such an environment is perfect for adopting Agile project management practices. Additionally, it significantly decreases time to market.
- Innovation. No secret that procedural and technological changes can be made more quickly and easier on a smaller scale. Teams are able to try out new things and quickly understand what does work for them and what doesn't. Such small-scale experiments will not impact the entire organization.
- Quality. Small and well-structured modules usually have fewer bugs compared to complex monolithic systems that usually have legacy “spaghetti code”. Also, such an environment simplifies automation of testing. As result, the quality will be essentially improved.
- Scalability. The first advantage is that each particular service can be implemented within the most suitable technology and/or framework: like business logic in Java, performance critical modules on Erlang. By design, the microservices architecture allows horizontal scaling that enables you to scale the system, fully utilize Docker and cloud advantages.
- Availability. Microservices simplify building highly available systems. Well defined, isolated components can be deployed, monitored and automatically replaced in case of failure. Also, any failure of any particular microservice will lead to just a system performance degradation instead of making an impact on the entire business flow.
Challenges with microservices releases
Of course, microservices architecture is not a silver bullet. As with everything in the world, it has its share of disadvantages and limitations. In this article I skip technical aspects and focus only on the challenges related to release and project management. From the management perspective I would like to outline the following challenges:
- Frequent releases. By its very nature, microservices architecture forces us to release more often in order to ensure rapid and granular delivery to our customers. Instead of a single release of a monolithic solution we will deliver a number of small releases of multiple microservices. From a release management point of view it creates planning, progress tracking and integration overhead. This situation will get to be even worse by considering a fact, that each service has its own release cycle.
- Variable development process. Scrum, Kanban or something else? No problem. Microservices architecture enables teams to choose their own development process without having to align with other teams. This is definitely good for development teams but can become a nightmare for a Project or Release Manager (PM/RM) who needs to create a single plan for the entire solution delivery.
- Dependencies between releases of microservices. All versions of relevant microservices have to be released in order to deliver a particular business function. This approach introduces a much larger management overhead compared to releasing just a single version of a monolithic solution. PM/RM has to aggregate those versions in a consolidated plan in order to answer the question, "When will the functionality be delivered?" instead of merely having to know a monolith release date. Delays of any version will cause an overall delay in the entire delivery process. That's why PM/RM should have a simple way to integrate multiple versions into a single deliverable package and track whether or not it has been delivered according to plan.
- Solution integration and end-2-end testing. This point is mostly valid for B2B enterprise solution with a number of client requested customizations. The entire solution should be configured specifically to each client and tested once the functionality is implemented in each particular microservice. To achieve that PM/RM needs to take a top-down view of the latest stable version of each microservices, have an overview of what versions are deployed and to which environment (environments pool or containers in a particular configuration) and coordinate testing and acceptance.
Jira has built-in versions and its progress tracking functionality. But, taking into account the abovementioned challenges, there are exposed areas to build an efficient microservices release process:
- It is not possible to define version workflow so it is not possible to see at which stage the version is. For instance, all functional requirements might be fulfilled, but the microservice version should pass load testing before being deployed to the production environment.
- Most likely, the various teams, who are developing microservices, will be working on their own Jira projects in order to have the flexibility to create their own development process. Out of the box, Jira doesn't have handy functionality to visualize and track versions from several projects in a single place.
- Also, it would be advantageous to aggregate several microservices versions into a single release which will represent desired business functionality across all services.
- The release can have its own workflow. For instance, before deployment to production, it might require end-to-end testing, even after B2B client acceptance.
Tools for release management
One can see that Jira has great flexibility and allows us to address these limitations in a number of different and effective ways: using embedded capabilities or by extending them with third-party apps.
You can refer to this helpful article on how to configure release management workflow using standard functionality: https://www.atlassian.com/blog/jira-software/jira-release-management-steps
An alternative way to organize microservices release management is offered by the Release management app.
Set a context
Let's imagine an organization with 5 teams who are working on their own microservices:
Each microservice has its own release cycle which is not synchronized with other microservices release cycles. Usually, each particular business feature delivery requires some changes in a few microservices.
Let's review how the Release management app can simplify release management orchestration.
Visualize versions from various projects on the board
One of the Kanban rules says "Visualize the flow". This rule is a very important concept as the majority of people on the Earth are visual learners so they can better interpret the visual representation of information. In the Release Management app it is possible to import versions from multiple projects and visualize them on the board. Out of the box, Jira has two version statuses: Releases and Unreleased. Releases Management app extends that by custom version workflow. The workflow is seamlessly integrated with embedded version statuses.
One particular advantage I would like to outline is the option to drag and drop versions from one column to another, so the release or project manager doesn’t need to jump between projects in order to update several distributed versions.
Create a multi-version release
While it is good to have all versions, from multiple projects, visualized on a single board, it remains an overhead to remember (or store in some other place) which particular versions have to be released in order to deliver a business feature.
In order to solve this problem, Release entity was introduced in the app. The release can consist of several versions. At the same time, each version can belong to none, one or several releases.
In our example, we can aggregate all versions to be delivered for Chinese market expansion into one Release and track them together.
Moreover, the Release entity can have its own custom workflow to visualize the activities that surround business feature delivery e.g. integration testing, performance or acceptance testing.
Build a timeline
Managing releases is not only about the statuses, but also about knowing precisely when some particular item will be ready. Timeline view is the perfect solution for this purpose. Also, it is well-suited to reporting.
API and integration with CI
Continuous delivery is all about automation. In the perfect world, the release management tool has to be integrated with a continuous integration server in order to automatically update version statuses after each deployment.
The Release Management app has a powerful REST API that enables seamless integration with the CI server by using webhooks. This would dramatically decrease the amount of manual work and managerial overhead.
Conclusion
Microservices architecture is a powerful software development technique that fits the modern market needs. It offers solutions to address scalability, reliability and quality issues, while dramatically decreasing time to market, which is crucial for highly competitive markets.
In order to fully exploit the advantages of microservices architecture, we need to decrease managerial overheads that tend to appear in a more granular and distributed setup.
The Release Management app helps to eliminate the overhead, automate routine operations and create a single workspace for RM/PM. Also, it brings better visibility and makes management of complicated, multicomponent releases simple and straightforward.
Was this helpful?
Thanks!
Yuri Kudin
3 comments