Cloud

DevOps & Deployment

Releases that are routine rather than events

How this is usually engaged

Typically four to eight weeks to build the pipeline alongside your team, deliberately with them rather than for them — a pipeline nobody in your organisation can modify is a dependency you did not ask for. Ongoing support is a separate agreement, with response commitments agreed per engagement and written into it.

Start a project brief

Practice: Cloud & Infrastructure
Sectors: 4 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

Build and deployment pipelines with automated checks, controlled database migrations and a rollback path, so shipping a change is a normal weekday activity.

01What this solves

The problem this addresses

When deploying is frightening, teams deploy less often, which makes each release larger, which makes it more frightening. The usual signs are a release checklist in a shared document, a person who is the only one who can run it, migrations applied by hand against production, and a rollback plan that consists of restoring last night's backup and losing a day of orders. The cost is not the deployment itself. It is the fixes that sit undelivered because nobody wants to open the door.

02Capabilities

What is included

Continuous integration

Tests, type checking, linting and dependency audit on every pull request, with the build kept fast enough that people wait for it rather than merging around it. A pipeline that takes forty minutes is a pipeline people learn to ignore.

Build once, promote the same artefact

One container image or bundle built from a reviewed commit and promoted unchanged through environments. Configuration differs between environments; the artefact does not, which removes an entire class of "it worked in staging" incident.

Blue/green and rolling deployments

Traffic moved gradually or switched between two live environments, with health checks gating each step and an automatic halt on failure. We choose the strategy against your database and session behaviour rather than by preference.

Database migration ordering

Migrations written to be backwards compatible with the currently running code — add before you read, deprecate before you drop — so a deployment can be reversed without a restore. Destructive changes are separated into their own later release.

Rollback and release safety

A rehearsed rollback path, feature flags for changes that cannot be reversed by redeploying, and a documented decision on who calls it during an incident. Rollback that has never been practised is a plan, not a capability.

Ephemeral preview environments

Per-branch environments created on open and destroyed on merge, so reviewers and stakeholders judge working software rather than a description of it. We cap their lifetime, because forgotten preview environments are a quiet and reliable source of cloud spend.

03Use cases

Where this work usually starts

Ending manual deployments

Releases currently run from one engineer's laptop against a written checklist. We move it into a pipeline, in the open, so the process is inspectable and the person is no longer the process.

Professional Services

Deploying during trading hours without fear

A storefront that cannot take a maintenance window in December. Blue/green cutover with health checks and a tested reverse path makes an ordinary fix possible in an ordinary week.

E-commerce

Making a release auditable

Approvals, artefact provenance and change records that an auditor or an enterprise customer can follow from commit to production without taking anyone's word for it.

Finance

04Approach

How we approach it

We make the pipeline the only route to production and then make that route fast enough that nobody wants to go around it. Every merge builds one artefact, that same artefact moves through staging to production, and the checks that would otherwise be a checklist — tests, type checking, linting, dependency audit, migration dry run — run automatically. Database changes are ordered so schema and code can be deployed independently, which is what makes a rollback possible at all. Deployments are rolling or blue/green depending on what your traffic and your database can support, and we say which one we recommend and why.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
Release audit
How a change currently reaches production, including the undocumented steps and the parts only one person performs. This is a conversation with the people who do it, not a document review.
02
Pipeline design
Stages, gates, approvals and the target build time, agreed against how often you intend to release and what the cost of a bad release actually is.
03
Build and integrate
Pipeline built against a non-production environment first, with the test suite and migration handling brought up to the standard the pipeline assumes.
04
Rehearse failure
A deliberately failed deployment and a rollback performed with your team watching, before the pipeline handles anything that matters.
05
Cutover and coaching
Production moved onto the pipeline, then a period of pairing so your engineers change it confidently rather than filing a ticket with us.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

Pipeline configuration in your repositoryVersion controlled alongside the application, reviewable like any other change.
Container build and artefact registry setup
Migration strategy and conventionsWritten rules for ordering, reversibility and separating destructive changes.
Deployment and rollback runbookIncluding the rollback we rehearsed together and who is authorised to call it.
Secret management configuration and rotation procedure
Working session with your engineers on maintaining the pipeline

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

TypeScript

Data & Storage

PostgreSQL

Cloud Platforms

Amazon Web Services

DevOps & Operations

Docker
Kubernetes
Terraform
GitHub Actions

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Pipelines authenticate to the cloud with short-lived federated credentials rather than stored access keys, and deployment permissions are scoped to the environment being deployed. Secrets are injected at runtime from a managed store, never committed and never printed into build logs. Dependencies are scanned on every build and the artefact is built once from a reviewed commit, so what is tested is byte-for-byte what is released. Production deployment requires an approval that is recorded.

Our full security and quality approach

09Questions

Asked before we start

Do we need Kubernetes?

Probably not. For most organisations asking us this question, Kubernetes adds a platform that itself needs upgrading, securing, monitoring and staffing, in exchange for flexibility they will not use. A managed container service or an application platform runs the same containers with a fraction of the operational load. We recommend Kubernetes when you are genuinely running many services with varied scaling behaviour and have people whose job includes the cluster — and we will tell you plainly when you are not that organisation.

How often should we be deploying?

As often as you have changes worth releasing, which for most teams means several times a week rather than monthly. Small releases are easier to review, easier to diagnose and easier to reverse. The batching that feels safer is usually what makes a release risky in the first place.

What happens to database changes during a rollback?

This is the honest limit of any rollback story. Code can be reverted in seconds; a migration that dropped a column cannot. We handle it by writing migrations to be compatible with the previously deployed code and by separating destructive changes into a later release, once the new code has been running for a while. Where a change genuinely cannot be made reversible, we say so before it ships and agree the recovery approach with you rather than discovering it during an incident.

Can our team maintain this after you leave?

That is the point, and it partly depends on you. We build the pipeline with your engineers involved, keep the tooling ordinary rather than clever, and leave the configuration in your repository with a runbook. If your team has no one who works comfortably in the pipeline, the more honest recommendation is a simpler pipeline you can own or an ongoing support arrangement, rather than something impressive that quietly becomes unmaintained.

START HERE

Talk to us about DevOps & Deployment

The project brief takes about five minutes and gives us enough to have a useful first conversation about DevOps & Deployment rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.