How to manage logical grouping of microservice based application to ensure version compatibility for CI/CD Pipeline?

user_4387736 0
Viewed 358

For the MicroService Architecture based application, I'm trying to understand a standard process about how to logically group and manage correct version compatibility among independently deployable microservices. Let me elaborate with practical scenario :

Say, I am building a software application which is composed of 10 microservices. All the microservices have their independent repositories(branching workflow etc.) and their separate CI/CD Pipeline. The CI/CD Pipeline gets triggered whenever any change pushed to 'master' branch for respective microservice.

Considering Helm chart and Kubernetes based deployment, all the microservices will get deployed with version 1.0 for the very first deployment and our system would work. For subsequent releases, we might have only couple of services that will get deploy. So after couple of production releases, each microservice will be at different version to constituent an application at that point of time.

My question is :

  1. How to logically group independently deployable microservices in order to deploy or rollback to earlier release i.e. how to determine what was the version of different microservices for earlier releases?

  2. Is there any existing tool or standard practice to track versions of each microservice for given release to seamlessly rollback to expected release?

  3. If not automated solution, what would be the right approach to address such requirement?

Appreciate your thoughts and suggestion on this.

continuous-deployment microservices devops kubernetes continuous-integration
2 Answers

With consideration kuberenets: 1. Helm is nice tool to deploy and track. 2. Native k8s deployment works nice, you need to use deployment properly especially look --record flag in k8s commands eg check this link

With AWS ECS clusters: 1. they have task definations and tasks. I think that works for you.

Not have pointers for docker-compose, swarm, and other tools. But you can always use the power of git and some scripting. the idea is make a file that lists all versions of services/containers/code . and commit that file in git with code. Make tag out of it for simplicity. your script should compare this state file and current state and apply specific changes only. Look at git submodules also. it is nothing but a group of many git projects and it tracks status of each project with help of commit id of each project. This helped us in the situation you mention.

user_17369550

This is a fairly new problem, we just launched a new tool Reliza Hub to solve that. Also here is my post on the subject: Microservices – Combinatorial Explosion of Versions. Currently, we are at the MVP stage and a lot of work is going on - see this video tutorial if our direction makes sense for you https://www.youtube.com/watch?v=yDlf5fMBGuI

If you decide to implement and have any questions or need help with integration, just tag me on SO and I'd be very much willing to make it work for you.

To sum up few things that we are doing - we denote developer facing projects (those that map to source code) as Projects and customer facing projects (bundles that customer sees) as Products.

And we say that Products are essentially composition of Projects and provide tooling how you can compile different versions of Projects into what's called a Product bundle. You can then integrate this into any CI or CD tool out there or start manually if you haven't configured CICD yet.

Other than that, yes - I highly recommend helm and kubernetes - this is what we use on newer projects. (And I can also add ArgoCD and Spinnaker to the existing tooling). But it is not enough to track permutations of different versions of microservices and establishing which configurations are good and which are not between different environments.

user_29488910
Related