Release Process

Continuous Delivery

We practice continuous delivery: once a merge request is approved and merged into main, it is automatically built and deployed to production. There are no deployment windows, no manual gates, and no release trains. We deploy multiple times per day.

How It Works

1. Create a branch from main
2. Open a merge request — CI runs tests and builds a review app
3. Get it reviewed and approved
4. Merge — CI automatically deploys to production

That’s it.

API Contracts

Because every project deploys independently, breaking changes between services must be managed through API contracts. When changing an API:

1. Add the new version of the API alongside the old one
2. Migrate consumers to the new version
3. Remove the old version once no consumers remain

Never deploy a breaking API change in a single step.

Merge Request Guidelines

See the dedicated Merge Requests page for the full process on creating, reviewing, and merging MRs. All CI checks must pass before merging.

Rollback

Rollbacks are only permitted on projects that do not use database migrations. Reverting a project that has run migrations leaves the database in a dirty state, and some applications (e.g. Connect) will refuse to start entirely.

For projects without DB migrations, revert the merge commit and let CI redeploy:

git revert <merge-commit-sha> -m 1

For projects with DB migrations, always fix forward instead.

Hotfixes

Hotfixes follow the same process — branch, MR, merge, deploy. The difference is priority: hotfix MRs are reviewed immediately and validated by the CTO before merging.