How do you folks handle deployments to multiple en...
# general
m
How do you folks handle deployments to multiple environments using Github actions? We currently do as follows (with some missing pieces) and I am sure there are better approaches 1. PR -> main -> Action: deployed to development (GH environment) 2. Manually create a tag and release 3. Action: deploy release to production (GH environment)
d
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
I also include a
manual_dispatch
in the action to allow manually redeploying incase there's a problem
m
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”.
d
Haha, yeah. It used to be much worse. I had a pre-processor at one point before composite actions became a thing
What walls are you running up against? Wouldn't mind running through a GHAction experiment. Been a while 🤣
m
Hah, yeah. GHA are just awesome for simple stuff, but yeaj.
I mean, I think we solved it, I am just curious what “everyone” is doing, because Google gave me nothing useful and I would not trust my worst enemy with advices from chatgpt.
d
The most interesting examples are always part of closed repos
m
indeed
l
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
m
I see, useful.