Use the Commit Hash as the Version Number Hence, our version numbers will look like this: format: yyyyMMdd-HHmmss.abbreviatedCommitHash To increase the human-readability, we prefix the Git commit hash with the commit timestamp. Update 2019: I won’t recommend wrapping a fat jar into a Docker image anymore, because it’s a huge waste of storage, bandwidth and time. The complete sources can be found on Github. Additionally, we wrap the fat Jar in a Docker image and deploy the image instead of the Jar. The example build produces a simple Spring Boot service as a fat Jar. Let’s integrate the proposed version naming in a Maven build. Basically, a Git tag is not necessary anymore.Just check out the revision and build the artifact again (assuming no snapshot dependencies). It’s obvious, which commits are included. => The delivery pipeline is significantly simplified and automated.So there is no need for a dedicated release workflow anymore! Therefore, every artifact is potentially shippable.Every built artifact has a machine-assigned unique number.Using the Git commit hash as the version number. We use the Git commit hash as the version number for the built artifact. We have to clean up the created Git tag, Git revisions and fix the wrong version in the pom manually. during the artifact upload), we are facing an invalid state. If something went wrong in the last step (e.g. Not isolated. The plugin can easily get in a mess when someone else commits changes during the release build.The maven-release plugin runs 3 (!) full build and test cycles, manipulates the POM 2 times and creates 3 Git revisions. Building from the Git branch will override the develop snapshot.)įinally, the maven-release-plugin is also causing troubles: when creating a Git branch, but forgetting to change the version number in the pom. It’s easy to override a snapshot accidentally (e.g. The snapshot artifact can change from one second to another. We can’t say, which commits are included in the current snapshot artifact. Unclear and changing content of snapshot artifacts. We need a Git tag.Īdditionally, snapshots cause a lot of problems. Moreover, just by looking at the version number “8.2.0” it’s not clear, which commits are included in the artifact.The version number needs to be assigned manually by a human.We need to manually trigger a dedicated release workflow.Therefore, he assigns a version number (“8.2.0”) up front.Ī human has to assign a version number and trigger the release build. When the developer feels that the software has reached a stable state, he triggers a dedicated release build. Typically, a commit triggers a snapshot build, which produces a snapshot artifact (“8.1.2-SNAPSHOT”). But let’s take a look at some concrete problems with the typical Maven release workflow and classical version numbers. Let’s consider the principles of Continuous Delivery. We’ll implement this solution with Maven and Docker. At the end, every build will produce an artifact which is potentially shippable. This post shows how we can leverage the Git commit hash to get rid of manual workflows and automate the Continuous Delivery pipeline. The classical versioning approach (“8.2.0”) and release workflow is inappropriate, because it can’t be automated properly. Is Docker Necessary for this Versioning Approach?ĭealing with version numbers is an important challenge on the way to Continuous Delivery.Use Build Timestamp instead of Commit Hash.What happens to the JAR and its Version Number?.Create a Docker Image and Tag the Image with the Version Number.Use the Commit Hash as the Version Number.Solution: Leveraging the Git Commit Hash.Let’s start with a test that takes an array of ComparableVersion objects, clones the array, sorts it, and compares it back to the original list.Java Ecosystem, Kotlin, Engineering Management, Sociology of Software Development Version Numbers for Continuous Delivery with Maven and Docker The Maven distribution includes a class called ComparableVersion which is the source of truth when it comes to how different version strings compare to each other.īy writing some tests against this class, we can explore how Maven versions work. In this post, I take a look at how Maven version strings work. Version strings are usually easy to understand, but Maven has a number of rules and edge cases that are not immediately obvious.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |