Deployment Maintenance Windows and Notifications Some changes — particularly large infrastructure or database work — are best done during a planned maintenance window when any brief disruption causes the least impact. Clear notific...

Infrastructure as Code in Practice Infrastructure as Code, or IaC, means defining your servers, networks and other infrastructure in text files rather than setting them up by hand through a control panel. This turns infrastructure ...

Rollforward vs Rollback Strategies When a release causes a problem, there are two ways to respond: roll back to the previous version, or roll forward by quickly releasing a fix. Both are valid, and the right choice depends on the situatio...

Build Caching to Speed Up Pipelines Caching stores the results of work that has already been done so it does not need repeating. In a build pipeline, caching unchanged parts can turn a slow build into a fast one. Faster pipelines m...

Post-Mortems Without Blame A post-mortem is the structured review we hold after a significant incident to understand what happened and how to prevent a repeat. Crucially, ours are blameless. The aim is to improve the system, not to...

Disaster Recovery Drills A disaster recovery plan describes how we would restore your service after a serious failure, such as the loss of a data centre. A drill is a rehearsal of that plan to prove it actually works. An untested r...

Service Level Objectives (SLOs) and Error Budgets A Service Level Objective, or SLO, is a clear, measurable target for how reliable a service should be — for example, that it is available 99.9% of the time. An error budget is the small am...

Configuration Management Explained Configuration is all the settings that control how your software behaves — which database to use, which features are on, how to connect to other services. Managing it well keeps systems predictable and s...

Alert Fatigue and Tuning Your Alerts Alerts notify the team when something needs attention. But too many alerts — especially noisy or false ones — lead to alert fatigue, where genuine problems get lost in the noise. Tuning alerts w...

Automated Testing in the Pipeline Automated tests are small programs that check your software still behaves correctly after every change. Run inside the pipeline, they form your safety net against bugs sneaking into production. Bec...

Deploying Static Sites and JAMstack A static site is one where the pages are pre-built into plain files and served directly, rather than being assembled by a server on each visit. JAMstack is a modern approach built around this idea. ...

Incident Response and On-Call Basics An incident is any unplanned event that disrupts your service, from a slow page to a full outage. Incident response is the organised way we detect, communicate about and resolve these events. Ha...

Monitoring Releases After They Go Live Deploying a change is not the end of the job. The minutes and hours after a release are when we watch closely to confirm everything is behaving as expected under real-world load. Active monito...

What DevOps Means and Why It Speeds Up Delivery DevOps is a way of working that brings the people who write software and the people who run it into one joined-up team with shared goals. Instead of developers “throwing code over the wall” ...

Rolling Back a Bad Release Quickly Even with strong testing, occasionally a release behaves badly once it meets real-world traffic. A rollback is the ability to return to the previous known-good version quickly and calmly. Knowing ...

Environment Parity: Dev, Staging and Production Software passes through several environments before it reaches your customers. Keeping those environments as similar as possible — known as environment parity — prevents the classic “it work...

Why We Use Git Branches and Pull Requests Git is the system we use to track every change to your code. Branches and pull requests are how we keep work organised, reviewed and safe before it joins the main codebase. Think of a branc...

Feature Flags for Safer Releases A feature flag is a switch in the software that lets us turn a feature on or off without deploying new code. It separates the act of releasing code from the act of launching a feature. This gives yo...

Cost of Downtime and Why We Invest in Reliability Downtime — when your product is unavailable — carries real costs that go well beyond the lost minutes. Understanding those costs is what justifies investing in reliability up front. ...

What a Build Pipeline Does Step by Step A build pipeline is the automated assembly line that takes raw code and turns it into a tested, packaged product ready to deploy. Every change you fund passes through it. Understanding the st...

Code Review: Catching Issues Before Release Code review is the step where one developer's work is read and checked by another before it is accepted. It is one of the most effective and inexpensive ways to improve software quality. ...

Secrets and Credentials in Pipelines Your software needs sensitive information to run — database passwords, API keys, encryption keys. These secrets must be available to the pipeline without ever being exposed or stored in plain sight in ...

Artifact Registries and Versioned Builds An artifact is the packaged, ready-to-run output of a build — the exact thing that gets deployed. An artifact registry is the secure, organised store where every version of that package is kept....

Database Migrations During Deployment When a new feature needs the database structure to change — a new column, a new table — those changes are applied through controlled scripts called migrations. Handling them carefully during de...

Logs, Metrics and Traces: The Three Pillars To understand how a live system is behaving, we rely on three kinds of data: logs, metrics and traces. Together they are known as the three pillars of observability. Each answers a differ...

Deployment Approvals and Sign-Off For some releases, particularly significant ones, an explicit approval step ensures the right person has reviewed and agreed to the change before it goes live. This adds a layer of governance and a...

Tagging and Releasing Software Versions Every release of your software is given a version number and a tag — a permanent marker in the code's history. This lets everyone refer to a precise, known state of the product. Clear version...

How We Keep Your Release Schedule Predictable A predictable release schedule means you know roughly when improvements will land, so you can plan marketing, training and communications around them with confidence. Predictability com...

Observability vs Monitoring Monitoring and observability are related but different. Monitoring tells you whether known things are working; observability lets you understand and investigate problems you did not anticipate. As system...

Self-Healing Infrastructure Self-healing infrastructure automatically detects and recovers from certain failures without anyone having to step in. If a server crashes, the system notices and replaces it on its own. This keeps your ...

Pipeline Security and Supply-Chain Risk Your build pipeline is a powerful piece of machinery: it has access to your code, your secrets and your live systems. That makes it an attractive target, so securing it is essential. Supply-c...

Why We Automate Everything We Can A guiding principle of our delivery approach is to automate any task that is repetitive, error-prone or done often. Machines are far better than people at doing the same steps the same way every time....

Blue-Green and Canary Releases Blue-green and canary releases are two proven techniques for deploying changes safely. Both let us test a new version against real conditions while limiting the blast radius if something is wrong. Cho...

Automating Dependency Updates Your software relies on many external libraries, and those libraries are updated regularly to add features and, importantly, to fix security flaws. Keeping them current is a constant, ongoing task. Aut...

Continuous Delivery vs Continuous Deployment These two terms sound almost identical and are often confused, but the difference matters because it decides who presses the final “go live” button. Both build on Continuous Integration;...

Containerising an Application for Deployment A container packages your application together with everything it needs to run — libraries, settings and dependencies — into a single, portable unit. The most common tool for this is Docker....

Smoke Tests After Every Deploy A smoke test is a quick, shallow check run immediately after a deployment to confirm the most important things still work. The name comes from switching a device on and checking it does not start smoking....

Capacity Planning for Traffic Spikes Capacity planning is making sure your system has enough resources to handle the load placed on it — including the busy peaks, not just an average day. Good planning keeps your product fast and a...

Zero-Downtime Deployments A zero-downtime deployment releases new software without your site or app ever going offline for visitors. People keep using the product while the update happens quietly behind the scenes. For any business...

Continuous Integration (CI) Explained Continuous Integration, or CI, is the practice of merging every developer's work into a shared codebase frequently — often several times a day — and automatically checking it each time. The goa...