DevOps & CI/CD
Automated deployment pipelines, containerization and DevOps practices for agile teams.
What's included
- Docker and containerization
- CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins)
- Build time optimization
- Monitoring and alerting
- GitOps and automated deployment
- Staging and production environments
I build robust CI/CD pipelines that speed up release cycles while reducing errors. From continuous integration to automated production deployment.
I work with the platform you already have
I use GitHub Actions and GitLab CI depending on the client's needs, and Jenkins on the many projects where it is the technology already adopted in-house. I don't propose a platform migration as a first move: in most cases the problem is not which runner executes the pipeline, but how the pipeline is written.
A CI migration makes sense when there is a concrete reason behind it — a licence cost, a runner fleet to maintain, a missing integration. Otherwise it is work that produces no visible value for whoever is paying for it.
Build times: 50-60% lower
On the projects where I worked on pipeline optimization, build time dropped by 50-60%. The savings are usually in the same places: dependency caching missing or invalidated on every run, Docker images rebuilt from scratch instead of using layers, jobs run in sequence when they are independent, and full test suites running even when a change touches an isolated area.
This is not a convenience detail. A slow pipeline is why teams stop integrating often, and that is where conflicting merges and risky releases come from.
Monitoring and alerting
On the observability side I work with Zabbix for infrastructure monitoring, the ELK stack for log collection and analysis, and VictoriaMetrics with Prometheus for metrics, visualised in Grafana.
What is usually missing is not data collection but a decision about which thresholds genuinely deserve a notification. A system that alerts on everything gets muted within weeks, and at that point it serves no purpose.
Frequently asked questions
Do we have to change CI tooling to work with you?
No. I work with GitHub Actions, GitLab CI and Jenkins. If you already use one of them, that is where the work happens; a migration is only proposed when there is a concrete reason for it.
How much can build time be reduced?
On the projects I worked on the reduction was 50-60%, but it depends on how much headroom there is. Looking at caching, Docker layers and parallelisation in the current pipeline shows the available margin almost immediately.
Do you handle monitoring as well?
Yes, with Zabbix, the ELK stack, VictoriaMetrics and Prometheus on Grafana. The most valuable part of the work is usually deciding which thresholds deserve an alert, not installing the tools.