DevOps consulting in the Netherlands
DevOps consulting for releases that still wait on people
We automate the release flows that cost you the most, in the tools you already run, and hand them to your team. Then any engineer can start a release and roll it back without waiting on another team.
- Your tools stay
Global retailer · store-server upgrades
One self-service pipeline instead of a checklist passed between five teams
- Servers at the same time: 2 → 8
- Teams involved: 5 by hand → 1 pipeline
What changes
A release, once the pipeline is yours
One pipeline per release flow. Every stage checks its own result.
Start
Any engineer on the team starts the release, without a ticket to another team.
Build and test
Every change is built and tested the same way, every time.
Approve
The approvals your policy requires run inside the pipeline.
Deploy
Hand-run steps and handoffs become stages of one pipeline.
Check and roll back
Each stage checks its own result. Rollback is tested before go-live.
Record
Status in chat or the ticket, and a change record for every production release.
The one person who knows how becomes a runbook, a trained team, and a pipeline your team has already changed on its own.
Scope
What we automate, and where we've done it
Every line in the last column comes from a published case.
| Area | What we build | Where we did it |
|---|---|---|
| Release pipelinesCI/CD automation | One pipeline per release flow, started by the team, with checks after every stage and a tested rollback. | ASMLIntegration steps that ran by hand became one self-service CI pipeline, standardized across teams. |
| Upgrades at scale | Upgrades that run in parallel through one pipeline, instead of a checklist passed between teams. | NikeStore-server upgrades from 6-8 hours to about 3 per server, eight servers at a time instead of two. |
| Self-service deploys | Deploys to test and staging that developers start themselves. | NikeA test build reaches staging devices in about 1.5 minutes, started by the developer, instead of 5-10 minutes by a release engineer. |
| Release readiness and recordsTraceability | One view of whether a release is ready, and a change record for every production release. | ASMLOne Python and SQL reporting view of production machine test results. |
| Mobile and device delivery | Signing, notarization and device management built into delivery. | NikeJamf integration with macOS signing and notarization. Provisioning from 45 minutes of hands-on work to about 3. |
| Recurring chores | One-click or scheduled automation for the work that comes back every week. | NikeA quarterly test-driver update from about 2 hours to under a minute. Device-profile repair in one click. |
| Cloud and migrationsSoftware migration | Infrastructure on AWS, Azure and Google Cloud, and test workloads moved to the cloud. | ASMLThe first offload of production machine tests to Google Cloud. NikeHigh-priority vulnerabilities in Azure and AWS mitigated. |
How a Build runs
Acceptance criteria first, then the pipeline
Plan on 4 to 8 weeks. You sign the criteria before the build work starts.
Criteria signed
From your Review, or from the Build's first week.
One release end to end
Early on, one release runs end to end through the new pipeline in test.
Flow by flow
Every manual step automated, with checks after each stage, a tested rollback and status messages.
Your team takes over
Each team releases once with us, then on its own.
Acceptance
Three production releases in a row meet the criteria. Then handover and 30 days of support.
“Previously, moving CI workflows between Dev, Staging, and Prod required manual, uncommitted code changes. Mateusz implemented a solution that reduced this to a single line of code, streamlining the process and enabling faster iteration for both developers and our team.”
Questions
Before you book a call
Anything else, ask in the call or send a message.
Do we have to switch CI tools?
No. We work with your existing stack and add tools only when they're needed, to avoid new tech debt.
Who does the work?
You work with us directly, from the first call to the decision meeting, not through an account manager.
What does a Build need from our team?
An owner for each release flow, access to your repositories, CI/CD and environments in the first week with least privilege, a contact in security, a test environment that mirrors production, and at least 3 to 4 hours a week from one of your engineers.
What if the pipeline doesn't meet the criteria?
Then the second half of the Build fee isn't due yet. It's due when every acceptance criterion passes in your environment, over three production releases in a row.
How do you handle access and data?
The Review works from read-only access to CI/CD and ticket data, or exports, under NDA. Exports are deleted after the decision meeting. A Build asks for least-privilege access in its first week.
Do you work outside the Netherlands?
Yes. We work with engineering teams in Benelux and North America. Review prices for North America are in US dollars.
Where do we start?
With the free Release Check: 11 questions about your last release, with the cost and three fixes on screen. No call needed.
Contact
Talk to the engineer
Book 30 minutes and bring your last release, or send a message. You talk with Mateusz directly.
