(Code that uses maven as build tool)
This pipeline is abstraction over gitflow-workflow. Basically gitflow is git branching and release management workflow that helps developers keep track of features, hotfixes and releases in software projects.
This blog answers everything! *I like the title of the blog a lot 'why-arent-you-using-git-flow'.
This pipeline is backed by with maven plugin jgit-flow which is basically java implementation of gitflow-workflow by atlassian. This plugin abstract out major complexity of gitflow implementation and you can do semantic versioning by few commands of this plugin e.g. if your current maven code version is 1.0.0-SNAPSHOT (offcourse that means you are in development). Following command will create a release branch that is generally release branch is used for testing and bug fixing purposes and once the code is released, it will also increment the version of the codebase in development. So generally by semantic version once you release the code (taking above development version), your release version would be 1.0.0 or 1.0.0-RC and develop version would be 1.1.0 or 1.0.1 unless.
mvn jgitflow:release-start -DallowSnapshots -DpushReleases=true -DreleaseVersion=${nextReleaseVersion} -DdevelopmentVersion=${nextDevelopmentVersion}"
Similarly there are other goals in jgit-flow that helps in implementing complete gitflow-workflow via maven plugin. See this for more details on other goals.
Imagine a scenario where you have microservices architecture and to maintain your code base you have different git repositories for your different microservices. Now as per basic microservices principle each microservice can have its independent release cycle that essentially means every microservice can have its own code version. Now releasing and maintaining that code version manually via release plugin or even with jgit plugin via command line could be very tedious specially if you have many microservices in your system.
In this scenario this pipeline becomes a handy and fast solution. It will help you to release your code base for testing i.e. in gitflow workflow terms start-release and in another click once testing and bug fixing and done this pipeline will help you to merge the code in master and create a tag in gitflow terms it means end-release
And the best part is single click would orchestate this for all the microservices (git repositories). We just have to be follow some conventions and be disciplined in how we commit code and bring it to dev. Rest everything will be taken care by this pipeline.
At the time of this pipeline release 1.0-m5.1 version of jgitflow-maven-plugin was latest.
<build>
<plugins>
<plugin>
<groupId>external.atlassian.jgitflow</groupId>
<artifactId>jgitflow-maven-plugin</artifactId>
<version>1.0-m5.1</version>
<configuration>
<noDeploy>true</noDeploy>
<squash>false</squash>
<allowSnapshots>true</allowSnapshots>
<autoVersionSubmodules>true</autoVersionSubmodules>
<flowInitContext>
<masterBranchName>master</masterBranchName>
<developBranchName>dev</developBranchName>
<releaseBranchPrefix>release-</releaseBranchPrefix>
<versionTagPrefix>dt-hgw-</versionTagPrefix>
</flowInitContext>
</configuration>
</plugin>
...
</plugins>
This file will derive the logic of calculating next development version and release version of the codebase when release-start command is executed.
- Pipeline takes input all the code repositions links.
- This pipeline offers two modes right now -
- start-release
- end-release
- Start-Release will execute following steps for all the code repositories
- If will compare the code of configured 'dev' and 'master' branch and smartly figure out if there code changes to release or not
- If there are code changes, pipeline with execute jgitflow:release-start command to create the release branch from develop branch with proper code versioning of dev and release.
- If no code changes are found then nothing happens for that repository.
- End-Release will execute following steps for all the code repositories
- If will figure out for what all repositories release branch exists by the configured release branch pattern.
- If release branch is found then end release command is triggered to finish the release branch and merge the code in master and create tag for the same.
- If no release branch is found then that repository will be skipped.
- Update-Release will execute following steps for all the code repositories
- It will figure out for what all repositories release branch exists by the configured release branch pattern.
- If will compare the code of configured 'dev' and 'release' branch and smartly figure out if there code changes to release or not
- If there are code changes, pipeline will create a copy of dev branch 'dev_branch' and version it according to the release branch
- It will then merge this copy into release branch and eradicate the copy of dev branch to create a release branch with proper versioning
- If no code changes are found then nothing happens for that repository.
Follow the steps on this wiki page to configure the pipeline https://github.com/techpleiad/jgit-jenkins-pipeline/wiki/Configuring-pipeline