woensdag 28 januari 2009

In SIT as in Heaven

Bij het in productie nemen van een informatiesysteem dat groter is dan pakweg een e-mailformuliertje voor de-slager-op-de-hoek ontkom je er niet aan: de SIT (system Integration Test) en de UAT (User Acceptence Test). Helaas wil onder druk van deadlines of beperkte budgetten een écht goede test(-omgeving) er nogal eens bij inschieten. Ware ontwikkelaars en projectmanagers weten echter dat je niet zonder SIT en UAT kunt en zorgen er dan ook voor dat de omgeving voor deze tests optimaal is ingericht. Waar moet je nu in elk geval aan denken bij het (laten) inrichten van een goede SIT- en UAT-omgeving?

Het allerbelangrijkste punt, waaraan veel andere zaken slechts een element hoeven bij te dragen, is in één zin uit te drukken: Bouw Productie Exact Na In SIT (B-PENISIT, een handig ezelsbruggetje!).

Het klinkt eenvoudig, maar toch zijn er nogal wat aandachtspunten voordat je met een gerust hart kunt zeggen dat je er alles aan hebt gedaan om straks in Productie/Live niet tegen verrassingen aan te lopen. Al die aandachtspunten dragen slechts bij aan B-PENISIT, maar B-PENISIT heeft ook weer een uiteindelijk, finaal einddoel. Dat einddoel bestaat uit het rustig kunnen slapen tijdens de nacht na een go-live (zonder pizza knagend op kantoor te zitten stressen), of, voor die verdraaide go-lives op vrijdag, het kunnen genieten van je weekeinde (zonder dat de directie je komt verwennen met ontbijtjes op kantoor om toch nog "iets" te kunnen bijdragen aan de geruïneerde zater- en zondagen van je team).

Hierna volgen tien, tijdens lange jaren, naar aanleiding van steeds weer andere Ultieme Ellendige Situaties verzamelde, aandachtspunten voor het nastreven van B-PENISIT. Ze zullen niet allemaal op elk project van toepassing zijn, maar het helpt zeker om ze door te lezen, en een enkeling grinnikend te herkennen. Vrees de dag dat je live gaat met twijfels over één van de items op deze lijst!

1. Deploy op SIT/UAT op de zelfde manier als in productie.

Ga je straks FTPen naar productie? FTP dan ook naar UAT. Je zult de eerste niet zijn die ontdekt dat je FTP-server files in stukjes knipt. Of jpgs uiters verdacht vindt. Deploy je straks in productie met EAR files? Dan doe je dat ook in UAT, want voor je het weet blijkt de EAR-depolyer van productie met vakantie te zijn.

2. Gebruik domeinen

In productie draai je straks vast op de een of andere fraaie duurbetaalde domeinnaam. Gebruik ook een domeinnaam in SIT/UAT! Testen met alleen een IP-adres geeft namelijk in meer dan genoeg situaties heel andere problemen met je deployment configuratie. Idealiter draai je in prodctie op www..nl, en in SIT/UAT op test..nl. Gebruik je in productie straks meerdere domeinen? Doe dat dan ook in UAT, want je zult zien, die cross-domain-scriping issues zijn afkomstig uit de zwavelige krochten van de hel!

3. Vul de database

Leuk, dat testen met 10 ideale records in de database, terwijl je straks in productie tegen 1001 wazige rommelrecords moet draaien. Erg nuttig is dat echter niet. Zorg dat je SIT/UAT database minimaal 10% van productie bevat en alle denkbare varianten omvat. Idealiter haal je regelmatig productiedata over naar test en scramble je daarbij velden als e-mail en wachtwoordhashes om Test-naar-Productie vermenging te voorkomen.

4. Configureer autheticatie, authorisatie, als in productie

Gebruik je straks Windows Domein Authenticatie voor een batch-procesje? Of misschien een aantal speciaal geconfigureerde SQL Server-accounts? Kies dan niet voor de makkelijke weg om in SIT/UAT alles als het "SA"-account te laten draaien. Configureer daar ook gewoon alle rollen, users en rechten en zet die later met een tool als X-SQL over naar productie. Minder handwerk, minder kans op fouten!

5. Produceer je Test en Productie deployments met één mechanisme

Zonder handwerk achteraf! Gebruik één Ant-script dat beide deployments (Wars, Ears, Jars) steeds in één run maakt, of gebruik een mooi Maven-achtig systeem dat je collega Jan-Willem (of equivalte getalenteerde collega) heeft bedacht hiervoor. In elk geval wil je zeker weten dat wat goed gebuild is voor SIT/UAT, straks ook goed gebuild is voor productie.

6. Installeer SSL-certificaten als in productie

Ga je in productie gebruik maken van SSL? Installeer dat dan ook in UAT! Het liefst met echte certificaten; zo duur zijn die nu ook weer niet in vergelijking met een dag lang je hele front-end team cross-site-scripting-errors en SSL-bugs in Javascripts laten opsporen, die je in SIT/UAT zo had gevonden. Voor je DEV-omgeving kan een self-signed certificate al wonderen doen.

7. Tuig de 3rd party kerstboom op

Ga je straks interfacen met een 3rd party systeem? Zorg dan dat je daar ook in SIT/UAT zinnige requests tegen kunt doen. Heeft je external party geen SIT/UAT omgeving? Bouw dan, na een hoorbare zucht om zoveel onprofessionalisme, desnoods een eenvoudige simulator (voor webservices is dat een eitje!). Een niet met ijzeren regelmaat geteste interface werkt per definitie niet in productie, hoe vaak je alles ook na bent gelopen! Is een 3rd party systeem traag? Maak dan gebruik van de geneugten van Thread.sleep() in je stubs, zodat je simulator ook lekker traag is.

8. Batches horen er bij

Ga je straks in Productie dagelijks een batch draaien? Of elk uur wellicht? Richt die dan ook in in SIT/UAT en bekijk de log-files. Het is aan te raden om ze voor een runtime midden op de werkdag in te plannen, zodat je meteen, live in de log-files mee kunt kijken en niet later door 5 gigabyte data heen hoeft te Grep/Sed/WC/Regexen.

9. VMWare is your friend

Met VMWare is het oneindig veel eenvoudiger geworden om voor een redelijk betaalbare prijs elke productieserver een SIT/UAT equivalent te geven. Richt een lompe VMWare host server in, waarop je tientallen SIT/UAT servers kwijt kunt. Je zult er geen spijt van krijgen!

10 En de versienummers van Java, JBoss, SQL Server, Service Packs, etc etc?

Wat dacht je nu zelf?