DevOps

CI, infrastructure as code, and a release path the team can run without me in the room.

What I do

A release is a button

I set up the pipeline that builds, tests, and ships, so a release is a button instead of a checklist.

Infrastructure as Code

I put the infrastructure in Terraform or Ansible, so the next change is a review instead of a console click.

Alarms before users write in

I add the metrics and the alarms that page someone before users write in.

What you get

The stack you already have

I use the tools that fit the stack you already have.

Fit to the repo

I fit the pipeline to the repo and the deploy you already use.

Less manual release work

The point is a release your team can run without me in the room.

A number you can watch

I track how often you ship, how long a change takes, and how often it fails.

How the work goes

From pull request to production

I look at how a change gets from a pull request to production.

A short list

You get a short list: the pipeline, the infrastructure code, and what to measure.

Small changes in the repo

I wire the tools into the repo you already have, in small changes.

Notes for the next change

I walk the team through the pipeline and leave notes for the next change.

DevOps Tools I Use

These are the tools I use when they fit the job.

Jenkins logoJenkins
Docker logoDocker
Kubernetes logoKubernetes
Terraform logoTerraform
AWS logoAWS
GitHub Actions logoGitHub Actions
Ansible logoAnsible
Prometheus logoPrometheus
Grafana logoGrafana
GitLab logoGitLab
Puppet logoPuppet
Chef logoChef
Nagios logoNagios
Splunk logoSplunk
ELK Stack logoELK Stack
Jenkins logoJenkins
Docker logoDocker
Kubernetes logoKubernetes
Terraform logoTerraform
AWS logoAWS
GitHub Actions logoGitHub Actions
Ansible logoAnsible
Prometheus logoPrometheus
Grafana logoGrafana
GitLab logoGitLab
Puppet logoPuppet
Chef logoChef
Nagios logoNagios
Splunk logoSplunk
ELK Stack logoELK Stack

If the release still needs you in the room, start there.

Questions people ask