Service 04 / 05

Deliverywith a way back.

Automated delivery with checks that actually block — and a rollback that doesn't run for the first time in an emergency.

When this fits

Four situations in which this service is the right answer.

01
Deployments no longer happen on Fridays, because nobody knows what will be broken on Monday.
02
The pipeline is green and production still goes down — the checks check the wrong thing.
03
The environment on one colleague's laptop is the only one where everything works.
04
An outage is reported by a customer, not by monitoring.

How we work

Order and stance. The four steps themselves are under Process.

A pipeline is only as good as the check that stops it. So the work starts at the gates: which tests, which security and licence checks, which build artefacts have to pass before anything ships — and what happens when they don't. A gate you can bypass isn't one.

Environments are generated from code, not maintained by hand. Development, preview and production differ in configuration, not in structure — so an error that doesn't show in preview stays out of production too.

Monitoring and alerting are aimed at the questions that matter in an outage: what is broken, since when, and how do we get back? The rollback is rehearsed before it is needed.

From this site's repositoryAt a3e8bcf · .github/pipeline.yaml

 1deployment:
 2  provider: cloudflare-workers
 3  cloudflare:
 4    config: wrangler.jsonc
 5    # populateCache copies the prerendered [slug] pages into the asset bundle
 6    # (static-assets incremental cache, see open-next.config.ts); without it
 7    # every generateStaticParams route is a 404 on the Worker.
 8    build_command: npm run build && npx opennextjs-cloudflare build && npx opennextjs-cloudflare populateCache local
 9
10  # Three environments, one name each, identical in GitHub / Cloudflare /
11  # Infisical. See ~/docs/operations/ENVIRONMENT_CONVENTION.md. `development`
12  # is local-only and never deployed, so it has no entry here.
13  #
14  # Feature-branch PRs are deliberately NOT deployed: PR pipelines build, lint
15  # and test only. The first deployment of a change is the merge to `dev`.
16  environments:
17    - name: preview
18      trigger:
19        event: push
20        branch: dev
21      auto_deploy: true
22
23    - name: production
24      trigger:
25        event: push
26        branch: main
27      auto_deploy: true

The block that ships this very page — not an example, the configuration. It is read again at the next build.

What you get

What is in your possession at the end — not in ours.

01
A CI/CD pipeline as code, with gates for tests, security and build
02
Reproducible environments for development, preview and production
03
Monitoring, alerting and a documented, tested rollback
04
An operations runbook your team actually uses in an emergency

When we advise against it

The cases in which we say no. Beforehand, not afterwards.

We don't build a pipeline we then have to operate for you. If after the handover only we can trigger a deploy, it wasn't a handover.

Questions

What is usually asked about this service.

01Which platforms do you work on?

Most often GitHub Actions, Docker and infrastructure as code on Cloudflare, Vercel or your own infrastructure. Existing platforms such as GitLab are no obstacle — the principles are the same.

02We already have a pipeline. Is it still worth it?

Often, yes: most pipelines ship, but few really block. An assessment of the existing gates is a small, clearly bounded engagement — remote from Mainz, wherever your team sits.

03How fast is a rollback?

It depends on the application — minutes for stateless services, and for database changes as long as the migration takes backwards. Which is exactly why it is planned and rehearsed beforehand.

Let's talk.

You get an honest first assessment — including the cases where we advise against it.

E-mail: kontakt@navigaite.de
Phone: +49 156 79701573
Response time: Usually by the next working day.
Location: Mainz, DeutschlandMainz