Retail

Store rollouts that still run on checklists and handoffs

We turn store upgrades and releases into pipelines your team starts, with a check after every stage and a tested rollback. At a global retailer with 900+ stores, one self-service upgrade pipeline cut store-server upgrades from 6 to 8 hours to about 3 per server.

  • Your tools stay
Illustration: a store release after a Self-Service Release Build.

What slows releases

Where retail releases get stuck

  1. Store upgrades pass from team to team

    One team prepares the package, another books the store windows, and a third runs it server by server. Every handoff is a wait.

  2. Only a few stores can be upgraded at once

    When every upgrade is run and watched by hand, the team can only handle a few stores at a time. A rollout to the whole fleet drags on, and stores run different versions in the meantime.

  3. Peak season makes every change a risk

    Before peak, nobody wants to touch checkout or the stores. Changes queue up behind the freeze and go out together afterwards, in one release that is harder to check and to roll back.

What changes

From a checklist between teams to a pipeline your team starts

A Self-Service Release Build automates the release flows that cost you the most, end to end, and hands them to your team. Plan on 4 to 8 weeks.

See the Build
  • TodayEach team runs its part of a store upgrade by hand, then passes it to the next.

    After a BuildHand-run steps and handoffs become one pipeline per release flow, started by your team.

  • TodaySomeone watches each upgrade and decides by hand whether the store is fine.

    After a BuildEvery stage checks its own result, and rollback is tested before go-live.

  • Today“Which stores have the new version?” gets asked in chat, on calls and in the stand-up.

    After a Build“Where is it now?” gets answered by status messages in chat or the ticket.

  • TodayThe full procedure sits with one or two people, and they are needed most at peak.

    After a BuildThe one person who knows how becomes a runbook, a trained team, and a pipeline your team has already changed on its own.

Results

What changed at Nike, across 900+ stores

Store-server upgrades ran by hand across five teams, only two servers at a time. We replaced that with one self-service upgrade pipeline, let developers start their own staging deploys, and added Jamf integration with macOS signing and notarization for mobile delivery.

NikeBeforeAfter
Store-server upgrade, per server6 to 8 hoursabout 3 hours
Store servers upgraded safely at the same time28
Test build to staging devices5 to 10 minutes, by a release engineerabout 1.5 minutes, started by the developer
Mobile app and bot provisioning45 minutes of hands-on workabout 3 minutes
Recurring device-profile repair, several times a weekby handone click
Quarterly test-driver updateabout 2 hoursunder a minute
Engineering time on this work600+ hours a year back
“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.”
Jon V.Mobile Release Engineer Lead, Nike

Read the Nike 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.