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
Illustration: one release flow after a Self-Service Release Build.

What slows releases

What travel releases wait on

  1. 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.

  2. 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.

  3. 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.

See the Build
  • 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)BeforeAfter
Store-server upgradesfive teams, by handone self-service pipeline
Upgrade time, per server6 to 8 hoursabout 3 hours
Servers at the same time28
Test build to staging devices5 to 10 minutesabout 1.5 minutes
Hand-offs per deployment1, and the wait for itnone
Engineering time back600+ hours a year
Read the Nike case

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.”
Maikel JansenGroup leader SW Stage Position and Measurement, ASML

300+engineering hours a year

Read the ASML case

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.

Mateusz UlasFounder and platform engineer

    Send us a message

    Leave a message and we'll get back to you.

    Read how we handle your details in our privacy notice.