This message was deleted.

It depends on how they want infrastructure deployed. Tags are a good way of reliably deploying snapshots that can be checked later for debugging, or rolled back in most situations. To allow a little more control, we used branches to represent each environment, which we fast-forwarded against the main dev branch to update while still allowing hotfixes without overhead. I've also worked in teams with no tags and a single branch, where pushing to main would deploy all environments with a "manual input" step to gate production environments

We just added a dispatch with input actually, where you can specify which release tag you want for production. I just wish github actions gave us more freedom so we could do more of “what we want” instead of “what github thinks we want”.

Haha, yeah. It used to be much worse. I had a pre-processor at one point before composite actions became a thing

Hah, yeah. GHA are just awesome for simple stuff, but yeaj.

The most interesting examples are always part of closed repos

indeed

Here's our approach, deploying to 4 Azure environments via GH action workflows: 1. Development: pushes to main (typically PRs) kick off action that builds and deploys 2. Test: triggered by creating and publishing a GH "release". A couple of things: a) we do this from a release branch, e.g. release/1.2; b) we store the results of the build as a tar.gz file in Azure blob storage so that we know for sure what we deploy to UAT and Production is the identical build. 3. UAT: a "workflow_dispatch" GH action - pick the tag and release branch; the action pulls down the build from blob storage and deploys to the Azure UAT environment 4. Production: same as UAT, but to the Production environment

I see, useful.