Overview of Gitlab CI/CD process for multi-project SOA application. Releasing and Versioning
Managing versions of different services can be tricky. For now I've never found a good HOW TO out there. Like most things you do what suit you the best. Here is a couple of suggestion you could use:

-> Tag docker image with their commit sha:
Pretty easy to do when you are using gitlab this is an already set environment variable that you can uses when building you image in the CI/CD pipeline. It's easy to track what code this container. Also when rolling back one of your service you can see directly the merge request you are rolling back on.

-> Continuous deploy on your staging environment: 
When one is merging a new feature on the master of one of your services deploy it as soon as possible so you can test the impact on all other services. 

-> When staging looks good trigger a release job: 
That job release shall be present on all your services. The purpose of this job is to:


Check if the service current version (commit sha) match the currently deployed in production. 
If not trigger the deploy job to production for this commit sha pipeline.
If the deploy to production job work then we shall store the current sha deployed in a new folder somewhere in a K/V store that way we keep a single source of truth of what's is being deployed and when


More on that K/V store and release job:

This shall be trigger form a different pipeline on a project you use only to remotely trigger the updated versions on your whole SOA-application.
That way we have a repo that contain a script that will trigger the job release of all the services. 
It will create a new folder on your K/V store and all the triggered release job of your application will write their current version in it (updated or not)
Once finished only service that had change will be deployed but you will have a major version for your wall application like this on the K/V store:

release_0.1.5:
 - user_service = COMMIT_SHA
 - payment_service = COMMIT_SHA 
 - organisation_service = COMMIT_SHA
 - ect..


When this job is replay it will detect that the folder already exist and so will trigger the deploy of all the version present in it so you can rollback your App to an older state.

Deploy to production job on each of your service can be protected to only be triggered from the main release project. But for quick fix reason you could also let it open just make sure it update the current K/V folder.