auto-version-release

Proof of concept to test the ability to automate deployments to multiple environments with automated versioning based semantic versioning controlled via conventional commits, when using trunk-based-development.

Tools used:

  • GitVersion - configured to autogenerate the semver based on the conventional commits
  • GitHub Actions - 3 different workflows were created to support this scenario
    • prepare-release - invokes GitVersion to generate the version, creates a Git tag and a GitHub release with that version, our deployable artifact would be created on this workflow as well and saved as part of the GitHub release
    • continuous-deploy - simulates the deployment of the artifact in 3 different environments, showcasing dependency between environments
    • manual-deploy - simulated the deployment of the artifact to a specific environment selected when triggering the workflow

Handling of exceptional urgent hotfixes

This PoC is also prepared to handle with urgent hotfixes that can't follow the normal flow. Considering that this should be very exceptional, the approach for this scenario, is not fully adherent to semantic versioning and trunk-based-development.

The version generated will always be the version containing the bug, suffixed by -hotfix.<number_of_hotfixes>

The flow would be the following:

  1. Somone with high privilleges would create a branch called hotfix/<something> based on the latest tag that is deployed to production. (identification of the tag that is in production can be done via the Deployments view of GitHub)
  2. Developer would create a working branch out of the hotfix/<something>, implement the fix and create a PR targetting hotfix/<something>
  3. PR is reviewed and merged. This will trigger prepare-release which will generate an hotfix release and tag
  4. manual-deploy workflow is triggered manually to deploy the tag generated by the prepare-release

Notes

  • continuous-deploy does not run any job for the hotfix scenario
  • prepare-release ensures that for the hotfix scenario, GitVersion ignores the commit messages and does not bump the version (so that it just sufixes the version with -hotfix)
  • prepare-release creates a PR from the hotfix branch to main, to ensure that there's no regression. We know that this PR might not be needed (e.g: bug doesn't happen in main) or can't be merged, in those cases, it should simply be closed, the hotfix branch can be deleted, and any other appropriate actions should be taken.

Test hotfix