Overview of Gitlab CI/CD process for multi-project SOA application. Releasing and Versioning

Question

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 1.2.3, while 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.

Answer 1

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.