Capability

Delivery pipelines that make production releases routine

We design the path from commit to production: build, test, security analysis, artefact management, environment promotion and progressive rollout. Security checks run inside that path, so a release is verified by the same system that ships it.

Discuss your system

Overview

DevOps is the engineering of the delivery system itself. The codebase, the pipeline, the environments and the feedback loops form a machine whose output is working software in production, and that machine can be designed well or badly. A well-designed one releases small changes many times a day with low failure rates. A badly designed one batches weeks of work into a release that needs a change window and a rollback plan nobody trusts.

DevSecOps extends the same idea to security. Instead of a review gate at the end, security controls are automated and placed where they are cheapest to act on: static analysis in the pull request, dependency and container scanning in the build, signature verification at admission, policy enforcement on infrastructure changes. Developers get findings in minutes, in the tool they already use, while the context is still fresh.

We treat pipelines, environment definitions and policies as production software. They are versioned, reviewed, tested and owned. The result we design for is a delivery process that an auditor can read, an engineer can reason about and a new team can adopt without reinventing it.

What we engineer

Technical areas

CI/CD pipeline design

A pipeline is a sequence of quality gates ordered by cost and speed of feedback. We put fast, deterministic checks first, parallelise what can run independently and cache aggressively so that the common case finishes in minutes. Pipelines are defined as reusable templates so that each service inherits the organisation's standards instead of copying YAML.

GitHub Actions, GitLab CI and Jenkins pipeline design
Reusable workflow templates and shared pipeline libraries
Build caching, test sharding and parallel stages
Unit, integration, contract and end-to-end test stages
Database migration checks and backwards-compatibility gates
Ephemeral runners with scoped, short-lived credentials

Source control strategy and build management

Branching strategy sets the batch size of change. We favour trunk-based development with short-lived branches and feature flags, because long-lived branches defer integration risk to the worst possible moment. Builds are reproducible and produce one immutable, versioned artefact that is promoted unchanged through every environment.

Trunk-based development with short-lived feature branches
Release branches only where regulatory or mobile store cycles require them
Semantic versioning and automated changelogs
Immutable container images tagged by commit digest
Artefact registries such as Amazon ECR, GHCR, Harbor and Artifactory
Monorepo and polyrepo build tooling with affected-target detection

Environments and progressive delivery

Environments exist to reduce uncertainty before production, and progressive delivery reduces it further inside production. We build environments from the same infrastructure code with configuration as the only difference, and promote the same artefact through them. In production, canary and blue/green rollouts expose a change to a fraction of traffic and compare its error rate and latency with the baseline before proceeding.

Environment parity through shared Terraform modules and Helm charts
Preview environments per pull request
Canary analysis with automated promotion and rollback
Blue/green cutover for stateful or high-risk releases
Feature flags to separate deployment from release
Expand-and-contract database schema migrations

GitOps and infrastructure automation

In a GitOps model the desired state of every environment lives in Git, and a controller inside the cluster reconciles the running state towards it. That gives a complete audit trail, removes cluster credentials from the CI system and makes rollback a revert. The same discipline applies to cloud resources through Terraform pipelines with plan review and policy checks.

Argo CD and Flux for continuous reconciliation
Environment repositories with promotion by pull request
Terraform and OpenTofu pipelines with remote state and locking
Drift detection and automatic or alerted correction
Sealed Secrets and External Secrets Operator for secret delivery

Shift-left security and supply chain integrity

Most vulnerabilities enter through code the team wrote or code it imported. We automate detection for both at the earliest stage that gives a reliable signal, and tune each tool so that findings are actionable instead of ignored. The build then produces evidence: a software bill of materials, a signature and provenance describing what was built, from which source, by which pipeline.

SAST with Semgrep, CodeQL or SonarQube
Software composition analysis and dependency update automation
Container image scanning with Trivy or Grype
Secret detection in commits and history with Gitleaks
SBOM generation in CycloneDX or SPDX format
Image signing with Sigstore Cosign and SLSA provenance attestations
DAST and API fuzzing against deployed test environments

Policy as code and platform engineering

Rules that live in documents are followed inconsistently; rules that live in code are enforced every time. We express security and operational policy with Open Policy Agent or Kyverno and evaluate it against Terraform plans, Kubernetes manifests and pipeline definitions. Around that, we build golden paths: templates and self-service tooling that make the compliant way of creating and running a service the easiest one.

OPA and Conftest checks on infrastructure plans
Kyverno or Gatekeeper admission policies in clusters
Service templates and scaffolding for new repositories
Internal developer portals such as Backstage
Self-service environment and database provisioning
DORA metrics collected from pipeline and incident data

Deployment and release are different events

Deployment is moving new code into production. Release is exposing new behaviour to users. Treating them as one event forces every deployment to carry business risk, which leads to change windows, release trains and large batches. Separating them lets code ship continuously while exposure is controlled independently.

Feature flags provide the separation for behaviour; canary and blue/green strategies provide it for runtime risk. A canary rollout sends a small percentage of traffic to the new version and compares its metrics with the stable version over a defined interval. If error rate or latency regresses beyond a threshold, traffic returns to the stable version automatically. Blue/green keeps two complete environments and switches traffic at once, which suits releases that cannot serve mixed versions.

Both depend on the data layer tolerating two application versions at the same time. Schema changes therefore follow an expand-and-contract sequence: add the new structure, deploy code that writes to both, migrate data, switch reads, then remove the old structure in a later release. Skipping this is the most common reason a rollback fails.

Architecture

CI/CD pipeline with security gates

Build & verify

01
Commit
Reviewed merge to the main branch
02
Build
Reproducible, pinned dependencies
03
Test
Unit, integration and contract tests
04
SAST and deps scan
Static analysis, dependency audit
05
Image scan and sign
Scan layers, sign, attach SBOM

Release

01
Staging
Same artefact, production-like data
02
Canary
Small traffic share, watch signals
03
Production
Progressive rollout with gates
04
Monitor
SLOs decide promote or roll back

One artefact is built, verified, scanned and signed, then promoted unchanged through staging and a canary into production. Monitoring closes the loop by deciding whether a release is promoted or rolled back.

Securing the software supply chain

A modern service is mostly third-party code: open source libraries, base images, build tools and CI actions. Each is a path by which an attacker can reach production without touching the application's own source. Supply chain security is the practice of knowing what went into an artefact and proving that it was not altered between source and runtime.

The controls form a chain. Dependencies are pinned by version and hash, and updates arrive as reviewed pull requests. Builds run on isolated, ephemeral runners with no standing credentials. Each build emits an SBOM, so that when a new vulnerability is disclosed the affected services can be found by query. The artefact is signed, and a provenance attestation records the source commit and pipeline that produced it. At deployment, an admission policy rejects any image that is unsigned or built outside the trusted pipeline.

Pin dependencies, base images and CI actions by digest
Generate an SBOM for every build and store it with the artefact
Sign artefacts and verify signatures at admission
Record provenance aligned with the SLSA framework levels
Fail builds on severity thresholds agreed in advance, with a documented exception process

Measuring delivery with DORA metrics

The four DORA metrics describe a delivery system from two sides. Deployment frequency and lead time for changes measure throughput: how often the team ships and how long a commit takes to reach production. Change failure rate and time to restore service measure stability: how often a release causes an incident and how quickly service returns. Research behind the metrics shows that throughput and stability improve together, because both follow from small batches and fast feedback.

We instrument these from pipeline events, deployment records and incident data, so that they are produced by the system instead of reported by people. They are used to locate constraints, such as a slow test stage or a manual approval that adds days, and to verify that a change to the process had the intended effect. They are diagnostic tools for a team, and they stop working when turned into individual targets.

Platform engineering and golden paths

As an organisation grows past a few teams, each one solving pipelines, observability and deployment separately becomes expensive and inconsistent. Platform engineering addresses this by providing an internal platform: a curated set of templates, pipelines and self-service capabilities maintained by a team whose users are other engineers.

A golden path is the supported route for a common task, such as creating a new service with its repository, pipeline, deployment manifests, dashboards and alerts already wired. It is optional by design. Teams with unusual needs can leave the path, but they take on the operating responsibility the path would have carried. The platform succeeds when engineers choose it because it is faster than building their own.

How we engineer it

Our approach

We improve a delivery system in the order that removes the largest constraint first, measuring before and after each change.

01
Map the current value stream
We trace a change from commit to production and record every stage, wait and manual step, together with baseline DORA metrics. This shows where time is lost and where failures are introduced.
02
Stabilise build and test
Builds are made reproducible, flaky tests are quarantined and fixed, and the pipeline is restructured for fast feedback. A pipeline that engineers do not trust will be bypassed, so reliability comes before new capability.
03
Standardise artefacts and environments
Each service builds one immutable artefact that is promoted through environments defined by the same code. Configuration and secrets are injected at deploy time from managed stores.
04
Embed security and policy gates
SAST, dependency, container and secret scanning are added with tuned rules and agreed severity thresholds. SBOM generation, signing and admission policies follow once the build is stable.
05
Introduce GitOps and progressive delivery
Deployments move to reconciliation from Git, with canary or blue/green strategies and automated rollback tied to service metrics. Feature flags separate release decisions from deployment.
06
Package the result as a golden path
The working pattern is turned into templates and self-service tooling that other teams can adopt. Metrics continue to be collected to guide the next round of improvement.

Trade-offs

Decisions that shape the design

The questions we work through with your team before committing to an architecture.

Trunk-based development or GitFlow?: Choose trunk-based development for services you deploy continuously: short-lived branches, feature flags and a main branch that is always releasable keep integration cost low. Choose a release-branch model only when you must support several versions in the field at once, as with packaged software or mobile apps bound to store review cycles. GitFlow's long-lived branches trade daily integration for periodic merge risk, which is rarely a good exchange for a web service.
Canary, blue/green or rolling deployment?: Rolling updates are the sensible default for stateless services with good health checks. Use canary when you have enough traffic to produce a statistically meaningful comparison and want automated verification before full exposure. Use blue/green when versions cannot coexist, when you need an instant switch back, or when traffic is too low for canary analysis; accept that it temporarily doubles capacity cost.
Push-based CI/CD deployment or pull-based GitOps?: Pull-based GitOps with Argo CD or Flux suits Kubernetes estates: the cluster reconciles itself from Git, CI needs no cluster credentials, and drift is corrected automatically. Push-based deployment from the pipeline remains simpler for serverless, virtual machine and managed-service targets that have no reconciliation controller. Many organisations run both, divided by target platform.
Should security findings block the build or only warn?: Block on a narrow, high-confidence set: leaked secrets, critical vulnerabilities with a fix available, and unsigned or unapproved base images. Warn and track everything else with an owner and a remediation deadline. Blocking on noisy findings teaches teams to bypass the pipeline; blocking on nothing leaves the scanners decorative.
Monorepo or one repository per service?: A monorepo makes atomic cross-service changes, shared libraries and consistent tooling easy, but needs build tooling that tests only what changed, such as Bazel, Nx or Turborepo. Separate repositories give teams independence and simple pipelines at the cost of harder cross-cutting changes and version drift in shared code. Choose by how tightly coupled the services are in practice and by how much build engineering you can sustain.
Build an internal developer platform, or keep per-team pipelines?: Below roughly a handful of teams, shared pipeline templates and good documentation are enough, and a platform team would be overhead. Invest in a platform when duplicated effort, inconsistent security controls and slow onboarding are measurable costs. Start with the thinnest useful golden path and grow it from real demand.

Production readiness

What makes it production-ready

How it is secured

Pipelines authenticate to cloud providers with OIDC federation and short-lived tokens, never stored keys, and run on ephemeral runners with least-privilege permissions per job. Branch protection, mandatory review and signed commits guard the source; signature and provenance verification guard the artefact on its way to production.

How it scales

Pipeline capacity scales through autoscaled runners, remote build caches and test sharding, so build time stays flat as the codebase grows. Reusable templates let the number of services increase without a matching increase in pipeline maintenance.

How it is monitored

Every deployment is recorded as an event and overlaid on service dashboards, so a regression can be tied to the change that caused it. Pipeline duration, queue time, failure causes and DORA metrics are tracked as first-class operational data.

How it is deployed

One immutable artefact is promoted through environments by pull request, with automated checks at each stage and progressive rollout in production. Rollback is a revert in Git or an automated traffic shift, and it is rehearsed.

How it integrates

Pipelines connect to issue trackers, chat, artefact registries, secret stores, vulnerability management and change-management systems through APIs and webhooks. Where formal change approval is required, the pipeline supplies the evidence automatically instead of adding a manual step.

Technologies

Chosen to fit the workload and your existing estate.

GitHub Actions
GitLab CI
Jenkins
Argo CD
Argo Rollouts
Flux
Terraform
Helm
Docker
Trivy
Semgrep
Sigstore Cosign
Open Policy Agent
Backstage

From zero to production

The engineering lifecycle

01
Idea
02
Discovery
03
System architecture
04
UX / product design
05
Application engineering
06
AI / data layer
07
Cloud infrastructure
08
Security
09
QA & performance
10
Deployment
11
Observability
12
Continuous evolution

FAQ

Common questions

What is the difference between DevOps and DevSecOps?

DevOps integrates development and operations so that software is delivered through an automated, repeatable pipeline. DevSecOps places security controls inside that same pipeline: code analysis, dependency and image scanning, secret detection, signing and policy enforcement run automatically on every change. In practice a well-built delivery system does both, and the distinction is one of emphasis.

Will adding security scanning slow our pipeline down?

Not materially when it is designed properly. Incremental static analysis and secret detection run in seconds on a pull request; heavier scans run in parallel with tests or on a schedule. The larger risk is noise, so we tune rule sets and thresholds until findings are specific enough to act on.

Can you work with our existing CI/CD tooling?

Yes. The principles are independent of the tool, and replacing a working CI system is seldom the highest-value change. We improve structure, speed and security in the tooling you have, and recommend migration only when the current platform blocks a capability you need.

Do we need Kubernetes to adopt GitOps?

The reconciliation-controller form of GitOps is native to Kubernetes, but the underlying practice applies anywhere: desired state in Git, changes by pull request, automated application and drift detection. Terraform pipelines for cloud resources and serverless deployments can follow the same model without a cluster.

How do you measure whether delivery has improved?

With the four DORA metrics taken from pipeline and incident data, compared against the baseline recorded at the start. We also track pipeline duration, flaky test rate and the time engineers spend waiting on environments, because those explain why the headline metrics move.

Related capabilities

Solutions that use it

Reference architectures

Have a system that needs to work in production?

Tell us what you are building. An engineer will read it and reply within two working days.

Start a project