Fast Runs and Full Runs: Choosing the Right Pipeline for a Change
When many people and assistants are improving a platform at the same time, the deployment pipeline becomes a shared road. If every small change waits for the longest possible test run, the road jams. If changes skip checks to go faster, the road becomes dangerous.
Our answer is a pipeline that lets each push choose its pace without ever removing the guardrails.
Two modes, one set of gates
Every push to our main branch can run in one of two modes.
Fast mode runs the build, the database migrations, the cache refresh, the health checks, the smoke checks and the release record. It skips the long automated test suite. This is the mode for small, low-risk changes such as copy fixes, styling adjustments or documentation.
Full mode runs everything in fast mode plus the complete validation and test jobs. This is the mode for larger changes, risky changes and final runs at the end of a piece of work.
The person pushing chooses the mode for that push and states which one they chose. Merge requests always run the full checks no matter what.
What never gets skipped
The important design decision is what both modes share. The steps that protect production stay in every run:
- The application is built from the exact pushed version
- Migrations run in order so the database matches the code
- Caches are rebuilt so no stale configuration survives
- Health and smoke checks confirm the application responds
- Logs are checked and the release is recorded
A fast run is not a shortcut around safety. It is a shorter run of the parts that are optional for that specific change.
No permanent skip switches
It would be easy to add a project-wide setting that turns tests off for everyone. We deliberately do not. A permanent switch gets forgotten, and then the whole team is shipping without tests while believing otherwise. The choice is made per push, in the open, and recorded with the pipeline.
We also do not use special markers in commit messages to skip the pipeline entirely. Every change goes through some version of the checks.
How we decide which mode to use
A few questions guide the choice:
- Does the change touch money, permissions or customer data? Use full mode.
- Does it change shared services many modules depend on? Use full mode.
- Is it the final push of a larger piece of work? Use full mode.
- Is it a contained copy, style or documentation change? Fast mode is usually fine.
When in doubt, we choose full mode. A few extra minutes is a small price for confidence.
Separate evidence for separate questions
A green pipeline tells us the code built, migrated and passed the checks that ran. It does not tell us that a real customer can complete a task, that a payment provider accepted a charge or that a page looks right on a phone. We record those as separate kinds of evidence, which keeps everyone honest about what has actually been proven. Our post on why every change goes through one pipeline explains the foundation this builds on.
What a typical day looks like
On a busy day, several streams of work move at once: a styling pass on admin screens, a fix to an email template, a new report, a change to how images are processed. Most of those pushes are small and self-contained, so they go out in fast mode, one after another, each with its own build, migration and health check. The person working on the report finishes with a full run once the whole feature is in place. The person changing image processing uses a full run from the start, because many modules depend on it.
The result is a steady flow of small, recorded releases instead of a few giant ones. Small releases are easier to review, easier to verify and much easier to undo if something surprises us. That rhythm is also why we can afford to keep migrations running on every deploy without fear: each one arrives with a small, understandable change.
Who watches the results
One person on our team watches the pipeline results as they come in, so individual contributors do not need to keep refreshing a status page. If something fails, the failure is reported with the specific job and log, and the fix follows the same path as any other change.
Frequently asked questions
Is it safe to deploy without running the full test suite?
For small, contained changes it can be, as long as the build, migration, health and release checks still run. Changes to money, permissions, data or shared services should always get the full suite.
Why not run every test on every change?
Long test runs on every small change slow down the whole team and encourage people to batch risky changes together. Choosing per push keeps changes small and still tests the risky ones fully.
Can a merge request skip tests?
No. Merge requests always run the full set of checks, regardless of the mode chosen for individual pushes.
Related Posts
Why Every Change We Ship Goes Through One Pipeline
We never deploy by logging into a server and running commands. Every change travels through the same automated pipeline. Here is why that discipline matters.
Turning Fixed Bugs Into Regression Checks
The best time to stop a bug from coming back is right after you fix it. Here is how we turn fixes into checks and what we learn from each one.
Handoff Notes: How Work Survives a Change of Hands
Work is often continued by someone else: a teammate, a later session or an AI helper. Here is what our handoff notes contain so nothing important is lost between them.
Why Every Import Starts With an Automatic Backup
Imports change a lot of data at once, so we never start one without a verified recovery point. Here is how the automatic backup step works and why it is not optional.
Code That Works on the Marketing Site and Inside Customer Accounts
Some of our code runs on public pages with no customer account at all. Here is how we write shared code that works safely in both places without crashing or leaking.
Comments (0)
No comments yet. Be the first to share your thoughts!