In past projects my release note strategy has been a combination of custom scripts (to pull the changesets between releases) and good old fashioned elbow grease to manually create the notes. I was curious to know ways about the ways to achieve the same in git and learning about the techniques used in popular open source projects.
In order to automatically generate a changelog the repository requires consistent commits - and I found that there are three steps that can be done to achieve this:
Enforcing commit message rules.
Install and setup tools that help generate commit messages that are compliant.
Generate the changelog for the project based on the commits.
Node.js - instructions on installing node can be found here.
A package.json file for your project. One can be generated by navigating to the root folder of the project, run the npm init command and follow the instructions
Enforcing Commit Message Rules
The enforcing of the rules are done using husky and validate-commit-msg packages. Husky makes it very easy to tap into the commit event and execute custom validation scripts and uses git hooks to do this. validate-commit-msg implements the validation scheme - conventional commits - that we would be used when the commit occurs.
Now that we have commitizen and its adapter installed, now its time to do some commits. The following command now replaces the usual git commit command:
It would guide you interactively to create the best commit message based on the conventional-changelog adapter. Find a recap of the message format here.
Now to generate the changelog. In my non-node.js based projects, I usually rely on the build process to bump the version number of the release, but node.js projects and tools appear to like the explicit versioning in the package.json file and the same checked into source control. I can work with that.
Confirm that the changelog has been updated with the new significant features.
Commit the changes back into git.
These same steps can be applied to almost any project type including .NET. So I am pretty excited to test this out in the Dynamics CRM/365 projects. I also found out that visual studio 2017 plays nice with git hooks.
It is important to remember that Git Hooks are client site and that it can be overridden:
... Client side hooks can often be bypassed, either by using low-level “plumbing” commands instead of the high-level “porcelain” commands, and often by passing the –no-verify option to the command. For example, git commit –no-verify will not run the pre-commit hook. ...
On an open-source project, maybe the maintainer could possibly eye-ball the pull request and ensure that it is valid or squash and provide a different message?
Since the package.json would be driving the version number, in my .NET/Dynamics CRM projects, I can possibly implement a PowerShell script that would bumps the version of the CRM solution based on the package.json instead of the build.