General Git Journey By GitLab and Maven

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.

Here I’m using GitLab as my code-repo and CI/CD pipeline, we can use the free version in this demo.

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”.

GitFlow Diagram:

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

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

mvn pmd:check

spring-io/spring-javaformat

mvn spring-javaformat:apply

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)

Code Review

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

you should add the following tag to your project pom.xml

<scm>  <developerConnection>scm:git:ssh://git@gitlab.com:/projectname.git</developerConnection>
    <tag>HEAD</tag>
</scm>

and in profiles > profile > build > plugins

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.5.3</version>
    <configuration>
        <tagNameFormat>@{project.version}</tagNameFormat>
        <autoVersionSubmodules>true</autoVersionSubmodules>
        <releaseProfiles>releases</releaseProfiles>
    </configuration>
</plugin>

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”

Staging Environment

progressing..

Production Environment

progressing..