Joined a new company and I’m having fits with their github actions release flow into production.
Here it is:
TaskBranch
----> code review
-------> DevBranch → github action to QA Env
Manuel:
-------> DevBranch → github action to Prod Env
As you see. The problem here is Dev is the source of truth but at any given time it can have a multitude of projects/bug fixes etc that haven’t been validated by QA.
So, when releasing into Prod, you have to pick a Dev PR that was approved by QA… but then that build still could have items unapproved in it.
It’s a mess.
It was setup before I came. So whatever the reason, it’s lost in time.
Because of costs, I think setting up another environment is not possible.
What is your process using github action?
What solution do we have here?
Feature branches. They are deployed in their own instances and don’t get merged until completed. Which means QA’d and validated by the product owner and the various module owners.
That way the main branch is always clean and deployable and when you branch out to start working on something you know you’re not pulling half-finished crap.
When we’re happy with the feature set in main we create a release and it deploys.
@Rory
So, those instances are like how Vercel does it? Problem, I see, those instances most likely have odd domain structures which muck with cookies and auth etc… not in your case?
Rylan said: @Rory
So, those instances are like how Vercel does it? Problem, I see, those instances most likely have odd domain structures which muck with cookies and auth etc… not in your case?
Never used Vercel.
Every instance uses a different subdomain, [random].dev.domain.com. Our app is entirely configurable via env vars which are passed to the docker instances.
Each instance is a full stack, including Auth, Db, message queue, workers, etc… I think 6 or 7 containers. So no, no issues with auth and cookies as each instance is a complete and independent deployment.
Rylan said: @Rory
Hmm. That sounds amazing. Any manual process in there at all?
You might be interested in spawning ephemeral environments for your PRs, so that QA can review them before merging. Since you are using GitHub, you can do that with a GitHub Action such as https://github.com/pullpreview/action (I’m the maintainer).
@Sterling
So. When Dev is promoted to QA, what happens for bug fixes that are associated with that particular promotion, they go directly to QA? If so, do you backmerge to Dev at any point?
@Rylan
First few days after DEV is promoted to QA is dedicated to bug fixing, bugs are fixed on DEV and then cherry-picked into QA (so 2 PRs for 1 bug, but only the initial PR is properly peer reviewed).
QA goes into code freeze 2 days before release/demoing and only hotfixes can go into QA. If hotfixes happen, then QA is merged into DEV after release, so all changes are saved.
We have bad tests and bad coding standards that’s why the 2nd week is mostly bug fixing, sadly lmao.
Pull request creates an ephemeral environment for development, functional and non-functional changes. Merging deploys that to a reference/integration environment.
Creating a release/tag triggers a deployment to the staging environment and starts a production deployment which pauses at an approval gate. Change management and sign-off etc happens and the production deployment gate is approved.
But, how would you promote to staging? Once you merge the PR, you are pushing into QA constantly… how do you promote to staging? By ticket or by time frame?
Once your ticket/PR is in dev… now you’re dealing with full builds…so, now how do you circumvent my original issue?
Also, what branch are you cutting your tickets/features from?
Based on your flow, you must do release dates with code freezes, no?
