Skip to main content

Development Lifecycle

How to develop a feature​

  1. Create a new branch off main. Call it something sensible. See git conventions.
  2. Develop your lovely feature. Deploy to dev manually (via the CLI tool or via the "Deploy to DEV" GitHub action from your draft branch). Note: We will need to collaborate slightly to make sure we don't deploy over each other. This is why dev is manually managed rather than auto deploy. You will also need to run migrations manually to dev, you can do this with the GH action.
  3. Once the feature is ready open a PR or mark your existing draft branch as ready for review (no branch should be ready for review unless its ready for review). Write a sensible summary of the PR, or use GitHub copilot to do it for you.
  4. Plop the PR in #eng-prs channel and pester people until you get a review. Reviewers can use deployment previews for gf-app-tng if they need to see the feature working.
  5. Once its good to merge, merge into main, and it will automatically get deployed to staging environment env (including RDS migrations). Here QA can be performed.
  6. Once all features in QA are QAed we can prepare a full production deployment by opening a PR from main to prod. Write a summary or use GitHub copilot. Merging this PR will automatically deploy to the prod env (including RDS migrations). Often we will perform more 'product QA' here which is less about seeing if the feature matches the acceptance criteria, more about 'is it good enough from the design'.

Possible avenues for optimisations and TBDs:

  1. It would be ideal if per feature QA could be carried out before merge. There is nothing stopping us QAing from dev other than the chance of things being deployed over if we leave them in QA a long time. This would mean that main is always deployable. TBD.

Feature flags​

Note that we encourage early and often deployment to prod. For new features we would prefer to use a flag to be able to deploy the feature and perform some testing in production... the reason for this is that we get much better testing ability using 'real' data and 'real' client accounts often.

Obviously for changes to existing features that cant be feature flagged we need to be more cautious.