Nike
Retail · 900+ winkelsUpgrades van winkelservers werden één self-service pipeline
Upgrades liepen met de hand via vijf teams, twee servers tegelijk.
Upgradetijd per server
Servers tegelijk veilig geüpgraded
Automatisering van de softwareontwikkelcyclus
Wij zoeken uit waar de tijd naartoe gaat, berekenen wat dat per jaar kost en automatiseren de flows die het meest kosten. In uw tools en uw repositories, overgedragen aan uw team.
Waar de tijd naartoe gaat
De rest is wachten, en op plekken als deze stapelt het zich op.
Iemand voert de release uit volgens een checklist en houdt elke stap in de gaten. Dat kost uren aandacht, en één gemiste stap betekent een mislukte release.
Build, test, goedkeuring en deploy liggen bij verschillende teams. Elke overdracht is een wachtrij, en niemand is eigenaar van de hele release.
De hele procedure zit bij een of twee mensen. Als zij het druk hebben of afwezig zijn, wacht de release op hen.
Waar releases in uw sector wachten
Resultaten
Nike
Retail · 900+ winkelsUpgrades liepen met de hand via vijf teams, twee servers tegelijk.
Upgradetijd per server
Servers tegelijk veilig geüpgraded
ASML
Halfgeleiders · lithografiesystemenVoor het domein Stage Position Measurement, waar integratiesnelheid en betrouwbare tests de levering bepalen.
“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.”
“It was a pleasure for the team and me to work with Mateusz and I wouldn’t hesitate to hire him again.”
Release Bottleneck Review
In een Release Bottleneck Review kiest u bij de kick-off over welk besluit het gaat. Wij meten uw releaseflows in uw tools en met de mensen die ze uitvoeren, en berekenen voor elke optie de kosten per jaar.
Wat u volgend jaar als eerste oplost, en wat dat waard is.
Of u mensen aanneemt voor platformwerk of het werk overbodig maakt.
Of u uw CI/CD-tooling houdt, samenvoegt of vervangt.
Wat u verandert nu AI-tools meer wijzigingen in hetzelfde review- en releaseproces sturen.
Waarom dat laatste nu telt: in een studie uit 2025 onder meer dan 10.000 developers zag Faros AI dat teams met een hoge AI-adoptie 98% meer pull requests mergeden, terwijl de reviewtijd met 91% steeg en de delivery op bedrijfsniveau niet verbeterde.
Wat u meekrijgt
Twee wekenVan uw team: leestoegang of exports, vier tot acht gesprekken van 30 tot 45 minuten, en een sponsor bij de kick-off en het beslisgesprek.
Bekijk de ReviewZo begint u
Begin gratis, betaal daarna voor een onderbouwd besluit en dan voor de Build. Alle prijzen zijn openbaar, en de helft van elk projectbedrag wordt betaald bij acceptatie.
Schatten
Wat uw laatste release per jaar kost, waar de tijd naartoe ging, en drie verbeteringen. Op basis van uw eigen antwoorden.
Gratis · 5 minuten
11 vragen, geen gesprek
Doe de Release CheckMeten
Dezelfde cijfers, gemeten in uw systemen, en een besluit met de kosten erbij.
Vanaf € 3.500 · Twee weken
Leestoegang en vier tot acht korte gesprekken
Bekijk de ReviewAutomatiseren
Pipelines die uw team zelf start en terugdraait, geaccepteerd op basis van criteria die u tekent voordat het werk begint.
Vanaf € 14.500 · 4 tot 8 weken
Een eigenaar per releaseflow, en 3 tot 4 uur per week van één engineer
Bekijk de BuildOnderhouden
Upgrades, patches en dependency-updates, met een maandrapport en review.
Vanaf € 2.500 per maand
Optioneel. Eerste drie maanden vast, daarna maandelijks.
Bekijk Release CarePaid on green
De tweede helft van het bedrag voor een Build is verschuldigd wanneer elk acceptatiecriterium in uw omgeving gehaald is. Wordt een criterium niet gehaald, dan werken we zonder extra kosten door tot het wel gehaald is.
In een Build
Een Self-Service Release Build maakt van elke handmatige stap een fase die zijn eigen resultaat controleert. De pipeline is geschreven in de tool die u al gebruikt en staat in uw repository. Elke engineer in het team kan een release starten en terugdraaien.
checkout-service release 2.14
Run #418 · main · gestart door een developer
BezigWacht op goedkeuringLive in productieTeruggedraaid naar 2.13
Probeer het zelf: start een release, keur hem goed als change board, of laat de smoketests falen en kijk hoe de rollback verloopt.
Smoketests24s
8 of 8 smoke checks passed
Live in production
Elke wijziging wordt op dezelfde manier gebouwd en getest, en de tragere controles draaien parallel.
De release gaat eerst naar een omgeving die overeenkomt met productie, en elke fase controleert zijn eigen resultaat.
De mensen die uw beleid aanwijst, keuren de release in de pipeline goed, en het change record wordt meteen vastgelegd.
Na elke deploy draaien controles, en de rollback naar de vorige versie is getest vóór de go-live.
Jenkinsfile
pipeline {
agent any
stages {
stage('Build') {
steps { sh 'make build' }
}
stage('Tests') {
parallel {
stage('Unit tests') {
steps { sh 'make test' }
}
stage('Security scan') {
steps { sh 'make scan' }
}
}
}
stage('Deploy to staging') {
steps { sh './deploy.sh staging' }
}
stage('Approval') {
steps {
input message: 'Go to production?',
submitter: 'change-board'
}
}
stage('Deploy to production') {
steps { sh './deploy.sh production' }
}
}
post { always { sh './change-record.sh' } }
}
.github/workflows/release.yml
name: release
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: make build test scan
staging:
needs: build
runs-on: ubuntu-latest
environment: staging
steps:
- uses: actions/checkout@v4
- run: ./deploy.sh staging
production:
needs: staging
runs-on: ubuntu-latest
# required reviewers: change board
environment: production
steps:
- uses: actions/checkout@v4
- run: ./deploy.sh production
- run: ./change-record.sh
environments.tf
# One module for staging and production,
# so staging mirrors production.
module "staging" {
source = "./modules/service"
name = "checkout-service"
environment = "staging"
instance_type = "t3.medium"
min_size = 2
}
module "production" {
source = "./modules/service"
name = "checkout-service"
environment = "production"
instance_type = "t3.medium"
min_size = 4
}
Controleerbaar gebouwd
Elke Build laat bewijs achter dat uw organisatie kan inzien zonder het ons te vragen.
U tekent de acceptatiecriteria voordat we gaan bouwen. Bijvoorbeeld: rollback naar de vorige versie in minder dan Y minuten, getest.
De goedkeuringen die uw beleid vereist, draaien binnen de pipeline, niet in een overleg of een chatthread.
Goedkeuring, auteur, commit en deploy bij elke productierelease, op één plek op te vragen.
Gesigneerde artifacts en een software bill of materials bij elke release, plus een auditexport.
Gebouwd in uw repositories en accounts, met tools die u al gebruikt. Geen ES.nl-software en geen licentie.
Een runbook, training en een pipeline die uw team al zelf heeft aangepast. Of laat het onderhoud over aan Release Care.
releaseséén bericht per release
Releasepipeline09:42bewerkt 10:01
checkout-service 2.14, gestart door een developer
BezigWacht op goedkeuringLiveRollback getestChange record CHG-2041
Vragen
Hier de korte antwoorden. Elke stap heeft een eigen pagina met de details.
Eén pad van merge naar productie: één pipeline en één manier van deployen. Services die via dezelfde pipeline worden uitgerold, tellen als één flow. Een webapp en de bijbehorende API die samen worden gedeployd, zijn één flow; een iOS-app die via de App Store wordt uitgebracht, is een andere.
Ja. In de eerste week van de Build meten we uw releaseflows en leggen we de acceptatiecriteria vast. U tekent ze voordat we gaan bouwen.
Nee. De blauwdruk uit de Review is van u. Gebruik hem met ons, met uw eigen team of met iemand anders.
Dan werken we zonder extra kosten door tot het wel gehaald is. De tweede helft van het bedrag voor de Build is pas verschuldigd wanneer elk criterium in uw omgeving gehaald is.
Pipelines worden gebouwd in de tool die u gebruikt. Valt een tool buiten de stack waarmee wij zelf werken, dan wordt die flow gebouwd door een partner-engineer die dagelijks met die tool werkt, en reviewen wij elke wijziging.
Leestoegang of exports, onder NDA. Exports worden na het beslisgesprek verwijderd.
Wij ontwerpen het, bouwen de kern en reviewen elke wijziging. Partner-engineers werken onder dezelfde NDA. U werkt rechtstreeks samen met Mateusz, de engineer achter de resultaten bij Nike en ASML.
Waar u begint
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
Plan 30 minuten en neem uw laatste release mee, of stuur een bericht. U spreekt Mateusz rechtstreeks.