I go into microservices architecture based on docker and I have 3 microservices, which together create one product for example "CRM system".
Now I want my client to be able to upgrade his product, whenever he wants to. I have 3 different versions of my microservices, which one should client see? I guess product version should be independent of microservices, because copying one of the microservices version would make me go into more trouble than having no version at all.
So is there any pattern, idea to handle such situation?
The only thing that comes to my mind is to have another repository which will be versioned whenever one of the microservices will produce production ready package. However, I now have a version, which none of my Product Owners (PO) would ever know about.
First of all ensure Semantic Versioning (SemVer) is strictly followed by the micro services. Not doing this will sooner or later lead to incompatibility problems.
Capture only API changes in that version, don't mix it up with micro service internal versioning (e.g. DB schema versioning for a service that has a DB).
Introduce a version for the product as you already suggested. Following SemVer makes sense here, too, but may need to be loosened to meet marketing needs (e.g. allow to make a major version increment even though SemVer would require only a minor version increment). In extreme cases, use dedicated "technical versions" and "marketing versions". This is however more complicated for the customers, too.
Also note that you will need to define what the SemVer version means in terms of your application, since the application as a whole has no "API".
Now a specific product version is a list of micro services of specific versions. Note that this is essentially dependency management in the same sense as apt, npm, bower, etc implement. How sophisticated your solution needs to be is difficult to say, but I recommend to at least support the notion of "minimum required versions". If docker has a built-in mechanism, try to use that one (I don't know docker very well, so I can't tell).
With this, you are e.g. able to specify that your product at version 4.8.12 requires service A at version 1.12.0 and service B at 3.0.4.
The update mechanism should then follow a strategy that adheres to SemVer. This means that installing a specific product version automatically installs the newest services with the same major version. In the example above, this could e.g. install 1.12.2 of service A and 3.3.0 of service B. Providing a mechanism to keep already installed services that meet the dependency requirement may be a good idea, so that users don't get annoyed by the update mechanism.