Wie een partner zoekt voor maatwerksoftware, vergelijkt al snel portfolio, technologie en prijs. Hoe een bureau zijn werk bouwt, test en live zet, blijft meestal buiten beeld. Jammer, want juist die werkwijze bepaalt hoe snel je aanpassingen krijgt, hoe vaak er iets misgaat en hoe lang een storing duurt.
Die werkwijze heet DevOps: ontwikkelen en beheren als een geheel, met zo veel mogelijk geautomatiseerd. Je hoeft er als opdrachtgever niet zelf in te kunnen werken. Je wilt wel kunnen beoordelen of een partner het op orde heeft, want daar merk je jarenlang de gevolgen van.
Kleine releases in plaats van grote sprongen
De kern is continuous integration en continuous delivery, kortweg CI/CD. Elke aanpassing die een ontwikkelaar aanlevert, wordt samengevoegd met het bestaande werk, automatisch getest en klaargezet voor livegang. Zo ontstaan veel kleine releases in plaats van een paar grote per jaar.
Voor jou betekent dat minder risico. Een kleine wijziging die misgaat, is snel gevonden en snel teruggedraaid. Een release met een half jaar werk erin die misgaat, legt een afdeling dagen stil. Vraag een partner daarom niet alleen wat hij oplevert, maar ook hoe vaak.
Geautomatiseerde tests als vangnet
Bij een volwassen team draait bij elke wijziging een reeks geautomatiseerde tests: doet de nieuwe functie wat hij moet doen, en werkt alles wat er al stond nog? Code die de tests niet doorstaat, gaat niet live. Juist voor maatwerk is dat vangnet onmisbaar: jouw applicatie draait nergens anders, dus een fout wordt niet eerst bij duizend andere gebruikers van een standaardpakket ontdekt.
Monitoring die problemen eerder ziet dan jij
Een partner met monitoring op orde weet van een storing voordat jij belt. Reactietijden, foutmeldingen en servergebruik worden doorlopend gemeten, en zodra iets uit de pas loopt, krijgt het team vanzelf een melding. Zo worden trage schermen en oplopende foutpercentages een trend die je ziet aankomen, in plaats van een klacht van je eigen medewerkers.
Omgevingen die opnieuw op te bouwen zijn
Minder zichtbaar, wel wezenlijk: bij volwassen DevOps staat ook de serverinrichting in code beschreven. Valt een server uit of is er een extra omgeving nodig, dan wordt die machinaal opgebouwd, niet uit het geheugen van een beheerder. Daar hoort een terugvalplan bij: elke release moet binnen minuten terug te draaien zijn, en dat wordt geoefend, niet alleen beloofd.
Zo toets je een partner aan tafel
Je hoeft geen pipeline te kunnen lezen om de volwassenheid van een team te peilen. Een paar vragen zeggen genoeg:
- Hoe vaak zetten jullie wijzigingen live, en hoeveel handwerk komt daarbij kijken?
- Wat gebeurt er automatisch op het moment dat een ontwikkelaar code aanlevert?
- Hoe merken jullie een storing op, en hoe snel staat een vorige versie terug?
- Kunnen jullie de productieomgeving vanaf nul opnieuw opbouwen?
Een partner die hierop concreet antwoordt, met voorbeelden uit lopende projecten, heeft zijn werkwijze op orde. Blijft het antwoord vaag of hangt alles aan een enkele beheerder, dan weet je ook genoeg. Meer gespreksstof vind je in de vragen die je stelt voordat je software op maat laat ontwikkelen.
Bij ons zijn deze practices de standaardinrichting van elk project, geen optie op de offerte. Draait je applicatie nu bij een partij waar elke release spannend is? Ook bestaande software brengen we naar dit niveau; hoe dat in zijn werk gaat, lees je bij doorontwikkeling en beheer.