I am starting to use Continuous Integration on my microservices solution, and I am referencing this post for versioning approach.
But, let’s say I make some change in one of the microservice and commit that change, but all the others are exactly the same. How the process would know that those microservices (docker images) weren’t changed so don’t need to increase the build number? I feel like I would end up with many docker images with different build numbers but same content.
Am I misunderstanding the concept? Sorry, this whole microservices and docker thing are pretty new to me.
TL;DR;
You are cutting releases, I would never use a build number to cut a release by itself (even though some people do), use name tagging instead (eg. latest, myapp-latest, myapp, etc).
My thoughts:
IMO I would not use build numbers for this. Build numbers are useful historical information, but should be used with tag and release names. I would use a tag such as latest, myapp-latest, or similar. Remember you can have as many tags aw you need.
A workflow for this using a build reporter (such as jenkins) would include a project that would run a docker-compose build (or multiple docker builds), and tag all of the images with the same tag. You COULD use build numbers in this example since they would all be based on the same project build number, but you don’t have to.
You could also do the build separately, just use tag names instead of build numbers. Things get slightly more complicated if you want versions of each release, but in that case tagging will still work you would just have to be smart with what you name them.