Engineer App

Appearance

Ways of Working - Proposal ​

Goal ​

Make the develop branch always releasable

Requirements ​

  • Catch regressions before merge, not after
  • Shift quality ownership from one person to the whole team
  • Scale these practices to support multiple teams in the codebase
  • Enable incremental delivery behind feature flags once coverage is mature

Problems ​

  • Develop is unstable due to uncomplete and untested work hitting it
  • Regressions are caught too late — no e2e tests run before merge and e2e tests are reactive instead of proactive
  • One person bottleneck — Dave (and Joel when he has time) writes and maintains all e2e tests, which doesn't scale
  • Not enough CI capacity — infrastructure can't support running e2e tests on every PR
  • Devs lack e2e skills and ownership — no training or expectation to write or fix e2e tests
  • Can't ship incrementally — without sufficient test coverage, partial features on develop risk breaking the release

Stage 1 — Dev training + Increasing threads ​

Addresses: CI capacity, dev skills, foundation for protecting develop

  • Provision enough e2e test threads to run e2e tests on every PR
  • Train all devs in e2e testing so they can run tests locally
  • Set up infrastructure to run e2e on PRs (even if just a dummy test to prove the pipeline works)
  • Lay the groundwork for protecting develop in later stages (returning to qa testing on pull requests before merge)

By the end of this stage: the team has the skills and the e2e test thread infrastructure is finalised — the next stages put them to use.

Move to Stage 2 when: devs are trained, e2e test threads are provisioned, and e2e pipeline is running on PRs.

Stage 2 — Feature branches + Devs fixing their own tests ​

Addresses: develop stability, catching regressions before merge, bottleneck, dev ownership

  • No partial features allowed on develop — reduces complexity so we don't have to worry about feature flags while the foundations are being built
  • Relevant e2e tests run on every PR targeting develop (manually identified at first)
  • Broken tests block merge — devs fix the tests they break
  • Nightlies expand to run on all feature branches, not just develop

By the end of this stage: develop is protected against half-finished work, devs are fixing tests they broke, nightly tests are running on more branches

Move to Stage 3 when: feature branch workflow is established, devs are fixing broken tests on their PRs, and relevant test selection is working (even if manual).

Stage 3 — E2E tests become a part of definition of done + Ability to scale to multiple teams ​

Addresses: e2e qa bottleneck, regressions fully automated, scaling to multiple teams

  • Relevant test selection is fully automated — no manual labelling, CI selects tests based on changed paths
  • Devs write e2e tests for their features, not just fix broken ones
  • Dave shifts to test strategy and policy — still writes tests and supports, but is no longer the sole author
  • The process and coverage are mature enough to support multiple teams in the codebase

By the end of this stage: the team owns quality end-to-end, and the foundations are in place to support multiple teams and incremental delivery.

Move to Stage 4 when: relevant test selection is fully automated, devs are writing e2e tests as standard practice, and coverage is sufficient to catch regressions.

Stage 4 — Allow partial features in develop with internal feature flags ​

Addresses: incremental delivery

  • Relax the "no partial features on develop" rule — partial work can land behind internal feature flags
  • Test coverage and automation are mature enough to catch regressions even with incomplete features on develop
  • Feature flags were deliberately deferred until the foundations were solid
  • Process for handling e2e tests around incomplete features and internal feature flags to be defined

By the end of this stage: the team ships incrementally with confidence, without compromising develop stability.

Note: This stage is a placeholder for discussion. The process for e2e testing incomplete features and managing internal feature flags needs to be defined.