Why deployment is the most important part of your project
Published on 2026-09-12 by frfrand
El código que no está en producción no existe. Por qué un despliegue difícil deforma todo lo demás, qué significa que sea aburrido y cómo se llega ahí.
There is an uncomfortable and quite true phrase: code that is not in production does not exist. It doesn't matter how well written it is, it doesn't matter that it passes all the tests. Until someone uses it, it is an intention.
That is why the mechanism that takes your code from your machine to the user deserves more attention than it usually receives.
The vicious circle
The interesting thing about a difficult deployment is that it doesn't just make you lose time: it deforms how the team works.
If publishing is costly, it is published less frequently. If it is published less frequently, each delivery accumulates more changes. If each delivery has twenty changes and something breaks, finding which one it was takes much longer. And since the last delivery was traumatic, the next one is postponed.
It is a circle that feeds back on itself, and it is almost always misdiagnosed: blame is placed on the code, the lack of tests, or the team, when the problem was in the friction of publishing.
The corollary is counterintuitive: publishing more frequently is usually safer, not less. A deployment of three changes is easy to revert and quick to diagnose.
What it means to be boring
A good deployment has four properties, and none of them have to do with speed:
Automatic. No one executes steps manually. Manual steps are forgotten, especially on Friday at seven.
Repeatable. The same commit produces the same result. If the deployment depends on what was installed on the server that day, it is not repeatable.
Observable. When it fails, the log says at which step. A deployment that fails silently is worse than one that doesn't exist.
Reversible. You must be able to roll back to the previous version in minutes, without thinking. And that should be tested before you need it.
The three steps that are always there
Underneath any tool, a web deployment does the same thing:
- Bring the new code to the server.
- Build: install dependencies, compile, apply migrations.
- Restart the service so it picks up the new version.
When something fails, it fails in one of these three steps. Knowing this shortens diagnosis significantly. And almost always it's the third step, the restart: the service didn't start, or started with the old configuration.
The restart gap
Between when the old process shuts down and the new one responds, there are a few seconds where no one is attending. The user sees a 502 error.
The way to avoid this is to invert the order: start the new version, wait for it to respond, route traffic to it, and only then shut down the old one. For this, you need a health endpoint that says "I'm truly ready," not just "the process exists."
The hardest part isn't the code
Rolling back in code is easy: revert the commit and redeploy.
The database is another matter. A migration that dropped a column cannot be undone with a redeploy.
That's why the order makes sense: first add the new stuff, then let the code use it, and delete the old stuff only several days later, when you're sure. That way there's always a previous version of the code that still works against the current database.
Where to get to
The goal isn't to have the fastest deployment. It's that no one hesitates before publishing.
When publishing is boring, the team delivers in small chunks, errors find themselves, and time goes into the product instead of the ceremony.
At ArduMaker that path is configured once from the panel: repository, branch, build commands, and domain. Each push runs the three steps and leaves its log, so when something breaks you see exactly where.