Automatisering van de softwareontwikkelcyclus

Uw releases verliezen tijd aan handmatig werk, overdrachten, goedkeuringsmails, flaky tests, testomgevingen, kennis in één hoofd of releasevensters.

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.

  • Release Check: 5 minuten, geen gesprek nodig
  • Gebouwd in uw eigen repositories en accounts

Waar de tijd naartoe gaat

Een release duurt dagen. Het werk duurt uren.

De rest is wachten, en op plekken als deze stapelt het zich op.

  1. 01

    Handmatige stappen

    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.

  2. 02

    Overdrachten tussen teams

    Build, test, goedkeuring en deploy liggen bij verschillende teams. Elke overdracht is een wachtrij, en niemand is eigenaar van de hele release.

  3. 03

    Die ene persoon die weet hoe het moet

    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

Wat er veranderde bij Nike en ASML

Lees de cases
  • 600+engineeringuren per jaar terug bij Nike
  • 300+engineeringuren per jaar terug bij ASML
  • 900+Nike-winkels op één self-service upgradepipeline

Nike

Retail · 900+ winkels

Upgrades 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

Lees de Nike-case

ASML

Halfgeleiders · lithografiesystemen

Handmatige integratie werd self-service CI

Voor het domein Stage Position Measurement, waar integratiesnelheid en betrouwbare tests de levering bepalen.

  • IntegratiestappenVoor: met de hand uitgevoerdNa: één self-service CI-pipeline
  • Release-gereedheidVoor: geen centrale plek om die te beoordelenNa: één rapportageoverzicht van testresultaten van productiemachines
  • CI over teams heenVoor: niet gestandaardiseerdNa: gestandaardiseerde CI-flows voor meerdere teams
Lees de ASML-case
“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
“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

Release Bottleneck Review

In twee weken naar één onderbouwd releasebesluit

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.

  1. Wat u volgend jaar als eerste oplost, en wat dat waard is.

  2. Of u mensen aanneemt voor platformwerk of het werk overbodig maakt.

  3. Of u uw CI/CD-tooling houdt, samenvoegt of vervangt.

  4. 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 weken
  • Uw cijfers per releaseflow, gemeten in uw tools: doorlooptijd, uren handwerk, wachttijd, overdrachten, mislukte releases en hersteltijd.
  • Gerangschikte verbeteringen, elk met uren per jaar, kosten per jaar, inspanning en eigenaar.
  • Een besluitmemo van twee pagina’s die u kunt doorsturen naar uw CEO of CFO.
  • Een blauwdruk voor de Build, met scope, acceptatiecriteria en een vaste prijs. Gebruik hem met ons, met uw eigen team of met iemand anders.
Prijs
Vanaf € 3.500, één releaseflow
Hoe u betaalt
De helft bij ondertekening, de helft bij acceptatie

Van 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 Review

Zo begint u

Schatten. Meten. Automatiseren.

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.

Elke stap in detail
  1. Schatten

    Release Check

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

    Release Bottleneck Review

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

    Self-Service Release Build

    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 Build
  4. Onderhouden

    Release Care

    Upgrades, patches en dependency-updates, met een maandrapport en review.

    Vanaf € 2.500 per maand

    Optioneel. Eerste drie maanden vast, daarna maandelijks.

    Bekijk Release Care

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

  • Wat u voor de Review heeft betaald, gaat af van de prijs van een Build die binnen 60 dagen na het beslisgesprek wordt getekend.
  • Prijzen zijn exclusief btw.

In een Build

Eén pipeline per releaseflow, gestart door uw team

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.

  1. Rollback getest

Smoketests24s

8 of 8 smoke checks passed
Live in production
Illustratie: één releaseflow na een Self-Service Release Build. Klik op een fase om de logs te bekijken.
  • Build en tests

    Elke wijziging wordt op dezelfde manier gebouwd en getest, en de tragere controles draaien parallel.

  • Staging die overeenkomt met productie

    De release gaat eerst naar een omgeving die overeenkomt met productie, en elke fase controleert zijn eigen resultaat.

  • Goedkeuring binnen de pipeline

    De mensen die uw beleid aanwijst, keuren de release in de pipeline goed, en het change record wordt meteen vastgelegd.

  • Productie, met een geteste weg terug

    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
}
Ingekorte voorbeelden. Elke Build wordt geschreven in de tool die uw team al gebruikt.

Controleerbaar gebouwd

Wat uw change board, security en finance kunnen controleren

Elke Build laat bewijs achter dat uw organisatie kan inzien zonder het ons te vragen.

  • Criteria vooraf getekend

    U tekent de acceptatiecriteria voordat we gaan bouwen. Bijvoorbeeld: rollback naar de vorige versie in minder dan Y minuten, getest.

  • Goedkeuringen in de pipeline

    De goedkeuringen die uw beleid vereist, draaien binnen de pipeline, niet in een overleg of een chatthread.

  • Een change record per release

    Goedkeuring, auteur, commit en deploy bij elke productierelease, op één plek op te vragen.

  • Gesigneerde artifacts en een SBOM

    Gesigneerde artifacts en een software bill of materials bij elke release, plus een auditexport.

  • Geen lock-in

    Gebouwd in uw repositories en accounts, met tools die u al gebruikt. Geen ES.nl-software en geen licentie.

  • Een team dat het zelf kan aanpassen

    Een runbook, training en een pipeline die uw team al zelf heeft aangepast. Of laat het onderhoud over aan Release Care.

Illustratie: één statusbericht per release, bijgewerkt door de pipeline.

Vragen

Wat engineeringleiders als eerste vragen

Hier de korte antwoorden. Elke stap heeft een eigen pagina met de details.

Zo werken de vier stappen

Wat is een releaseflow?

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.

Kunnen we beginnen zonder Review?

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.

Moeten we de Build bij u kopen?

Nee. De blauwdruk uit de Review is van u. Gebruik hem met ons, met uw eigen team of met iemand anders.

Wat als een criterium niet gehaald wordt?

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.

We gebruiken geen Jenkins.

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.

Zijn onze gegevens veilig?

Leestoegang of exports, onder NDA. Exports worden na het beslisgesprek verwijderd.

Wie doet het werk?

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

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.