CI/CD and Safe Deployment: Why Nobody Releases on Friday Afternoon

In many companies, deploying a new version of software is an event. A date is scheduled, a list of steps is written, somebody connects in the evening, runs it, and then watches for an hour to see whether anything fell over. If it does, improvisation begins, because the way back was never prepared.

Continuous integration and continuous delivery (CI/CD) don't change this by making deployment faster. They change it by turning deployment into an ordinary, boring operation that happens several times a day and that nobody notices. The difference isn't in the technology but in how much of the team's fear is attached to a single button.

The two terms travel together but solve different problems.

Continuous integration (CI) is an automatic check on every code change. When a developer submits a change, the system builds it, runs the tests, checks types and code style, and says whether the change is sound. The goal is to catch a problem while the author still has it in their head — not two weeks later at deployment time.

Continuous delivery (CD) is the automated delivery of a verified change into an environment. Deployment stops being a manual sequence of commands and becomes a repeatable process that runs the same way every time. Repeatability is the point — a manual procedure is slightly different every time, and the difference shows up on the least convenient evening.

Most projects get by with three environments, each with a different job.

Staging is the most misunderstood of the three. Its value isn't that it exists, but how closely it resembles production. An environment with a different database version, a different configuration and ten test records instead of a realistic data volume can't reveal the very problems it was created for. False confidence is worse than no staging at all, because it leads to deploying with the feeling that "it was tested, after all".

Part of this consideration is what data staging works with. A copy of the production database gives realistic behaviour, but it means customers' personal data suddenly sits in an environment with looser access — something to resolve deliberately through anonymisation, not to overlook.

Automated tests are the precondition without which CI/CD is just a faster way to deploy a bug. There don't have to be many of them, though — which ones matters more.

The minimum that makes sense in almost any project:

1. Build and type checking. Catches the cheapest category of errors immediately.
2. Tests for critical flows. Login, order, payment, saving the main record — the things that must never stop working.
3. Tests for things that have already broken once. Every bug fix should arrive with a test, so the same bug can't come back.

Trying to cover everything with tests is the classic way to postpone the topic indefinitely. It's more practical to start with critical flows and add more based on what actually breaks. We cover the topic more broadly in our article on the QA process before launch.

The most underestimated part of deployment isn't the way forward but the way back. A team that can restore the previous version in two minutes deploys calmly. A team that can't deploys cautiously, rarely and in large batches — which paradoxically raises the risk, because when something goes wrong it's harder to tell which of thirty changes caused it.

For a rollback to be dependable, three things have to hold:

• The previous version is still available and can be started without rebuilding it.
• Database changes are backward compatible. This is the part that most often makes rollback impossible — code can be reverted, a dropped column can't. That's why structural changes are deployed in steps: add first, switch over, and only remove the old thing in a later release.
• You know a problem has occurred. Without monitoring, the company hears about the bug from a customer, and by then a fast rollback doesn't save the reputation.

The rule "we don't deploy on Friday afternoon" looks like superstition, but it's a rational response to a specific state of affairs: the team doesn't believe it can fix a problem quickly. If rollback took two minutes and monitoring raised the alarm within one, Friday would be no different from Tuesday.

So it's a useful indicator. If the rule holds at a company, the question isn't "how do we persuade the team to deploy on Friday" but "what's missing for that to be safe". The answer is always one of three things: missing tests, an unreliable rollback, or no monitoring.

A related topic is the state of the code itself — a project carrying a lot of technical debt is hard to deploy no matter how good the pipeline is. We cover how to recognise and pay down that debt in a separate article.

CI/CD isn't about how often you deploy but about whether deployment is an ordinary operation or an event. Automatic checks on every change, a staging environment that genuinely resembles production, tests for critical flows and — above all — a dependable rollback: those are the four things that decide.

The scope of the setup varies between projects depending on where the application runs, what the database looks like and what the availability requirements are. If you're working out how to set up deployment or why the current one hurts, we'll go through it in a no-obligation consultation — or take a look at how we approach custom development.