Releases without surprises: automated checks before every deployment

In many teams the path from a finished change to the running system still depends on people who remember the steps. Code is formatted differently in every file, reviews turn into arguments about style, and a build works on one machine and not on another.

The cost shows up later. Customers find the bugs instead of the tests. Dependencies fall years behind because updating them feels risky. Documentation no longer matches the code, and new people need weeks to learn the unwritten rules. Releases become rare and tense, and each one carries risk.

DORA research describes measures of how well a team delivers software. The classic four are how often it releases, how long a change takes to reach production, what share of releases cause a problem, and how quickly service recovers after a failed release. The model later added a fifth: how often unplanned releases are needed to fix a problem in production.

Together the measures describe both speed and stability. They help management because they turn "the team is slow" into specific questions about where time is lost and where errors come from.

Style first. Automatic formatting, for example with Prettier, and linters that check rules and common mistakes, for example ESLint, run on every change. PHP has equivalents of both. Reviews stay about logic, and changes are easier to read.

Static analysis early in the process. It finds wrong types, unreachable code and bad calls while they are still cheap to fix. It runs before or in parallel with the fast tests, so it does not lengthen the wait.

Tests at several levels. Most are fast unit tests of individual parts, then integration tests of how they connect, and fewest are end-to-end tests of the key flows: sign-in, payment, the main order or request flow. End-to-end tests run in a real browser, for example with Playwright. Because they are slower, the full set often runs before a merge or before a release.

One standard for the API. Interfaces are described with the OpenAPI standard, the documentation is generated automatically, and the process checks that the description matches how the API actually behaves. Every system that uses the API then works from the same contract.

Dependencies as a routine. Lock files pin the exact versions of dependencies, automated update requests arrive in small batches, and a check for known vulnerabilities is part of the process.

One build from test to production. The built image, for example a Docker image, is tested once and exactly that image is released, instead of being rebuilt for each environment. A multi-stage build helps keep the image smaller and free of development tools. Configuration and secrets stay separate for each environment.

Automated checks reduce errors but do not remove them. Every version therefore goes first through a test environment kept as close to production as possible. After a release, a short automated smoke test and error monitoring show problems before customers report them.

Rolling back to the previous version is planned in advance. Database changes are made in steps (expand and contract), so the old and the new version can work with the same data. Where possible, new functionality is switched on gradually or behind feature flags, and can be turned off without a new release.

Rolling back is not always the right move. If irreversible operations have already happened, such as payments or messages sent, or data now exists in a new format, a quick fix may be safer. When to roll back and when to fix forward is decided in advance, not in the middle of an incident.

The main branch of the repository is configured to accept changes only after the checks pass and a review is done.

Secrets such as keys and passwords are not kept in the code. For a smaller project, the protected settings of the environment and the CI system are enough. As the project grows, it is better to keep them in a secrets manager, for example HashiCorp Vault or the cloud provider's own service. It shows who uses each secret, and secrets can be rotated automatically. Where possible, the process uses short-lived access (for example through OIDC) instead of permanent keys. An automated check makes sure no secrets end up in the code, and any leaked secret is replaced immediately.

Each step is added once the team has accepted the previous one. What removes friction, such as automatic formatting, comes first, and what adds rules comes later. A process that blocks every change from day one starts being worked around.

People are an important part. Developers and QA specialists learn to write and maintain the automated tests, so checking the key flows stops depending on one person. Those flows are then checked automatically on every merge or release.

With a well-tuned process, reviews get shorter and more useful, because style and simple mistakes are already handled by the automated checks.

Releases can become more frequent and smaller, which reduces the risk of each one. The result depends on the quality of the tests. Flaky tests or a slow process hold the team back, so the process itself is maintained and improved too.