I have been using Maven for almost a year and have recently started using GitLab CICD. I am trying to develop CIs for the build and deployment of microservices. Each microservice is packed in a docker container and stored in Nexus. We will be using Kubernetes to manage the distribution of the services to test and production environments.

We are a small team of 3 developers and we currently have around 10 services. Both of these numbers will increase so it is important that we find a way to describe the workflow and to automate it as much as possible.

Reading around the subject, some have suggested that each build should be seen as a potential release. I understand this to mean that there should only be one build and this build gets retagged as it is promoted towards a release.

My difficulty here is regarding the use of SNAPSHOT and version numbers in the project POMs.

My current plan:

  • use feature-branches while implementing new features
  • when complete, features will be merged with the development branch which causes a full build and test.
  • the resulting docker image will be stored in Nexus as x.y.z-${COMMIT_ID}
  • a release-candidate will be merged to releases/x.y.z triggering a retag of the docker image in Nexus to x.y.z-rc
  • a release will be merged from releases/x.y.z to the master branch triggering a retag of the docker image in Nexus to x.y.z

(Deployment to actual servers will be handled by Kubernetes)

Do I need to use SNAPSHOT at all with this kind of workflow? The microservice projects don't have build-dependencies on each other so I can't immediately see the point of adding SNAPSHOT to the POM version numbers.

Can any one comment on this? Are there any well-documented workflows for this type of project?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.