Skip to content

Tenets

  • All releases have canaries with auto-rollback on alarms.
  • All significant new features are deployed incrementally behind feature flags.
  • Feature flag changes have canaries with auto-rollback on alarms. Flags are removed after release.
  • Changes are fully testable by CI on PRs without manual deployments (e.g. to staging).
  • Releases need only run the subset of end-to-end tests that are relevant to the changes.

Continuous Integration (CI)

Each PR triggers GitHub Actions workflows that run the following steps:

  • Linting, formatting, type checking, etc.
  • Unit tests
  • Component-level integration tests
  • Deployment of a fresh test environment
  • End-to-end tests against the test environment

Continuous Deployment (CD)

Upon merging to main, the following steps are taken:

  • Create new release
  • Deploy to staging
  • Run end-to-end tests against staging
  • Deploy to preprod
  • Run smoke tests against preprod
  • Deploy to prod
  • Run smoke tests against prod

Smoke tests are similar to end-to-end tests but are faster and more focused on the most critical paths. They are mainly intended to catch issues arising from differences between environments rather than logical errors in the code itself. See EDR-26 Testing Approaches for more details.

Deployment Configuration

Deployments are orchestrated by GitHub Actions workflows. Each target AWS environment has a corresponding GitHub environment with environment-specific variables, secrets, and protection rules. In particular, the prod environment requires a manual approval step before deployment.

Rollbacks

If a deployment needs to be rolled back, the previous release is re-deployed to the target environment. Run the Deploy action targeting the prod environment, and enter the last release's tag in the ref input (instead of main).

If the rollback is not urgent, you can also run the full Deploy Pipeline action with the previous release tag as the ref input.