Semver bump / Delivery / Deployment strategy

[TillaTheHun0]

So for automated semver bumping and release, I was thinking one of these flows. Both result in a publish off of a new git tag, but there is a difference in what event produces the new git tag. Would like some thoughts on what works best for our current team:

Some definitions, since we are talking about libraries:

• delivery: code being pushed to main
• deployment: code on main being published to a public registry, as new version

Option 1: Git tags driven off new pushes to main

• Any push to main ie. merge or push by maintainer (tip of main changes)
• CI kicks off and inspects commit messages
• semver bump egg.json based on commit messages
• append to changelog file
• tag
• push back to repo
• tag kicks off publish

pros:

• continuous delivery and deployment off of main. Every new tip of main is published
• no additional steps from owners/release managers. Continuous delivery gains us continuous deployment, through CI

cons:

• less control over when commits are released
  • the only way is not merging to master, which could lead to long lived feature branches.
    • The way to hedge against this is feature flagging
      Can't choose which semver bump to perform, since it's done by tooling
      Implies the use of some sort of commit message linter

Option 2: Git tags manually created by contributors

• contributor manually creates a git tag
• CI kicks off and bumps egg.json to match the new git tag
• append to changelog file
• push back to repo
• publish

pros:

• owners/release managers choose what sort of semver bump occurs
• owners/release managers choose when changes are deployed, by creating a tag

cons:

• continuous delivery, but not continuous deployment
• owners/release managers choose what sort of semver bump occurs (it could be incorrect and not reflect changes made in commits)
• owners/release managers must manually adhere to a git tag format (similar to what we are doing now)
• adds an extra, manual step, the creation of a git tag, that owners/release managers must perform, to deploy

edits:

• added definitions
• "contributors" -> "owners/release managers"

[twilson63]

Hey Tyler,

Thank you for breaking this down, in my study of continuous delivery the actual act of release should be separated from the act of deployment. Deployment should happen multiple times a day which means multiple times to the main branch. If you are branching from the main, you should pull and push often, this is where many teams just work off the main branch or do trunk-based development. While code is able to run in production but not yet validated, you leverage a feature flag, so that it can be validated. I realize the development flow with libraries are a little different, but I think releases should be separated from continuous deployment, in other words, we should be able to work off of the trunk branch or a staging branch, and everyone commit to that branch even when features are in flight, and a release is cut by generating a release event on github. There is a github action that can trigger via the release event. I would recommend that we consider that approach, and consider following continuous deployment practices instead of feature branch or git flow practices. Then trigger releases from the release tags. At least lets give it a shot. Outside contributors would still need to create pull requests and have code reviewed, but it would allow for a continuous flow, and encourage outside contributors to consistently pull upstream from main before submitting their contribution. And internal contributors would not have to worry about shipping breaking features and can commit to main multiple times a day.

[TillaTheHun0]

Thanks Tom. If i'm understanding your points, it sounds like you are advocating for Option 2.

[twilson63]

Yes, but I would say github releases created by project release managers, not contributors, if that makes sense

[tripott]

• release directly from the trunk to a promote a higher release cadence
• All developers in a team working on an application/service, clone and checkout from the trunk. They will update/pull/sync from that branch many times a day
• developers completing a piece of development work (changes to source code), that does not break the build, will commit it back to the trunk. That it does not break the build should be provable.

Question: How do code reviews occur? Short-lived feature branches before merge into the trunk?

https://trunkbaseddevelopment.com/5-min-overview/

[TillaTheHun0]

That it does not break the build should be provable

This is a concern I have with committing directly to trunk. By pushing directly to main, we bypass any sort of quality checks that could be enforced via CI.

How do code reviews occur

I figure if an owner wanted a code review, then they could open a PR and go through that process.

[TillaTheHun0]

owners are able to merge PRs without approval. This would allow owners to leverage quality checks on CI, but without forcing another developer into the process. With "Squash and merge" and "Rebase and merge", a merge commit is also avoided, making this process semantically the same as pushing directly to trunk, but with the added benefit of allowing CI to run quality checks.

[TillaTheHun0]

With trunk based development, Option 2 makes the most sense. This way owners can continuously push to trunk, and can separately cut a release at any time by creating a git tag ie. via a github release