Releases That Only Happen After Office Hours

Some teams have no problem with their software. The problem appears at seven in the evening, when most people have gone home and one person is still waiting for a copy-and-paste job to finish.

At that point a release stops being ordinary work. It becomes an event scheduled well in advance and carried out at the quietest possible hour, so that if something breaks, fewer people are watching. The consequences are quiet but expensive: small requests pile up waiting for one release window, and every window carries more risk than the one before it.

The cause is almost always the same single thing: there is no way back that anyone can run calmly. Installing the new version is doable. Returning to yesterday’s version means finding the backup folder and hoping its contents still line up.

A boring release is a release that has been fixed

The work we do here is rarely about sophisticated tooling. It usually starts with making every release take the same path (build, test, deploy), run with the same commands rather than one person’s memory.

Once that path exists, two other things become practical: rolling back to the previous version in one step that has actually been tried before, and knowing whether the system is alive without waiting for a client to call.

Signs we usually find together:

• Releases are scheduled at odd hours: nights, weekends, or just before a long holiday.
• Only one person dares to run the deployment.
• Backups live as folders and have never been tested as restores.
• The first news of an outage comes from a client, not from monitoring.

The improvement here usually shows in people’s behaviour before it shows in the tooling. When a release can go out in the afternoon without special preparation, requests stop waiting two weeks, and the team stops looking for a safe hour to do work that is actually routine.

If the release calendar at your company is still treated as a special occasion, tidying the release path and adding monitoring is the sensible place to start. That is the work we do as part of our cloud and DevOps service.