What We Check After Every Release

It is surprisingly easy to deploy software that does not work. The files copy successfully, the pipeline turns green and the website shows an error page to every visitor. Something small went wrong: a cached setting that still points at an old value, a background worker running yesterday's code, a migration that needed a step it did not get.

That is why our releases do not end when the code arrives on the server. They end when a set of checks confirms the application is healthy. Here is what those checks cover and why each one exists.

1. The exact version is built and recorded

Every release starts from a specific commit in our source repository. The pipeline builds that version, installs the dependencies it declares and compiles the front-end assets. When the release finishes, it records which version is live along with checksums of key files. If anyone later wonders "what is running right now," the answer is precise.

This sounds basic, but it underpins everything else. You cannot reason about a problem if you are not sure which code is producing it.

2. Migrations run in order

Database migrations run as part of every release, so the database always matches the code that expects it. If a migration fails, the release fails, rather than leaving new code running against an old database. Data and content changes that ship as migrations, such as a set of new pages, are covered by the same rule. Our article on one-time seeders that respect later edits explains how we keep those safe.

3. Caches are cleared and rebuilt

Modern applications cache configuration, routes and views for speed. After a release, those caches may describe the old version. We clear them and rebuild them as part of every release, so nothing stale survives. We also reset the server's compiled-code cache so the language runtime loads the new files instead of serving old ones from memory.

4. Background workers restart on the new code

Queue workers are long-running processes. A worker that started before the release keeps running the old code until it is restarted, which can cause strange bugs where the website behaves one way and background jobs another. Restarting workers is part of every release, and we confirm there is exactly one supervisor running them, not a duplicate left behind by an earlier release.

Our realtime service, which pushes live updates to open pages, is checked and restarted after releases too, and administrators are alerted if it stays down.

5. Health and smoke checks answer real requests

A health check asks the application a simple question and expects a simple answer: can you reach your database, your cache and your queue? A smoke check goes one step further and loads real pages, the way a visitor would, expecting a successful response.

If either fails, the release is marked as failed. We would much rather learn about a broken release from our own checks than from a customer.

6. Logs are reviewed for new errors

Some problems do not stop pages from loading but show up as errors in the logs: a deprecated call, a missing translation, a job that cannot find a class. The release process looks at recent logs for new errors so they are noticed while the change is fresh in everyone's mind.

7. Feature-specific checks follow

The automated gates prove the platform as a whole is healthy. They do not prove that the specific feature in this release works as intended. For that, the person who made the change follows up with targeted checks: visiting the changed page, testing the changed workflow with a dedicated quality-assurance account and capturing screenshots at desktop and phone sizes. We record those results separately from the pipeline, because "the release is healthy" and "the feature is accepted" are different statements.

Why all of this is automatic

Every step above could be done by hand. The problem is that people forget steps, especially when they are in a hurry. By putting the checks into the pipeline, every release gets the same treatment, whether it is a one-word copy fix or a large new module. That consistency is why we insist on one pipeline for every change.

Frequently asked questions

What is a smoke test?

A smoke test is a quick check that the most important parts of an application respond after a release, such as loading key pages successfully. It catches obvious breakage before customers do.

Why restart queue workers after a deploy?

Workers are long-running processes that keep the code they started with. Restarting them makes background jobs use the same new code as the website.

Does a green pipeline mean a feature works?

It means the platform built, migrated and passed its health checks. Whether a specific feature works for real users is confirmed with separate, targeted checks after release.