'Java EE is een standaard, dus het kan niet zo moeilijk zijn', is een veelgezegde zin van ontwikkelaars. Daaruit kunnen we opmaken dat deployments vaak worden onderschat. En dat terwijl het deploymentproces een kritisch proces is, waarbij meerdere afdelingen en expertises zijn betrokken. Wanneer het verkeerd aangepakt wordt, kan het ook een langdurig, duur en onvoorspelbaar proces worden. Als aanleiding hiervoor zijn een aantal zaken aan te wijzen, die wij de ’valkuilen van deployment’ noemen.
Ten eerste worden deployments vaak niet meegenomen bij het ontwerp van een infrastructuur en middleware. Voor het verhogen van de performance of het beperken van de licentiekosten is wel oog (denk hierbij aan het opsplitsen van de middleware inrichting in veel verschillende componenten). Maar een infrastructuurinrichting die deployment lastig of langdurig maakt, kan hoge verborgen kosten met zich meebrengen. Denk hierbij aan de grotere inspanning die ervoor nodig is of de kosten van mislukte deployments.
Prioriteitenlijst
Naast de systeembeheerders hebben ook ontwikkelaars geen oog voor deployment wanneer zij applicaties ontwerpen en ontwikkelen. Het draaiend krijgen van software in een ontwikkelomgeving is vaak simpel, maar installeren in een productieomgeving is andere koek. Vreemd genoeg staat deployment niet hoog op de prioriteitenlijst. Daardoor kan de software architectuur een eenvoudige deployment van de applicatie in de weg staan, bijvoorbeeld door de opsplitsing in vele afzonderlijke deploymentonderdelen. Daarnaast komt het installeren pas in een later, maar zeer cruciaal, stadium van het project ter sprake. 'Dat komt later wel', is de gedachte. Er ligt dan al druk op het project en dat maakt een mislukte deployment een niet welkome gast.
Een andere valkuil is het niet ontwikkelen in een representatieve middleware-omgeving. Het ontwikkelen van de software gebeurt meestal op een simpele desktopomgeving, terwijl de uiteindelijke applicatie moet draaien op meerdere machines in een complexe omgeving. Dat betekent dat bij de ontwikkeling rekening wordt gehouden met een andere versie en met andere componenten. De uiteindelijke code gaat dan niet werken. Het installeren van Office geschiet met één druk op de knop, maar dat geldt helaas niet voor applicaties in een enterprise omgeving. Ontwikkelaars zouden meer rekening moeten houden met de omgeving waar hun software uiteindelijk in komt te draaien. En welke versies van JDK's, middleware et cetera daar worden gebruikt.
Dikke handleidingen
Sommige organisaties vertrouwen in het deploymentproces op dikke handleidingen met eindeloze omschrijvingen van stappen die moeten worden genomen. Dit is een vervelende manier van werken en daardoor worden handleidingen bijna nooit gelezen en toegepast. En ze worden al zeker niet bijgewerkt als er iets veranderd. Daarnaast worden vaak niet alle requirements gedocumenteerd. Het is beter om te vertrouwen op best practices en standaard features. Verkies daarom automatisering boven documentatie.
Maar al te vaak worden middleware-omgevingen niet gesynchroniseerd met andere omgevingen. Testomgevingen beschikken niet over een loadbalancer, productieomgevingen hebben grotere clusters en acceptatieomgevingen hebben weer kleinere clusters. Een succesvolle deployment op de ene omgeving leidt daardoor niet automatisch tot een succesvolle deployment op de andere omgeving. De deployments worden onvoorspelbaar en daardoor is synchronisatie noodzaak.
Dit probleem is overigens niet gemakkelijk op te lossen, wegens licentiekwesties. Virtualisatie kan een optie zijn. Zorg er in ieder geval voor dat handmatige aanpassingen in de middleware-omgeving niet mogelijk zijn.
Gebrek aan overzicht
Het ontbreekt organisaties aan een overzicht van de configuraties van de middleware. Daarnaast hebben zij geen zicht op de verschillende systemen in de organisatie en wat er moet gebeuren voor een deployment. Zo moeten bepaalde firewalls opengezet worden of moet er ook geïnstalleerd worden op een http-server. Dit soort zaken worden vaak vergeten. Daarom is het noodzaak om zoveel mogelijk informatie te verzamelen over welke systemen in huis zijn. Zo niet, dan bestaat het risico dat men met onjuiste aannames werkt.
Het testen van software is common practice, maar het testen van de deployment van die software gebeurt meestal niet. En dat is vreemd want deployments zijn een belangrijk onderdeel van de lifecycle van een applicatie. Het makkelijk en zonder uitval kunnen deployen van nieuwe versies van de software is een belangrijke requirement van enterprise software. Daarom is het belangrijk om het deploymentproces zelf goed te testen en te hertesten op een representatieve omgeving, bijvoorbeeld de acceptatieomgeving. Daarbij is het belangrijk om niet alleen te testen of het proces iedere keer succesvol afgerond kan worden maar ook of de applicatie dan steeds correct draait.
Automatiseren
Veel middlewarebeheerders denken dat het niet mogelijk is het deploymentproces volledig te automatiseren. Zij blijven werken met de vele foute en onvoorspelbare handmatige deployments. Zij blijven afhankelijk van ontwikkelaars met specifieke kennis, die ondertussen vaak op een nieuw project ingezet zijn. Of zij hebben te maken met de nadelige effecten van een gedeeltelijke automatiseringslag ('Welk script moet ik wanneer runnen?'). Het is wel degelijk mogelijk om het deploymentproces te automatiseren. En dit zorgt ervoor dat het deploymentproces niet het ondergeschoven kindje wordt!
Vincent Partington is chief technical officer bij Xebialabs
