Reizen

Als de freeze voorbij is, gaan weken aan wijzigingen in één keer live

Rond de pieken in boekingen en reizen wachten fixes op het volgende venster, en elke release heeft meerdere teams online nodig. Wij bouwen één pipeline per releaseflow die elke engineer in uw team kan starten, met controles na elke stap en een geteste rollback.

  • Uw tools blijven
Illustratie: één releaseflow na een Self-Service Release Build.

Wat releases ophoudt

Waar releases in de reisbranche op wachten

  1. Het einde van de freeze

    Rond de piek liggen releases wekenlang stil, terwijl het team blijft mergen. De eerste release na de freeze bevat alles, en als er iets breekt, is het moeilijk te zien welke wijziging het was.

  2. Meerdere teams in één call

    Een wijziging in het boekingsproces kan zoeken, betalingen en koppelingen met leveranciers raken. Dus draait de release in een call waarin iemand van elk team paraat staat, en gaat hij pas live als iedereen erbij kan zijn.

  3. Het volgende releasevenster

    Een fix die dinsdag klaar is, wacht op het volgende venster, en reizigers lopen tot die tijd tegen de bug aan. Of hij gaat onder druk met de hand live, met een rollback die niemand heeft geprobeerd.

Wat er verandert

Uw freezekalender blijft. De releases eromheen veranderen.

U bepaalt zelf wanneer u een freeze instelt. Een Build verandert hoe elke release verloopt, binnen de freeze en daarbuiten.

Bekijk de Build
  • NuWeken aan wijzigingen gaan na de freeze in één release live, met de hand, stap voor stap.

    Na een BuildElke engineer in het team start een release vanuit één pipeline per releaseflow, zonder op een ander team te wachten.

  • NuDe release draait in een call, met meerdere teams online om hun deel te doen en te vragen hoe ver het is.

    Na een BuildOverdrachten worden stappen in de pipeline, en statusberichten in chat of in het ticket beantwoorden “Waar staat de release nu?”

  • NuEen fix wacht op het volgende venster, of gaat met de hand live met een rollback die niemand heeft geprobeerd.

    Na een BuildElke stap controleert zijn eigen resultaat, en de rollback is getest vóór de go-live.

  • NuEen uitzondering op de freeze wordt in een aparte thread goedgekeurd, en het overzicht van wat er live ging, wordt later bij elkaar gezocht.

    Na een BuildDe goedkeuringen die uw beleid vereist, draaien binnen de pipeline, en elke productierelease laat een change record achter dat uw change board kan controleren.

Resultaten

Hetzelfde releasewerk bij Nike en ASML

Resultaten van releasewerk bij Nike (retail) en ASML (halfgeleiders), waar handmatige release- en integratiestappen self-service pipelines werden.

Nike (retail)VoorNa
Upgrades van winkelserversvijf teams, met de handéén self-service pipeline
Upgradetijd, per server6 tot 8 uurongeveer 3 uur
Servers tegelijk28
Testbuild naar staging-apparaten5 tot 10 minutenongeveer 1,5 minuut
Overdrachten per deployment1, plus het wachten eropgeen
Engineeringtijd terug600+ uur per jaar
Lees de Nike-case

ASML (halfgeleiders)

Integratiestappen die met de hand gingen, werden één self-service CI-pipeline

Gestandaardiseerd voor meerdere teams, met één overzicht in Python en SQL van testresultaten voor besluiten over release-gereedheid.

“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+engineeringuren per jaar

Lees de ASML-case

Waar u begint

Begin bij uw laatste release

De gratis Release Check laat in minder dan 5 minuten zien waar de tijd van uw laatste release naartoe ging en wat dat per jaar kost, zonder gesprek.

Contact

Praat met de engineer

Plan 30 minuten en neem uw laatste release mee, of stuur een bericht. U spreekt Mateusz rechtstreeks.

Mateusz UlasOprichter en platform engineer

    Stuur ons een bericht

    Laat een bericht achter, dan nemen wij spoedig contact met u op.

    Lees in onze privacyverklaring hoe wij met uw gegevens omgaan.