CODEWITHSUNDEEP
architecturemicroservices
Petter Nordlander
Petter Nordlander

Reputation: 22279

Versioning microservices in trunk based development

Given a system built using microservices (somewhat diverified tech stack - parts in ASP.NET Core, Node.js, React, python - the right tool for the job etc etc). The whole system is to be released to end users in fixed increments (let's say each sprint), in a "trunk based development approach". That is, the system is devloped using feature teams able to work on all components. How would you version each microservice? The system as a whole is what the end user faces and what can be tested using integration tests etc.

I can find two alternatives.

  1. Build every service at release (or simply use last successful build from master). The version of a service is merly the "build number" or "build time".
  2. Version each service using semantic versioning and track each service for each release.

I'm leaning at #1. Seems like the easy way out. What is the best practice? Monolith/single framework is not an option.

Upvotes: -1

Views: 840

Answers (1)

Iswariya Manivannan
Iswariya Manivannan

Reputation: 724

My experience with trunk based development has led me to use semantic release or its python variant python-semantic-release. These are pretty standard tools which are able to parse your angular style commit message based on commits in the trunk and accordingly bump the version, push git tags and even release packages to artifactory. However, in the case of micro-services it would suffice to bump the version and push the git tags, which can then be used as a version for the docker images (assuming that you have micro-services which run inside pods based on the docker images).

Upvotes: 1

Related Questions