Drie ingrediënten voor geweldige softwarereleases

Op een bepaald moment in je carrière, als dat nog niet is gebeurd, ben je betrokken bij een monolithische softwarerelease. Dat wil zeggen, een softwarerelease met koppige bugs en onderlinge afhankelijkheden, en een die het hele team de klok rond aan het werk zet. Om nog maar te zwijgen van het feit dat als het eenmaal in productie gaat, het waarschijnlijk verschillende patches nodig heeft.

Verzendcode – de softwarerelease – is een sterke meting van wendbaarheid voor softwareontwikkelaars. Elke poging om planning, codering en testen sneller te maken is voor niets geweest als de release geen soepel proces is. Daarom kiezen agile- en DevOps-teams voor automatisering, brengen ze ontwikkeling en operations vroeg in de ontwikkelingsfase samen, beoefenen ze continue integratie en pakken ze defecten onmiddellijk aan.

Ervoor zorgen dat de code altijd klaar is voor release is hét kenmerk van agile ontwikkelen. Al je geïmplementeerde lean planning en iteratieve ontwikkeling is voor niets geweest als je je code niet kunt leveren op het moment dat je wilt.

Bij elk softwareprogramma is het goed om software eenvoudig en vaak te releasen. Een team kan een release een natuurlijk onderdeel van hun agile cultuur maken door een modulaire architectuur te bouwen (of hierin in te passen). In plaats van één grote toepassing te hebben (zoals de hierboven genoemde monoliet), moduleer je deze al vroeg in het programma in verschillende stukken. Groepeer vergelijkbare functies in kleinere applicaties of componenten en zorg voor duidelijke API-contracten tussen elk van de applicaties en componenten. Deze API's kunnen bij elke build automatisch worden getest om compatibiliteit te garanderen en het risico in de softwarerelease te verminderen.

Een modulaire architectuur betekent dat je niet de volledige softwarestack in een bigbangachtige release hoeft uit te brengen, en de API-contracten maken het eenvoudig om componenten bij te werken en compatibiliteit tussen versies te garanderen. Kortom, modulaire softwarereleases vereisen minder bewegende onderdelen. En dat vertaalt zich in eenvoudigere releases.

Softwareontwikkeling gebeurt zelden in een vacuüm. Bij geweldige softwareontwikkeling is het hele team betrokken, van productbeheer tot operations. Het operationele team is bijvoorbeeld een belangrijke partner bij het leveren van software aan de productie, omdat ze helpen de software bij de eindgebruikers te brengen.

Ontwikkelingsteams kunnen operationele teams beter op de hoogte houden en versterken met behulp van deze twee technieken:

• Maak de stuklijst voor elke softwarerelease duidelijk. Operations-teams hebben niet altijd hetzelfde contextniveau rond de release als het ontwikkelingsteam.
• Zorg ervoor dat alle issues die in de release opgelost zijn, een link bevatten naar je issuetracker en broncontrolesysteem. Zo beschikt het operationele team over alle context wanneer er problemen ontstaan tijdens de implementatie.
• Soms verschijnen er problemen wanneer de code van de ontwikkelomgeving naar de stagingomgeving gepusht wordt. Benoem deze problemen, omdat ze tijdens de productiepush weer kunnen opduiken.
• Implementatieproblemen zijn onvermijdelijk, dus geef het operationele team altijd een duidelijk escalatiepad om ze soepel op te lossen.

Operationele teams kunnen hun collega's op de afdeling ontwikkeling helpen met deze suggesties:

• Wanneer zich problemen voordoen bij productie, neem dan de tijd om de onderliggende oorzaken en oplossingen te begrijpen. Zo kunnen ze in de toekomst worden vermeden (of in ieder geval handiger worden aangepakt).
• Migreer configuratiegegevens van productie terug naar staging- en ontwikkelomgevingen om configuratieverschillen te voorkomen.

Terwijl code migreert van ontwikkeling naar stagen en daarna naar productie, migreren codeconfiguraties en gebruikersgegevens precies de andere kant op: van productie naar stagen naar ontwikkeling. Door die bidirectionele relatie helpt de ontwikkelingsomgeving de productieomgeving nauw te modelleren. Dit betekent minder bugs en verrassingen op de releasedag.

Automatiseren! Automatiseren! Automatiseren!

Een softwarerelease automatiseren is de beste manier om een releasecultuur te verbeteren. Als de softwarerelease momenteel niet is geautomatiseerd, begin dan bij het automatiseren van de softwarerelease naar een testomgeving. Zodra iedereen ziet hoe eenvoudig het is, is de natuurlijke stap om ook productie-implementaties te automatiseren.

Als releases moeilijk zijn, maak er dan een gewoonte van om software regelmatig te releasen, ook al is het maar om te stagen. Het ontwikkelingsteam de pijnpunten van een release te laten voelen, zal innovatie inspireren zodat de release eenvoudiger (en geautomatiseerder) kan worden gemaakt.

Geautomatiseerd testen en continue integratie zijn belangrijke disciplines die geweldige releases mogelijk maken. Zorg ervoor dat de bouwtijden en testtijden zo kort mogelijk zijn en vergeet niet dat builds die eenvoudig te valideren zijn, gemakkelijker kunnen worden vrijgegeven. Dat komt omdat de validatiecyclus beter aansluit op het team.

Ervoor zorgen dat de code altijd klaar is voor release is hét kenmerk van agile ontwikkelen.

Als softwareontwikkelaars zou een softwarerelease het hoogtepunt van onze innovatiecyclus moeten zijn. We zien klanten reageren op de code die we hebben geschreven en feedback geven. Fijn! Door releases een natuurlijk onderdeel van je werkdag te maken, wordt het gemakkelijker om code in productie te nemen en te genieten van de voldoening bij het zeggen: "Dat is mijn code!"