From release weekends to routine deploys.
CI/CD, infrastructure as code, observability and SRE practice — the operational backbone we run under our own products, installed in your organisation.
- Baseline
- Pipeline & IaC
- Observability & SLOs
- Operate & handover
A deploy should be the least interesting event of the day.
The gap between “works on staging” and “running calmly in production” is where enterprises lose their velocity. It shows up as a release weekend, a change-advisory board that meets on Tuesdays, a runbook in a shared drive that only one person has ever followed, and a deployment that four people watch in silence. None of that is a tooling problem. It is the absence of a path to production that is written down, executed the same way every time, and reversible when it goes wrong.
We close the gap with the same platform discipline our own products run on: everything as code, everything observable, every failure rehearsed. The pipelines, Terraform modules, dashboards and on-call design we install in your organisation are the ones we use to operate our ObelusLabs platforms to a contracted uptime target — not a reference architecture drawn for a slide. We start by measuring what your delivery actually does today, because “we deploy fortnightly, mostly” is not a baseline you can improve against.
When deploys are routine, teams ship small and often — and small changes are safe changes, because the blast radius of one hour of work is something a human can still reason about at two in the morning.
Four things we install, in this order.
Each one is useless without the one before it. Observability on a pipeline nobody trusts produces dashboards nobody reads; SRE practice without a rollback path produces heroics.
CI/CD pipelines
Trunk-based flows with automated tests, security scans and preview environments — merge to production, safely. Every pull request builds once, gets its own ephemeral environment, and carries the artefact it produced all the way to production, so the thing you tested is the thing that ships. The slowest and scariest manual step is automated first, because that is the one keeping batch sizes large.
Infrastructure as code
Terraform-managed environments that are reviewable, reproducible and disposable. No snowflake servers, no console clicks that nobody wrote down, no staging that quietly differs from production in the one setting that matters. Guardrails — encryption, tagging, network egress, least-privilege IAM — are policy in the same repository, enforced on the plan rather than discovered in an audit.
Observability
OpenTelemetry traces, metrics and logs with SLO-based alerting — pages for symptoms users feel, not noise. One request can be followed from the edge through every service and queue it touches, which turns “the app is slow” into a span with a name. Alerts are tied to error budgets, so the rotation is woken by things that are burning the budget and by nothing else.
SRE practice
Error budgets, incident response, blameless postmortems — the habits that turn outages into improvements. We define SLOs with the people who own the service, rehearse failure in game days before it happens for real, and write the runbook while the memory is fresh. The measure of success is that your engineers hold the pager confidently, not that we do.
How the work runs, day to day.
One path to production, and no way around it.
Where releases are rare, there are usually three paths to production: the pipeline, the emergency script, and the person who knows how to do it by hand. We collapse them into one. A commit builds a single immutable artefact, that artefact moves through test, scan, preview and canary stages, and production is the last gate rather than a separate procedure. Promotion is a signed decision recorded in the repository, and every stage can refuse — a failing contract test, a critical CVE, a performance budget breach or an unapproved infrastructure change all stop the line in the same way. Rollback is the same mechanism running backwards, rehearsed before the first real release, so nobody has to invent it during an incident.
- Build once, promote the same artefact — no rebuild between staging and production
- Preview environments per pull request, torn down automatically, so review happens on running software
- Progressive delivery: canary or blue-green with automated rollback on SLO burn, not on a human noticing
- Emergency changes use the same pipeline with a shortened gate list and a recorded approver
- 01Commit
- 02Build & test
- 03Scan
- 04Preview
- 05Canary
- 06Production
The path to production
Guardrails that answer before the auditor asks.
Infrastructure as code is often sold as reproducibility. The bigger win is that policy becomes reviewable. When accounts, networks, identity and data stores are Terraform in a repository, a control is a rule that runs on every plan instead of a paragraph in a document. A bucket cannot be created public. A database cannot be created outside the region your data-residency obligations allow. A production role cannot be granted to a human without an approval trail. The result is that a compliance conversation starts from evidence — a plan output, a policy run, a commit history — rather than from a promise. Pair it with our Cybersecurity service where the estate needs deeper assurance.
- Modules for the environments you actually run, versioned and reused rather than copied
- Policy as code on every plan: encryption, tagging, egress, public exposure, region pinning
- Drift detected and reported, so the console change someone made at midnight does not survive quietly
- Environments are disposable — a new region or a full rebuild is a pipeline run, not a project
Pages for what users feel, silence for everything else.
An alerting system that pages on CPU teaches a rotation to ignore it. We instrument for symptoms: latency at the percentile your users experience, error rate on the journeys that earn money, queue lag on the flows that must not fall behind. Each service gets an SLO agreed with the people who own it and an error budget that makes the trade-off explicit — when the budget is healthy, ship; when it is burning, stop and fix. Traces carry context across services and message topics, so an incident starts with the span that is slow rather than with five engineers grepping in parallel. See Kafka & event-driven for how we trace across an event backbone.
- OpenTelemetry across services, jobs and consumers with context propagated end to end
- SLOs and error budgets per service, with burn-rate alerts instead of static thresholds
- One dashboard per service that answers “is it healthy, and if not, where”
- Alert policies exported as code and reviewed like any other change
The bill becomes a number someone owns.
Cloud spend drifts upward for unglamorous reasons: environments nobody remembered to delete, storage tiers left on the default, instances sized for a launch that happened three years ago, and no tag saying who the cost belongs to. Once the estate is code, that becomes tractable. Tagging is enforced at plan time, so every resource has an owner. Non-production environments shut down outside working hours. Rightsizing and reserved-capacity decisions are made against real utilisation, not against the original architecture document.
- Cost attributed per team, product and environment from enforced tags
- Idle and orphaned resources reported regularly, at a rhythm agreed with you, with an owner attached
- Rightsizing and commitment planning against measured utilisation
- Budgets and anomaly alerts as code, so a surprise is caught early, not at invoice time
What each side of the table gets.
A change reaches production as a routine step.
Developers get preview environments on every pull request, a suite fast enough that nobody skips it, and a promotion path they can read. Merging becomes the interesting decision; deploying becomes routine. Small batches are the point — a change that took an afternoon can be reasoned about, reviewed properly and rolled back in one action.
- Preview environment per pull request, destroyed on merge
- Rollback in one action, rehearsed before it is needed
A rotation that can be held without dread.
On-call is designed, not inherited: a sensible rotation size, alerts that correspond to user pain, a runbook per alert, and a handover that says what happened. Game days rehearse the failures that actually threaten you — a region loss, a dependency timing out, a queue backing up — before they happen unannounced on a Friday.
- One runbook per alert, tested in a game day
- Escalation and handover written down, not remembered
- Postmortems blameless, with actions tracked like any other work
Controls that produce evidence on their own.
Scanning runs in the pipeline: dependencies, containers, infrastructure plans, secrets. Access to production is least-privilege IAM defined as code with named approvers, and every change carries a commit, a reviewer and a build record. We document our controls against ISO 27001 and treat GDPR / KVKK as design inputs, so the artefacts an assessor asks for are produced by the system rather than assembled before the visit.
- SAST, dependency, container and IaC scanning as pipeline gates
- Secrets in a managed store, never in a repository or a build log
- Change history, approvers and policy results retained as audit evidence
Four numbers that say whether delivery is improving.
Deployment frequency, lead time for change, change-failure rate and time to restore are measured from the pipeline itself, not from a survey. They give you a defensible answer to “are we getting faster or just busier”, and they make the cost of a change freeze visible. We report the baseline first, and the trend thereafter at a rhythm agreed with you.
- DORA metrics collected automatically from pipeline and incident data
- Cost per environment and per team from enforced tagging
- A trend you can put in front of a board
What every engagement includes, and what depends on your estate.
Four phases, then your team holds it.
Baseline
Deployment frequency, lead time, MTTR, change-failure rate — measured, not guessed. We instrument the pipeline and incident record you already have, walk one real release end to end with the people who perform it, and map where time and confidence are actually lost. The output is a written baseline and a ranked list of the changes that will move it most.
Pipeline & IaC
The path to production rebuilt as code, with the slowest, riskiest steps automated first. Environments move into Terraform module by module, starting with the ones that block delivery. One service goes end to end through the new path before the rest follow, so the pattern is proven on something real rather than agreed in a document.
Observability & SLOs
Instrumentation, dashboards and alerting tied to what users experience. SLOs are agreed service by service with the teams that own them, alerts are rewritten as burn-rate policies, and the noisy pages that trained everyone to ignore the channel are deleted. By the end of this phase an incident starts with a trace, not with a guess.
Operate & handover
Game days, runbooks, and on-call design — then your team runs it, with us on the bench as needed. We rehearse the failures that matter, run the rotation jointly until the handovers are smooth, and leave the repositories, dashboards and procedures in your hands. Continued operation is an option, never a dependency we engineer for.
What you have at the end.
- CI/CD pipelines with quality and security gates
- Terraform codebase for all managed environments
- Observability stack with SLO dashboards and alert policies
- Incident-response runbooks and postmortem practice
- DORA-metric baseline and trend
- On-call design: rotation, escalation, handover template and game-day record
- A cost model with tagging enforced, budgets and anomaly alerts as code
When this is the right call.
Choose this when releases are events rather than routine: a change freeze, a release weekend, a board that meets before anything can ship. Choose it when incidents are found by customers rather than by alerts, when nobody can say what is running in an environment without logging in to look, when the cloud bill grows faster than the traffic, or when one person is the only route to production and everyone knows it. It pairs naturally with Cloud Migration when the estate is moving anyway, and with QA & Testing when the reason deploys are slow is that nobody trusts the tests.
It is the wrong first move when the product itself has not been decided — a team still searching for a market needs an MVP, not an error budget. It is the wrong move when the organisation wants the tooling without the practice: pipelines and dashboards installed over an unchanged approval culture become expensive decoration. And we will tell you when Kubernetes is not the answer. A single application with predictable load is often better served by managed containers or a platform service, and the honest recommendation is the simplest platform that meets your scale and compliance needs.
Frequently asked questions
Where this service usually sits.
Tell us what you’re building.
Describe what exists today and what you need. An engineer reads it and replies in writing with how we would approach it, and the model that fits.