Git release bot - PART 1
Releasing software to the final users is challenging regardless of the programming language of choice. For web apps it requires a web server, for compiled apps it requires a way for distribute the binary and for each one extra steps are needed, in the end the release is just the final step of a long process.
In the old days, applications where deployed via SFTP and required to move file by file in the server, later on git, was used to make the changes a bit easier, without the need to upload file by file then the devops and continuous integration/delivery came to support the agile practices.
Gitbot comes to continue the continuous integration/deploy in the development
process based on conventional commits and semantic version. Gitbot is an attempt
to make the boring task to change files (
for each relased an automated process.
Table of contents
The problem with releases
To release a version of a software, usually there is a boring task of updating
specific files with the version to be released. For example, a team may want to update
package.json file (version property) with the release they are tagging,
for documentation purpose. Then, before a release the developer in charge of the
release must remember to follow the rules of updating the file, and after that
generate a git tag.
In the scenario described the major issue is to relay on the developer to always remember to update the file, which is fine, but what if the release requires to update two, or even three files? There is the human aspect of it as well, we are humans and we are error prone, which we can sometimes, forget to do things. In this case, the developer can also forget to update the files before the release, and then if it happens, the developer should follow a specific flow to change the file (or files) and release again.
The gitbot project is based in two major conventions:
In practice gitbot integrates with a git repository and watches through webhook for pushes into a specific branch (or branches) which can be configured through the web interface. Once a push is made gitbot receives the commit (or commits) content, and then analyze the commit title for one specific match:
chore: tagged version x.x.x
As a first approach the version pattern is constrained to use numeric versions, only, (this is a limitation added just for speed up the prof of concept), for example, the following version is valid:
chore: tagged version 10.2.0
Therefore, the following version is not:
chore: tagged version 10.2.0-rc
Once Gitbot detects the match, it will automatically push the changes to the files with the specific version. The following flow chart describes the flow that is executed starting from the git repository (Gitlab).
Currently Gitbot implementation  supports Gitlab only, but it’s core was designed to support other git providers, such as github or bitbucket.
- C. commits, “Conventional Commits - A specification for adding human and machine readable meaning to commit messages,” 2020 [Online]. Available at: https://www.conventionalcommits.org/en/v1.0.0. [Accessed: 17-Aug-2020]
- T. Preston-Werner, “Semantic Versioning 2.0.0,” 2020 [Online]. Available at: https://semver.org. [Accessed: 17-Aug-2020]
- M. Marabesi, “Git bot release,” 2020 [Online]. Available at: https://github.com/marabesi/git-bot-release. [Accessed: 17-Aug-2020]
This link provides a step-by-step guide to deploy gitbot release in AWS lambda.