Travel
When the freeze lifts, weeks of changes ship at once
Around peak booking and travel seasons, fixes wait for the next window and each release needs several teams online. We build one pipeline per release flow that any engineer on your team can start, with checks after every stage and a tested rollback.
- Your tools stay
Release calendar · peak season
Approved fixes still go out during the freeze
- Release, every stage checked
- Freeze week
- Approved fix
Release bot#releases
Fix 2.21.1 is live: approved in the pipeline, every stage checked, rollback tested before go-live.
What slows releases
What travel releases wait on
The end of the freeze
Releases stop for weeks around the peak, while the team keeps merging. The first release after the freeze carries all of it, and when something breaks, it is hard to tell which change did it.
Several teams on one call
A change to booking can touch search, payments and supplier connections. So the release runs on a call with someone from each team standing by, and it goes out when all of them can be there.
The next release window
A fix that is ready on Tuesday waits for the next window, and travelers keep hitting the bug until then. Or it goes out by hand under pressure, with a rollback nobody has tried.
What changes
Your freeze calendar stays. The releases around it change.
When to freeze stays your call. A Build changes how each release runs, inside the freeze and outside it.
-
TodayWeeks of changes go out in one release after the freeze, run by hand, step by step.
After a BuildAny engineer on the team starts a release from one pipeline per release flow, without waiting on another team.
-
TodayThe release runs on a call, with several teams online to do their part and ask where it is.
After a BuildHandoffs become stages of the pipeline, and status messages in chat or the ticket answer “Where is it now?”
-
TodayA fix waits for the next window, or goes out by hand with a rollback nobody has tried.
After a BuildEvery stage checks its own result, and rollback is tested before go-live.
-
TodayA freeze exception is approved in a separate thread, and the record of what shipped is pieced together later.
After a BuildThe approvals your policy requires run inside the pipeline, and every production release leaves a change record your change board can check.
Results
The same release work at Nike and ASML
Results from release work at Nike (retail) and ASML (semiconductors), where hand-run release and integration steps became self-service pipelines.
| Nike (retail) | Before | After |
|---|---|---|
| Store-server upgrades | five teams, by hand | one self-service pipeline |
| Upgrade time, per server | 6 to 8 hours | about 3 hours |
| Servers at the same time | 2 | 8 |
| Test build to staging devices | 5 to 10 minutes | about 1.5 minutes |
| Hand-offs per deployment | 1, and the wait for it | none |
| Engineering time back | 600+ hours a year | |
ASML (semiconductors)
Integration steps that ran by hand became one self-service CI pipeline
Standardized for multiple teams, with one Python and SQL view of test results for release-readiness decisions.
“It was a pleasure for the team and me to work with Mateusz and I wouldn’t hesitate to hire him again.”
300+engineering hours a year
Read the ASML caseReading
Reading for the next peak season
- ArticleShipping Faster Without Grounding the Fleet: SDLC Discipline for High-Availability Travel PlatformsWhy shipping more changes exposes weak foundations in tightly coupled booking stacks, and what teams that hold up at peak do differently.Read the article
- ArticleProgressive Delivery in 2026: Canary vs Blue-Green vs Feature FlagsHow canary releases, blue-green deployments and feature flags shrink the blast radius of a release, and how each one rolls back.Read the article
- ArticleDisaster Recovery in 2026: RTO vs RPO, the Four DR Strategies, and What EU DORA RequiresRecovery targets per business function, the four recovery strategies, why replication is not a backup, and how often to test.Read the article
Where to start
Start with your last release
The free Release Check shows where your last release spent its time and what that costs a year, in under 5 minutes and without a call.
Contact
Talk to the engineer
Book 30 minutes and bring your last release, or send a message. You talk with Mateusz directly.