04 / Selected CI/CD, automation and infrastructure engagements
DevOps Engineering
A cross-section of DevOps work: from releases done by hand after hours to repeatable pipelines, infrastructure described in code, and monitoring that reports problems before users do.
- Client
- A range of organizations, from small product teams to projects delivered in enterprise environments
Diagram of a change's path from commit to production
1600×900 px, SVG/PNG
Overview
This is not the story of a single product but a cross-section of similar problems I solve for different clients. The same picture repeats from company to company: deployments done by hand by one person, a server nobody dares to touch, and environments no one can rebuild. This page collects selected engagements from that area.
One approach connects them: the path from commit to production gets automated, the infrastructure is described in code, and monitoring answers the question of what is going on before a customer asks it. Instead of heroics at every release, there is a boring, repeatable process that simply works.
Some of these practices come from projects delivered in enterprise environments, including work connected with international organizations such as PwC, Roche and E.ON. I bring them to smaller teams at a scale that fits, without the corporate overhead.
Challenge
The typical starting point looks alike everywhere: releases are rare and stressful, configuration has drifted apart between environments, the classic works-on-my-machine problem is routine, and defects are discovered by users instead of by the system. Knowledge of how to deploy the application lives in one person's head — which is a business risk, not just an inconvenience.
The real challenge is not the tooling but changing the process without stopping delivery. Automation has to be introduced into a live project, in stages, without freezing development for weeks — and in a way that leaves the team able to run the process on their own after the engagement ends.
My role
In these engagements I am the engineer who designs the solution and implements it hands-on: pipelines, infrastructure definitions, environment configuration and monitoring. I work directly with the developers and system owners, with no layer of intermediaries.
Just as important is what I leave behind: documentation, transparent definitions in the repository, and knowledge-transfer sessions after which the process belongs to the team, not to me.
Solution
CI/CD pipelines in GitHub Actions
Every code change automatically goes through build, tests and quality checks, and deploying to an environment comes down to an approval. Pipeline definitions live in the repository next to the code, so they go through review and carry a full change history.
Containerization with Docker
I package applications as Docker images, so the same artifact travels from the developer's machine through testing all the way to production. The works-on-my-machine problem disappears, because exactly the same image runs everywhere.
Infrastructure as code with Terraform
Cloud resources on AWS are described in Terraform: networks, services, permissions and configuration come from code, not from clicking through a console. A new environment can be stood up from the same modules, and every infrastructure change goes through review like ordinary code.
Environments, configuration and secrets
I put the split between development, staging and production in order, with per-environment configuration and secrets kept in dedicated mechanisms rather than in files and chat messages. It becomes clear what runs where, and with which settings.
Monitoring and alerting
Systems get metrics, log collection and alerts, built on Amazon CloudWatch among other tools — configured so a notification reaches the right person with guidance on what to do. The goal is to learn about problems from monitoring, not from customers.
Release and rollback process
Releases become small, frequent and versioned, with a clearly described procedure for returning to the previous version. When rolling back takes minutes and no nerves, the team stops fearing deployments — and, paradoxically, makes fewer mistakes.
Technology stack
CI/CD and automation
- GitHub Actions
- Docker
- Bash
Cloud and infrastructure as code
- AWS
- Terraform
Monitoring and observability
- Amazon CloudWatch
Everyday tooling
- Git
- GitHub
Engineering decisions
- 01
All automation lives in the repository next to the code — no configuration clicked together in web panels that nobody can later reproduce or audit.
- 02
Terraform from day one, even for small infrastructure. Describing three resources in code costs hours; importing them after a year of manual changes costs weeks.
- 03
An artifact is built once and promoted through the environments — production receives exactly what passed the tests, not the same thing rebuilt one more time.
- 04
I choose proven, well-documented services over fashionable novelties. The client's team has to run this process after I leave, so the barrier to entry matters.
- 05
Alerts are designed for action: each one has an owner and a documented first response step. An alarm that only makes noise teaches the team to ignore alarms.
Security & reliability
Permissions follow least privilege: pipelines and services receive exactly the AWS permissions they need — no shared administrator keys.
Secrets never land in the repository. They live in dedicated secret stores and can be rotated without code changes.
Environments are isolated from one another — production does not share resources or data with test environments for convenience.
Infrastructure changes go through code review, which leaves a full audit trail of who changed what, and why.
Outcome
Deployment stops being an event. Releases become routine: small, reversible and doable by any authorized person on the team, not just the one admin.
Environments can be recreated from code — standing up a new environment or rebuilding after a failure is a procedure, not archaeology through hand-configured servers.
The client's team understands and independently maintains the whole process, because it is delivered with documentation and knowledge transfer, not as a black box.
Gallery
A GitHub Actions pipeline run (anonymized)
1920×1080 px, AVIF/WebP
Terraform module structure in a repository (anonymized)
1600×1000 px, AVIF/WebP
Monitoring dashboard with metrics and alerts (anonymized)
1920×1080 px, AVIF/WebP
More work
Let's talk about your project
Happy to walk you through how a similar approach would work in your case — and what I would avoid.
- Phone
- +48 573 021 012