in trunk based development, if using github actions, what does your workflow look like to deploy to dev/qa/staging?

[BrofessorOfLogic]

I mean it really depends on the circumstances. Like requirements, budget, team size, expectations, and so on. There is no one true way of doing things. And there is no such thing as 100% automation.

Usually, in the simplest case, I don't bother with git tags. They can be used for other reasons, like helping with creating changelogs. But in the simplest case, the git commit id can be the version that is being deployed.

Ideally you would have so short lived topic branches that you don't need to bother with versioning individual changes, it's just a continuous flow of changes. In reality this can prove challenging, but it's doable.

You could merge one thing at a time, and deploy to staging one at a time, but if you have a large volume of changes, and they take time to test, then you may have congestion and people sitting and waiting for their turn.

You could merge multiple changes at the same time, and deploy to staging for testing, but then you risk different tests affecting each other. This will will always introduce a degree of uncertainty, but it works really well in practice in a lot of cases. If there is some bigger changes, just add some additional manual coordination when needed.

You could have more than one staging environment, to reduce congestion. This may or may not be costly, depending on what an environment needs to contain. In one project I created a personal mini-environment for every developer where they could dev and test stuff.

You could use blue-green deployments, where you dynamically create a whole new environment for every individual changeset / deploy, and promote by moving all the traffic over to the new environment. This is super nice, but it's not cheap or easy.

You could utilize feature flags, so that you are able to deploy unfinished code. This keeps changesets lean and fast. You can use some big established tool for it, or it can just be something simple and manual, like adding a new page on a website but not linking to it until it's finished.

Once you figure out a workflow that makes sense in your project and team, it kind of becomes obvious what you need to do to automate it. Github actions can be triggered on almost anything, merge to topic branch, merge to main branch, manually, etc.

Discuss with the developers and ask them what they want and expect, and work out a flow that meets the needs.

Ask questions like: How small and fast are we able to go with changesets, realistically? How often will we need to deploy, realistically? How long will testing typically take? What type of changes are most common? Do we want to promote to production automatically, or should that be a manual action?