Atmora Tech

Cloud & Platform

Ship on Thursday
without anyone staying late

DevOps is not a tooling purchase. We shorten the path from commit to production by removing handoffs, making deployments reversible and building tests that fail for real reasons, then we measure whether any of it worked.

Overview

Delivery pipelines, release engineering and incident practice, measured by DORA metrics.

Ask an engineering team how long a one-line change takes to reach production. The answer, and the length of the pause before it, tells you most of what an assessment would. Usually the delay is not the pipeline. It is a change advisory board that meets on Tuesdays, a shared staging environment with a booking sheet, and a test suite nobody trusts.

So we start from the constraint rather than the tools. That might mean rewriting 200 flaky tests, splitting a 40-minute build with proper caching, or replacing a manual approval with a progressive rollout that halts on error rate. Tool migrations happen only when the existing tool is genuinely the limit, which is rarer than vendors suggest.

The four DORA measures, deployment frequency, lead time, change failure rate and time to restore, are the scoreboard rather than the goal. We instrument them at the start so improvements can be argued with data, and so it is obvious when a change made things worse. Teams that game the numbers get caught by the change failure rate.

26 min
median lead time from commit to production, from nine days
4.7%
change failure rate after six months, down from 18 per cent
9.4x
increase in deployment frequency across 34 services

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Pipeline design and build performance

    Caching, test sharding and dependency graphs applied until CI finishes inside the window where developers still wait for it. Below ten minutes behaviour changes; above thirty, people stop looking.

  • Release engineering

    Progressive delivery through canary or blue-green, feature flags separating deploy from release, and automated rollback triggered by service level objectives rather than by a human noticing a graph.

  • Test strategy repair

    Quarantining flaky tests, rebalancing an inverted test pyramid, and adding contract tests at service boundaries so integration failures surface in CI instead of in a shared environment.

  • Environment and test data

    Ephemeral environments per pull request, seeded with masked production-shaped data. Shared staging queues are usually the single largest contributor to lead time in an enterprise.

  • Observability and incident practice

    Service level objectives with error budgets, alerts that each map to a runbook, blameless review, and an on-call rota where the people who wrote the code are the ones being paged.

  • Secrets and supply chain

    Short-lived credentials through OIDC instead of long-lived keys in CI, SBOM generation, artefact signing and provenance, so a compromised dependency is traceable to the builds that used it.

Deliverables

What you get

  • Value stream map with measured wait times at each stage
  • Reference pipeline implemented for two or three representative services
  • DORA metrics dashboard wired to deployment and incident data
  • Ephemeral environment tooling with data seeding and teardown
  • SLO definitions, alert rules and the runbooks paired to them
  • On-call handbook and incident review template

Stack

What we build it with

  • GitHub Actions
  • Argo CD
  • Kubernetes
  • Terraform
  • OpenTelemetry
  • Prometheus
  • Grafana
  • Dagger
  • Trivy
  • HashiCorp Vault
  • Playwright
  • Sigstore Cosign

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Measure the current state

    Two weeks instrumenting the existing pipeline and incident record. No recommendations until baseline numbers exist and the team agrees they are accurate.

  2. Find the constraint

    Value stream mapping across commit, review, test, approval and deploy. Improving anything other than the constraint changes the dashboard and not the delivery.

  3. Fix it, once

    The team works one bottleneck at a time with a target number attached to it. Parallel improvement programmes reliably produce parallel abandonment.

  4. Codify as a template

    The working pipeline becomes a reusable template with versioned workflows, so the tenth service takes a day of work rather than a fortnight.

  5. Transfer and re-measure

    Your engineers own the pipeline before we leave, and we re-measure the DORA baseline at 30 and 90 days to confirm the change actually held.

When this is the wrong engagement

If you deploy a single monolith four times a year because the business genuinely does not want it changed more often, DevOps investment will not pay back and release quality is the better target.

FAQ

Questions we get asked

Do we need to move to Kubernetes to do this?

No. Deployment frequency and lead time improve on virtual machines, on ECS, on a managed platform and occasionally on a mainframe. Kubernetes helps once you have enough services that scheduling becomes a real problem; before that it adds operational burden without a return.

Our change advisory board is a regulatory requirement. Can we still move quickly?

Yes, but the board changes shape. Standard changes with automated evidence, meaning tests, scans and approval in the pull request, become pre-authorised, and the board reviews the process and the exceptions. Auditors accept this when the evidence trail is generated automatically.

How do you handle flaky tests?

Quarantine immediately, then fix or delete within a fixed window, usually two weeks. A flaky test left in the main suite teaches the team to ignore red builds, which costs far more than the coverage it provides. The quarantine list is tracked as debt with named owners.

Who is on call afterwards?

Your engineers. A model where a separate operations team is paged for services it did not write produces slow restores and no feedback into design. We help set up the rota, the compensation discussion, the escalation path and the handover routine, but ownership sits with the teams.

Related

More in Cloud & Platform

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project