'branching strategy for migrating microservices to Spring BOOT
We have following core services, all services are basically Rest end points providing business logic each service has its own repo and database.
- ServiceA
- ServiceB
- ServiceC
Now we have below common services which are services that are compile dependencies for above core services,
- service1-common
- service2-common
- service3-common etc.
Environments:
- Dev,
- QA,
- Release as environments for developers, testers, releasing respectively.
Now we are planning to migrate the services to Spring Boot from existing Spring application. Core services migration depends on the common service migration as it is compile time dependency.
Problem here is that when common service is migrated to Spring boot we cannot release all the core services that are dependent on the common service unless all core services are also migrated to Spring Boot. This is a huge effort.
So we have created two branches for each environment for common services one with old spring application features and another for spring boot migration. Whenever we push a new changes in common we push to 2 branches and release two versions of common ,one for spring boot and other for old spring. So core dependencies can choose which version of common dependency they want based on whether core is boot or non boot.
Is it right approach? , Can we do anything better? Is it good branch strategy? Is there any better way to handle compile time dependencies in microservices besides versioning?
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|
