Development Lifecycle

Where QA happens

We QA at three points, each answering a different question:

Stage	When	What we're checking
dev / dev2	Before merging to main	Story-level QA against the acceptance criteria — does the feature do what the ticket said?
stag	After merge, before deploying to production	Does everything queued for release still work together, including migrations?
prod	Immediately after deployment	Did the release land cleanly? Design quality and polish rather than acceptance criteria.

Story code should only be merged to main once it has passed QA on dev, so main stays deployable at all times.

Development workflow

1. Create a feature branch from main, using a descriptive name in line with our git conventions.

2. Develop the feature and deploy to dev or dev2 manually, either via the CLI tool or via the "Deploy to DEV" GitHub Action from your draft branch. Because dev environments are shared, please coordinate with other engineers to avoid overlapping deployments — this is why dev environments are managed manually rather than auto-deployed. Database migrations to dev and dev2 must also be run manually, which can be done via the corresponding GitHub Action.

3. QA on dev against the story's acceptance criteria, before opening the branch for review. This can be done by you or by another engineer — see How we work for when to ask someone else.

4. Open a pull request, or mark your existing draft branch as ready for review. Branches should only be marked ready for review when they are genuinely complete and have passed story QA. Provide a clear summary of the changes; AI can be used to help fill in the following:

   • Summary
     • What changed and why. Link to ticket: GFENG-123.
   • Changes
     • [Bullet list of user-visible or system-visible changes]
   • How to test
     • [Steps a reviewer or QA can follow to verify the change — where to click, what to expect, any test data or SQL snippet needed to re-run your own verification]

5. Request a review by posting the PR in the #eng-prs Slack channel. Follow up as needed to ensure timely review. Reviewers can use deployment previews for gf-app if they wish to see the feature in action.

6. Merge to main. This automatically deploys to the stag environment, including any RDS migrations, where release QA is performed across everything queued to go out.

7. Promote to production once all features on stag have passed QA. Open a PR from main to prod with a clear summary (AI may again be used to assist). Merging this PR will automatically deploy to the prod environment, including RDS migrations.

8. Verify on prod. A further round of product QA confirms the release landed cleanly, focused less on acceptance criteria and more on overall design quality and polish.

Feature flags

Early and frequent deployment to prod is strongly encouraged. For new features, the preferred approach is to gate the work behind a feature flag, enabling the code to be deployed and tested in production prior to general release. This approach affords significantly stronger testing assurances, as it allows validation against real production data and live client accounts, which is often unachievable in lower environments.

For modifications to existing functionality that cannot reasonably be placed behind a feature flag, a more cautious approach is naturally required.