Overview

Within the IndeVets/core repository, Git is leveraged as the source-of-truth and driver for three layers of our development and deployment process:

1. Development: The develop serves as our trunk for trunk-based development. Developers branch off from here to begin all work and then merge it back into here.

2. Continuous Integration: Every time new content is pushed to the trunk develop branch, GitHub automations “render” all releasable products to stage a potential release:

   • The Laravel site gets rendered to releases/laravel-site with frontend builds and Composer dependencies integrated
   • The complete declared state for the Kubernetes cluster is rendered to releases/k8s-manifests
   • The docs site is rendered directly to gh-pages

   Note

   Every push to develop triggers a re-rendering of every releasable product, but the automations skip making a new commit to the target release branch when the hash of the new tree matches the hash of the previous tree. In this way, looking at a visual git graph of the trunk and release branches provides a clear illustration of when changes to the trunk change various release products. This also provides a sort of “noise suppression” where automations hooked up to the release branches only run following trunk pushes that actually change the segment of the code base that they care about.

3. Release and Deployment: For products subject to human moderation of the release flow, the gap between the releases/* and deploys/* represents the accrued changes that have yet to be deployed and a pull request is automatically opened between the two when new changes are first available

   • releases/laravel-site→deploys/laravel-site pull requests mediate the designation of CATS application semantic version numbers and deploy new versioned container images to the GitHub container registry. Git tags (or really GitHub releases) get created on the releases/laravel-site branch when these pull requests get merged and are named by the version number indicated in the title of the PR. This version number gets automatically generated by the GitHub Actions automation that opens the PR by incrementing the previous patch number, but may be edited manually before merging to increase the minor or major version number instead or to designate a prerelease version.
   • releases/k8s-manifests→deploys/k8s-manifests pull requests mediate the application of declared/desired state changes to the Kubernetes cluster and are versioned continuously with a content hash rather than a human-moderated semantic version number
   • gh-pages goes through no mediation process so changes to docs/ content is immediately published to the GitHub Pages website for the repository

Git Graph

An actual git graph, as visualized by Visual Studio Code’s excellent Git Graph extension by filtering the branch list down to only the trunk, releases, and deploys branches

Diagram

Editable source