Skip to content

Taking the fear out of shipping a release

A pipeline that takes the code from a commit to production on its own: tests, image, deployment to three different targets, and a check that it answers.

Who
Mayda Morales Viera
When
2026
Built with
Jenkins · Docker · Kubernetes · Terraform · Node.js

Our own end-of-course project. The code and the pipeline are public.

  • 7automatic steps between the commit and the service running
  • 3targets deployed in the same run
  • 0manual steps along the way

The situation

In plenty of places, releasing is still one person logging into a server on a Friday afternoon. It works until the day that person is on holiday, or skips a step, or nobody remembers what the order was.

What was built

The whole pipeline described in a file that lives next to the code: run the tests, build the image, publish it, deploy it to a container server, to a cluster and to a machine running it as a system service, and finish by asking each target whether it really answers. Credentials kept out of the repository.

What came out

Releasing stops being an act of faith and becomes a button. If something breaks, it breaks in the pipeline and not in the customer's face, and you hear about it in minutes instead of in a phone call from someone angry.

What this has to do with you

It is the same idea we sell to any small business, applied to our own house: if a process repeats, you write it down once and nobody does it by hand again.

All case studies