Thanks for sharing! We are a small company and right now we release (from our monorepo) on every PR merge to main. As the engineering team continues growing, we anticipate this approach will become unsustainable soon, and are looking for alternatives.
I wonder if the tag based release is a widespread industry pattern (especially for growing monorepos)? Would be curious to learn more about it
I was honestly shocked that I couldn't find many blog posts or articles about managing this process. The tag based mechanism was one I came up with on my own because we needed something. We're also a small team of 5 engineers, with many small microservices that each have their own pipelines. The problem with main being the release tracker is that it doesn't work if you have multiple environment stages. Stage specific branches work, but then you don't get history.
I'm on a team that implemented a hybrid tag-based release system on a monorepo and it is working well.
External releases are built on release branches off of main with their own git tag rules, but I want to touch on internal releases off of main.
Between feature branches and main we have GitHub status checks that gate bad PRs from getting in. Once the PRs are in main, we build a nightly full suite of components and put them through various levels of interop testing. Once our system receives the signal that all builds and interop testing had passed, it applies a Last Known Good (LKG) tag to the git commit the components were built from.
After that, various systems including artifact links for QA and auto-merge jobs from main, are set to use the LKG tag to ensure they are getting good builds and code.
I wonder if the tag based release is a widespread industry pattern (especially for growing monorepos)? Would be curious to learn more about it