I have a SOA-application. Each service is a separate project in Gitlab with its own Dockerfile. So, in terms of structure it looks as follows
\UserService Dockerfile \src \OrderService Dockerfile \src
There is one developer (or group of developers) responsible for just one Gitlab project (or service as I call it). So, in fact each group technically can tag its project with its own version, so that
UserService can have version
OrderService can have version
5.7.8. It does not look good, because both services are part of one SOA-application.
So, in terms of DevOps I need know what is the best practice for versioning SOA-application containing physically separate services with their own code base?
My another question is about Docker. We are using docker for packing services. I know, that we can tag Docker images also with version number. In terms of best practices should this image version have something to do with versions of the source code of each single service?
Besides, I do not know what should we treat as a release and its version. I guess there will be a build pipeline in Gitlab, which will build multiple Docker images and tag each one with a version. Should we treat the collection of these images as a release or should there be some kind of a bundle, physical release with again its own version.
I know there may exist different practices, I want to know some real world approaches.