Deploying on a Friday, without the stress

If nobody dares to deploy on a Friday afternoon, Friday is not the problem. The problem is that releases are still risky: manual steps, surprises in production and no easy way back. Here is how to change that.

2 min read

Diagram: the pipeline from commit to build and tests, staging, approval and production, with one-click rollback.

One pipeline for every change

Every change, however small, takes the same route: build, automated tests, deployment to staging, approval, deployment to production. No copying files by hand, no quick fixes straight on the server. If the route is always the same, it is always tested.

Azure DevOps and GitHub Actions both do this very well. The tool matters less than the rule: nothing reaches production any other way.

Tests on what matters

Your tests do not need to cover everything to be useful. Start with whatever would hurt most if it broke: signing in, payments, the main user journeys and the deployment itself.

A failing test stops the pipeline, and that is the whole point. A problem caught in the pipeline costs a few minutes. The same problem found by a customer costs a great deal more.

Staging that mirrors production

Staging is only useful if it behaves like production: same configuration, same infrastructure, same deployment process. When both environments are defined as code, with Terraform or Bicep, they stay in step instead of slowly drifting apart.

That way, surprises turn up in staging, in front of the team, rather than in production, in front of your users.

An approval that actually means something

Before anything goes to production, someone checks that staging looks right and signs it off. It takes a minute in the pipeline, and it leaves a record of who released what, and when.

Alerts before your users notice

After a release, you want to know straight away if something is wrong: error rates, response times, failed requests. Azure Monitor and Application Insights can send an alert as soon as a threshold is crossed, before users start to complain.

One-click rollback

The best safety net is being able to go back. Keep the previous version ready to redeploy, or use deployment slots to switch back in seconds. Database changes need more care: they have to work with both the old and the new version of the application.

When rolling back takes one click, a bad release is a minor incident rather than a crisis meeting.

Where to start

You do not have to do everything at once. Automate the deployment first, then add tests on the critical paths, then rollback. Each step makes the next release a little calmer.

That is exactly what our DevOps services are about.

DevOps & automationReproducible pipelines, infrastructure described as code and end-to-end observability.

All articles

A project, an overloaded team, an audit? Let's talk.

Reply within two business days, in English, French or Dutch. NDA on request.

[email protected] Send an email