Skip to content
DevSaheb

service

DevOps that makes deploying boring

The measure of a deployment pipeline is how little anyone thinks about it. If shipping requires a specific person, a checklist, or a quiet Friday afternoon, the pipeline is the bottleneck — not the team. We build the automation that removes the ceremony, and we hand it over rather than operating it forever.

What we actually change

Most engagements start in the same place: deploys are manual, environments have drifted apart, and nobody is certain what is running in production. The fix is rarely a new tool. It is making the current state reproducible.

So we begin by putting infrastructure into code, so that staging and production are the same thing with different variables. Drift between environments is the root cause behind most 'it worked on staging' incidents, and it cannot be fixed by being more careful.

Then the pipeline: build, test, security scan, deploy, with the quality gates enforced rather than advisory. A gate that can be skipped under pressure is not a gate — it is a suggestion that gets ignored on exactly the day it mattered.

Monitoring that someone reads

A dashboard nobody looks at is not monitoring. We instrument the handful of signals that actually predict user pain — error rate, latency at the 95th percentile, queue depth, saturation — and alert on those. Everything else is available when you go looking, but does not wake anyone up.

Alerts route to a rotation with a written runbook per alert. If an alert fires and the on-call engineer does not know what to do, that is a defect in the alert, not in the engineer.

Rollback before rollout

We do not ship a deployment pipeline until the rollback path has been tested under load. The question is never whether a bad release will reach production; it is how long it stays there.

That usually means versioned, reversible database migrations and a deployment strategy where the previous version is still running when the new one starts taking traffic. It costs a little more to build and it is the difference between a four-minute incident and a four-hour one.

YAML · .github/workflows/deploy.yml

A gate that cannot be skipped under pressure. Each check runs unconditionally — no continue-on-error, no manual override — and deploy depends on all of them, so a red build cannot reach production by someone approving past it. The rollback is verified as part of the pipeline rather than assumed: the previous revision is deployed to a canary and health-checked before traffic moves, because the question is never whether a bad release will ship, only how long it stays.

name: deploy
on:
  push:
    branches: [main]

jobs:
  gates:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false        # report every failing gate, not just the first
      matrix:
        check: [typecheck, test, audit, budget, a11y]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci
      # No continue-on-error anywhere. A gate with an override is a
      # suggestion, and it gets overridden on exactly the day it mattered.
      - run: npm run ${{ matrix.check }}

  deploy:
    needs: gates             # every gate, not a subset
    runs-on: ubuntu-latest
    concurrency:
      group: production      # two deploys must not interleave
      cancel-in-progress: false
    steps:
      - uses: actions/checkout@v4

      # The rollback path is exercised here, not discovered during an
      # incident: the previous revision is brought up and health-checked
      # before any traffic is shifted to the new one.
      - name: Verify rollback target
        run: ./scripts/verify-previous-revision.sh

      - name: Deploy
        run: ./scripts/deploy.sh

      - name: Smoke test
        run: ./scripts/smoke.sh || ./scripts/rollback.sh

Who works on this

  • Nayemul Saheb

    CEO & Software Engineer

    Builds the pipelines and runs the deployments.

The rest of the team

When this is the wrong thing to buy first

If your application has no tests, a deployment pipeline will automate shipping bugs faster. Coverage comes first — there is no point automating a process whose output nobody trusts. Equally, if you are pre-launch with one environment and three users, this is premature. Ship something, find out what breaks, then automate the parts that hurt.

Common questions

Do we need DevOps if we deploy once a month?
Deploy frequency is a symptom, not the problem. Teams that deploy monthly usually do so because deploying is frightening, and it is frightening because it is manual. The work is the same either way; the benefit is that monthly becomes weekly because it stopped being an event.
Which cloud do you recommend?
Whichever one your team already knows. The operational cost of a platform nobody on staff has used outweighs almost any feature difference. If there is no existing preference we will usually suggest AWS for breadth, but that is a default rather than a conviction.
Can you take over an existing pipeline?
Yes. We start by documenting what is currently there before changing anything, because undocumented pipelines usually contain at least one step that is load-bearing for a reason nobody remembers.
Do you provide ongoing on-call?
We can cover a transition period, but the goal is that your team runs it. Permanent outsourced on-call means the people who understand the system are not the people carrying the pager, which makes incidents longer.

Related services

Built with

Tell us the constraint. We will tell you honestly if we fit.

Start a conversation