DevOps consulting

Help for a team that wants to release software often without each release becoming a risk to the work it supports.

Pieces of the pipeline

Most of these parts come into play on any real engagement. Which ones matter depends on how your software is built and shipped today.

Automated builds: A build that runs the same way every time and stops when something it depends on has broken.
Tests on every change: Checks that find the faults most likely to reach users, run before a change is allowed through.
Infrastructure as code: The servers and services a release needs, written down so they can be rebuilt the same way each time.
Release process: A path from a change to production that is routine enough to run several times a week.
Monitoring: Signals that show when a release has made something worse, read soon enough to act on them.
Fast recovery: A tested way to return to the last working version when a release turns out to be broken.
Handover: Your own people left able to run the pipeline and to change it without outside help.

Why frequent releases need a way back

Many teams try to make releases safe by making them rare. A large change is held back for weeks, then shipped all at once on a quiet evening, with people standing by in case it breaks. A release that big contains many changes, and when something goes wrong it is hard to tell which one caused it. Rare releases also tend to grow larger, which makes each one harder than the last.

The approach that holds up ships small changes often. Each one is built and checked the same way, so a problem can be traced to a single change and undone. That depends on a build that runs by itself with tests on every change. The servers a release lands on are written as code, so they can be rebuilt exactly, and monitoring shows when a release has made something worse. The way back to the last working version is tried in advance, so it works on the day it is needed.

How to start

The brief

Say how your software is built and released today, and what tends to break when a release goes wrong.

Working with your team

The pipeline is set up together with the developers who will use it, so they know how each part works by the time it is finished.

Who does the work

Amos Weiskopf is a software engineer, and he sets up the pipelines he proposes himself.

Questions buyers ask

What is DevOps consulting?

It is help for a team that wants to release software more often without adding risk each time. Most of the work is in automating the build and the tests, and in making a failed release easy to undo.

How much does DevOps consulting cost?

That depends on how your software is shipped today and how much of the pipeline has to be built. The price is agreed after the written brief.

Can our team operate the pipeline afterwards?

Yes. The builds and the infrastructure code are set up to suit the skills your team has, so your people can run the pipeline and change it once the engagement ends.

Does our code stay under our control?

Yes. The pipeline runs on accounts and servers you control, and the code it builds stays in your hands.

What is infrastructure as code?

It is writing down the servers and services a release needs as files that can be read and run, so the place a release lands can be rebuilt the same way every time instead of changed by hand.

How soon is there something working?

The first goal is usually one real part of your software going through a pipeline that builds and releases it. The timetable for the rest is set in the brief.

Engagements by written brief.

Work begins from a documented problem statement, not a sales call.

Write a brief Or book a meeting