Trunk-based dev and GitOps workflow

• Update CI/branches for trunk-based dev
• Review using gitlabs new gitlab-agent for the GitOps workflow.
  • We've already automated the install and created a separate project for it, but not a bad idea to review how they relate to the gitops flow
    • https://docs.gitlab.com/ee/user/clusters/agent/install/
  • https://docs.gitlab.com/ee/user/clusters/agent/gitops.html
• Reviewed the gitlab-agent GitOps workflow and will hold off, check out ArgoCD and see if that could possibly work
  • gitlab-agent seems to be in an infancy stage as only in 15.6 allows custom values to be set. As an example this project/chart will have the DB disabled by default (template/example project) but would like it to deploy/test with it enabled.
  • gitlab-agent requires the secrets to be encrypted in the repo using something akin to SealedSecrets, which is probably necessary in some fashion but would like to explore other alternatives before committing to SOPs/SealedSecrets just yet.

When conceiving of different development flows to use, the GitFlow is an obvious choice to start with. Many people use it, its a proven workflow that works, and gives room for some creativity while enforcing some good standards to prevent broken releases and deployments.

One of the reasons I had started using it and convinced it was necessary was the separation from Prod/Stage/Dev/Feature releases/environments.

• Prod release/promotion from main branch
• Staging/Beta release on initial merge to main
• Dev as an isolated/INTEGRABLE (this is important in a second) environment
• Feature for completely isolated environment

However, due to some shortsightedness I overestimated the need for the Dev branch/environment. Going with the idea of video game releases as an example, many people have heard of an Alpha and Beta version before the release

• Personal dev version (feature)
• Rapidly integrated version (dev or possibly alpha)
• More stable version getting closer to release (staging or beta)
• Fully released version (prod)

This workflow is probably still necessary for some types of projects, whether its heavily regulated, additions are massive in scope (game patches/expansions), massive teams, or any bugs/downtime caused being extremely costly. But after a silly eureka moment, I have found the dev branch/environment for my use cases, entirely redundant and unnecessary.

The 2 major reasons to switch to trunk-based and removing the dev step:

• It requires making sure to merge BACK changes from master back to dev asap, and after a "release" commit, can accidentally fall behind causing divergent branches if not paying attention.
  • Instead of developers branching of dev (potentially being a commit behind) they now branch directly off main and readily merge master changes in
• If the feature(s) are massive in scope and/or require integration from other branches, you can simply have the massive feature (epic some may call it) be the long-living (deleted on merge) branch that can stay up-to-date with main.
  • This removes the need for the dev branch entirely. Now if multiple developers are working on the Next Big Thing, they branch off of the Epic branch and merge their changes into this branch, which is acting as a pseudo dev branch.
  • The team working on this particular epic branch, can selectively merge in changes from other branches that they may need or depend on, without worrying about breaking the Dev environment as a whole.
  • If you need to have an environment that requires multiple Epics together before merging to main, now you can just make another umbrella/release branch and continuously merge changes to these Epic branches/environments, and be managed by an entirely different team if necessary.

Branching directly off the main branch makes it much easier to merge changes from main into your Epic/Feature branch keeping your branch up-to-date. Now you can quickly re-test changes from main making sure nothing from main would break your work or cause conflicts, increasing confidence and shipping it asap.

Each has their place, but for the above reasons, this and other projects will be trunk-based unless theres a very solid reason against it, or why switching is necessary.

---

With the switch to trunk-based dev, it feels appropriate to try and switch to a GitOps pull-based flow. How thats going to go, not entirely sure.

Its always felt appropriate to have some type of manual release to prod. But with the right workflow, long-term I think it forces more testing/safe guards before merging to main and forces a stricter but less error prone/automated flow from staging -> prod.

Manual action can be error prone and more time-consuming. Having the staging -> prod promotion semi-automated, deployment/release will be far more frequent and standard in the long run.

12/5/22 Update

• Probably hold off on this for now or explore ArgoCD over GitOps via gitlab-agent, see 3rd bullet at top.