Here I'm trying to come up with a best practice solution for Maven-based applications CI/CD pipeline automation. As the number of your microservices increases, the challenge of deployments for versus versions of apps increases.
Note: Gitflow is a well-known git process but is not suitable when you have multiple versions in production at the same time. (custom versions depending on your VIP clients profile)
GitFlow is one way of overcoming this issue. You can have multiple development processes and at the same time, you can have release or deployment in parallel.
Basically in GitLab, your pipeline is inside the GitLab runner depending on your setup and licenses.
Right off the bat, you need to create your “develop” branch of the “master”.
Setting up Maven Repository
You can check my other post related to how to have your own private Maven Repository in AWS-S3 (almost free). I already have a separate article for the setup:
Make AWS-S3 as Maven Repository
With the help of this maven-plugin, you can create your own private Maven Repository with the essential features. There…
Develop and Feature Branches
You should never have any development process directly In the develop branch. Instead, you should have created a “feature” branch that started with “feature/”.
let's say you are working on a Jira ticket ABC0001, first thing you need to do is to create a feature branch as followed by the ticket number, like:
git checkout -b feature/abc0001
Feature Branch Pipeline
Usually, we can some basic code Quality check with code format check(not the test cases and code coverage)
Maven - Code Quality Management
Some existing Maven plugins use code analysis technologies (like [Checkstyle][Checkstyle], [PMD][PMD]…
A set of plugins that can be applied to any Java project to provide a consistent "Spring" style. The set currently…
Having these processes on the feature branch pipeline, helps us to have fewer issues when we do code review or PR.
Once the ABC0001(your Jira ticket) development is done, we are merging that branch into the “develop” by raising the Pull Request (PR or Merge Request)
Usually, this process happens by a different person(s) in the feature branch to approve the PR.
At this point, the “develop pipeline” should have already started running.
Deploy to QA Environment
Before start, the release process into the QA environment let's looks at the pre-requirements we need in our project.
Setting up Maven Release Plugin in POM.XML
Maven Release plugin - Introduction
This plugin is used to release a project with Maven, saving a lot of repetitive, manual work. Releasing a project is…
you should add the following tag to your project pom.xml
and in profiles > profile > build > plugins
The main lifecycle of this plugin is in the following order:
1- mvn release:clean
- delete the release descriptor (release.properties)
- delete any backup POM files
2- mvn release:prepare
- perform some checks — there should be no uncommitted changes and the project should depend on no SNAPSHOT dependencies
- change the version of the project in the pom file to a full release number (remove SNAPSHOT suffix) in our example 0.0.1
- run the project test cases
- commit and push the changes
- create the tag out of this non-SNAPSHOT versioned code
- increase the version of the project in the pom in our example 0.0.2-SNAPSHOT
- commit and push the changes
3- mvn release:perform
- checkout release tag from SCM
- build and deploy released code
Right after the maven plugin has done all the manual works for you, now is the time to create a release branch. Ex: release/0.0.1 which is your projects pom version
What to do when QA finds bugs in the release branch?
You may ask, create a bugfix branch or merge back into “develop” and create a feature branch from it?
The current release branch “release/0.0.1” is created from the “tag” so any new changes on this branch will not be compatible with the “tag” we created through the Maven Release Plugin.
Just to remember that at this point your “develop” branch pom version is “0.0.2-SNAPSHOT” and it may have already some extra features from other PRs which you most probably don’t want on this release.
One Way of fixing this issue, is to create a “bugfix” branch from the “release” branch (release/0.0.1 — > bugfix/0.0.1) and developer(s) start to work on the bug and once it fixed, we should merge it back to both “release/0.0.1” and “develop” (So the bug doesn’t show up again) branches.
Note: keep in mind that at this point your current tag “0.0.1” no longer valid and also your project’s “develop” pom version is “0.0.2-SNAPSHOT”