CI/CD & Release Engineering

Pipelines that let you deploy on a Friday, with a rollback somebody has actually run rather than one that exists on a wiki page.

Who it is for
Teams who can describe exactly why they do not deploy on a Friday, and would like that reason to stop being true.
What you get
  • Pipeline design and rewrite
  • Deployment and rollback strategy
  • Security gates inside the pipeline
  • Release process people follow
What I need from you
Your repositories and whatever pipeline you have now, however embarrassing you think it is.
Overview

What this is

A long, error-prone deployment is a symptom of missing automation rather than of team culture. The team already knows what the manual steps are. They have written them down, usually in a document that is out of date, and they take turns doing them on a Tuesday because Tuesday leaves four days to notice.

The work is turning those steps into a pipeline that runs the same way every time, and making the rollback a thing somebody has executed rather than a paragraph nobody has read.

Capabilities

What you get

Pipeline design

  • GitHub Actions, GitLab CI, Jenkins and ArgoCD
  • Reusable workflows and shared libraries instead of copy-paste per repository
  • Build caching and parallelism, so the pipeline is not the slowest reviewer
  • Matrix builds that fail fast on the case most likely to break

Deployment and rollback

  • Blue-green, canary and progressive delivery, chosen for what you run
  • Multi-region deployment with a defined order and a defined stop
  • Rollback automation, tested on a schedule rather than during an incident
  • Database migrations that can go backwards, or a written reason why not

Security in the pipeline

  • Image and dependency scanning that blocks rather than reports
  • Signed artifacts and provenance
  • Secret handling that does not put credentials in the build log
  • Environment protection rules and approval gates that match who is accountable

Release process

  • Pipeline inputs as choices with defaults rather than free text
  • Release notes generated from the work rather than written from memory
  • Versioning and tagging that survives a hotfix
  • On-call handover that includes what shipped since the last one
Evidence

What I can show you

ICF is early, so there are no named client logos here yet. What there is: public code you can open and read, and work described without naming whose it was.

Approach

How I work

01

Read the pipeline

What runs today, how long each stage takes, and which stages people skip when they are in a hurry. The skipped ones are the interesting ones.

02

Agree the target

What "deployable on a Friday" means for your system, written down, including what you are willing to give up to get there.

03

Rebuild in slices

One pipeline at a time, in front of the team, so nobody inherits something they have not seen built.

04

Rehearse the rollback

A rollback that has never been run is a paragraph. We run it, on purpose, before you need it.

Technology

Stack

GitHub ActionsGitLab CIJenkinsArgoCDDockerKubernetesTrivySnykTerraformGo
When to engage

Signs this is the work you need

Deployments happen on a Tuesday so there is time to notice

The rollback plan is a document rather than a command

Each repository has its own copy of the same pipeline, drifting

A release needs somebody specific to be awake

Related Services

You may also need

Is this the work you need?

Tell me what you are running and what is slowing you down. I reply within one business day, and I will say so if this is not work I should take.

Taking a small number of contracts