Time and time again, the dreaded question marches your way — what is actually going out in the next release? There are multiple ways you can handle that, below are some of my favourites:
- Grep git differences — most people ask me why would I ever need it if half of the version control system is spitting out the differences on merge requests. Not sure where besides the following — when we were working with GitLab (or another tool) which doesn't have proper integration with your ticketing system. This little script allowed us to move tickets from:
to-do → in progress
review → test
test → done / deployed
2. Automatic changelog — more useful for packages, binaries, and libraries in my opinion. Again, requires using a version of conventional commits, but is highly configurable. In short, what you do is follow the principles described in https://www.conventionalcommits.org/en/v1.0.0/ and then output it with.
it will output a nice document for you, along the lines of:
It can be easily incorporated in your toolchain — either with husky or git-commit hooks (well, you can write them yourself if you wish as well) or into your CI processes. This way, you can easily enforce the formatting, making sure everyone on the team complies with the required structure.
Some good resources to use when working conventional commits / semantic changelog:
Happy to hear about other tools you use to automate some boring & repetitive aspects of what we do!