Er is een gewoonte die veel schade aanricht. Even snel iets aanpassen op de live site. Een plugin bijwerken tussen twee afspraken door. Het gaat negen van de tien keer goed. Die tiende keer staat je website wit, midden op een werkdag, met bezoekers erop.
Dan ben je aan het repareren onder tijdsdruk. Dat is het slechtste moment om een oplossing te bedenken.
Voor VGO Garant werk ik daarom anders. Ik verzorgde daar het webdesign, de webteksten en de vindbaarheid, in opdracht van Leadmasters. Bij zo’n organisatie kijken meerdere mensen mee voordat iets naar buiten gaat.
Elke wijziging gaat eerst naar een kopie van de site. Daar bouw ik, daar test ik en daar kijkt de opdrachtgever mee. Pas als iedereen akkoord is, gaat het naar de live omgeving. Er is nooit een moment waarop een bezoeker een half afgemaakte pagina ziet.
Testen doe je op een kopie, niet op de site van je klant.
Wat betekent DTAP?
DTAP is een afkorting van vier omgevingen. Development, Testing, Acceptance en Production. In het Nederlands hoor je ook OTAP, met ontwikkel, test, acceptatie en productie.
Elke omgeving is een complete kopie van je website. Zelfde bestanden, zelfde database, andere plek. Een wijziging schuift van links naar rechts door die keten.
Development
De ontwikkelomgeving is waar gebouwd wordt. Vaak op de computer van de bouwer zelf. Hier mag alles kapot, want niemand anders kijkt mee.
Testing
De testomgeving is een kopie op een server. Hier controleer ik of alles werkt zoals bedoeld. Formulieren, betalingen, filters en inloggen.
Acceptance
Hier vindt de acceptatie door de klant plaats. Jij kijkt mee en geeft akkoord. Deze stap voorkomt dat er iets live gaat wat jij niet wilde.
Production
Dit is je echte website, de plek waar je bezoekers komen. Hier wordt niet gebouwd en niet geprobeerd.
Heeft een kleine website dit nodig?
Niet alle vier de stappen. Voor een bedrijfssite met een eigenaar is dat overdreven en te duur.
Maar de kern wel. Ik werk bij vrijwel elke klant met twee omgevingen: een kopie en de live site. Dat is de lichte variant en die vangt negentig procent van de risico’s af.
Wanneer ik altijd op een kopie werk
Bij het verhogen van de versie van je serversoftware.
Bij een grote update van je systeem of je thema.
Bij het toevoegen van een koppeling of betaalmethode.
Bij het opruimen van verouderde code, zie deprecated.
Bij elke wijziging in een webwinkel die geld raakt.
Kleine tekstwijzigingen doe ik gewoon live. Daar is het risico verwaarloosbaar en de omweg zonde van de tijd.
Waar het misgaat
De grootste valkuil is de kopie zichtbaar laten voor zoekmachines. Dan staat je site twee keer in de index en concurreren ze met elkaar. Zet een kopie daarom altijd op slot met een wachtwoord.
Een tweede valkuil zijn e-mails. Een testomgeving met een echte database kan bestelbevestigingen versturen naar echte klanten. Schakel het versturen van mail daar altijd uit.
De derde is terugzetten. wijzigingen testen heeft weinig zin als je de wijziging daarna handmatig overtypt op de live site. Dan test je iets anders dan wat er uiteindelijk komt te staan.
Hoe je het opzet
Goede webhosting maakt een kopie met een paar klikken. Je krijgt dan een afgeschermd webadres met een volledige kloon erop. Dat is de eenvoudigste route en meestal zit het bij je pakket.
Kan dat niet, dan doe je het met een plugin of met de hand. Meer over dat begrip lees je bij staging.
Wat je in beide gevallen doet, is vooraf een live gaan. Niet alleen van je bestanden, maar ook van je database. Zonder dat laatste kun je niet terug. Ik neem dit standaard mee in onderhoud. back-up maken is namelijk het verschil tussen een uurtje werk en een avond.
Wat je terugkrijgt voor die extra stap
Werken via een kopie kost per wijziging wat meer stappen. Daar staat rust tegenover. Je durft door te pakken, want er kijkt niemand mee.
Dat merk ik vooral bij grotere ingrepen. Een nieuwe versie proberen, een plugin vervangen of je CSS opruimen. Op een live site blijft zulk werk liggen omdat het risico te groot voelt.
Zo wordt onderhoud iets dat je doet in plaats van iets dat je uitstelt. Dat scheelt op termijn meer dan de omgeving kost.
Meer vragen over DTAP
Dit zijn de vragen die ik hierover het vaakst krijg. Ik werk ze los uit.
Wat betekent DTAP?
Heeft een kleine website een testomgeving nodig?
Wat is het verschil tussen staging en productie?
Hoe zet je een testomgeving op in WordPress?
Waarom mag je niet direct op de live site werken?
Wat kost een testomgeving?
Wat betekent DTAP?
Niet alle vier de stappen. Voor een bedrijfssite met een eigenaar is dat overdreven en te duur.
Maar de kern wel. Ik werk bij vrijwel elke klant met twee omgevingen: een kopie en de live site. Dat is de lichte variant en die vangt het grootste deel van de risico’s af.
Er zijn vijf momenten waarop ik altijd op een kopie werk. Bij het verhogen van de versie van je serversoftware, bij een grote update van je systeem of thema, bij een nieuwe koppeling of betaalmethode, bij het opruimen van verouderde code en bij elke wijziging in een webshop die geld raakt.
Kleine tekstwijzigingen doe ik gewoon rechtstreeks. Daar is het risico verwaarloosbaar en de omweg zonde van de tijd.
De vuistregel is simpel. Kan deze wijziging je site plat leggen of geld kosten? Dan gaat hij eerst langs een kopie.
Twijfel je bij een wijziging? Neem dan de veilige route. De extra tijd op een kopie is altijd minder dan de tijd die je kwijt bent als het live misgaat.
Heeft een kleine website een testomgeving nodig?
DTAP is een afkorting van vier omgevingen. Development, Testing, Acceptance en Production. In het Nederlands hoor je ook wel OTAP, met ontwikkel, test, acceptatie en productie.
Elke omgeving is een complete kopie van je website. Dezelfde bestanden, dezelfde database, maar op een andere plek. Een wijziging schuift van links naar rechts door die keten.
Development is waar gebouwd wordt, vaak op de computer van de bouwer. Daar mag alles kapot, want niemand kijkt mee.
Testing is een kopie op een server waar gecontroleerd wordt of alles werkt. Formulieren, betalingen, filters en inloggen.
Acceptance is waar jij meekijkt en akkoord geeft. Deze stap voorkomt dat er iets live gaat wat je niet wilde.
Production is je echte website. Daar wordt niet gebouwd en niet geprobeerd. Meer over de omgeving eronder lees je bij backend.
In de praktijk gebruiken kleine bedrijven zelden alle vier de stappen. Het gaat om de gedachte erachter: bouwen en testen doe je ergens anders dan waar je klanten kijken.
Waarom mag je niet direct op de live site werken?
Omdat het negen van de tien keer goed gaat. Precies daarom blijft de gewoonte bestaan.
Die tiende keer staat je website wit, midden op een werkdag, met bezoekers erop. Dan ben je aan het repareren onder tijdsdruk, en dat is het slechtste moment om een oplossing te bedenken.
Er is een tweede reden die minder zichtbaar is. Terwijl jij bouwt, ziet een bezoeker een half afgemaakte pagina. Een menu dat niet werkt of een formulier dat halverwege stopt. Die bezoeker komt niet terug en meldt het ook niet.
En er is een derde. Op een live site kun je niet rustig proberen. Je durft niet door te pakken, want er kijkt iemand mee. Daardoor blijven verbeteringen liggen.
Op een kopie kun je wel doorpakken. Gaat er iets stuk, dan zet je hem terug en begin je opnieuw.
Denk ook aan het moment van de dag. Ga nooit live vlak voor sluitingstijd of op vrijdagmiddag. Gaat er iets mis, dan wil je dezelfde dag nog kunnen ingrijpen.
Hoe zet je een testomgeving op in WordPress?
De eenvoudigste route loopt via je hostingpartij. Goede hosting maakt een kopie met een paar klikken. Je krijgt dan een afgeschermd webadres met een volledige kloon van je site erop.
Meestal zit dat gewoon bij je pakket. Kijk dus eerst in je klantenpaneel voordat je iets installeert. Meer daarover lees je bij webhosting.
Kan dat niet, dan doe je het met een plugin of met de hand. Dat werkt ook, maar het kost meer tijd en er gaat vaker iets mis bij het terugzetten.
Er zijn twee dingen die je daarna direct regelt. Zet de kopie op slot met een wachtwoord, zodat zoekmachines hem niet oppikken. Anders staat je site twee keer in de index.
En schakel het versturen van e-mail uit. Een testomgeving met een echte database kan bestelbevestigingen naar echte klanten sturen.
Ververs je kopie regelmatig vanaf de live site. Werk je op een kloon van drie maanden oud, dan test je een situatie die niet meer bestaat. Dat geeft schijnzekerheid.
Wat kost een testomgeving?
Vaak niets extra, en dat verrast de meeste ondernemers. Bij veel hostingpakketten zit een kopieerfunctie standaard inbegrepen.
Zit het er niet bij, dan reken je op een paar euro per maand voor de extra ruimte. Dat is minder dan een uur van je eigen tijd.
De echte kosten zitten in de werkwijze, niet in de techniek. Werken via een kopie kost per wijziging wat meer stappen. Je bouwt, test, geeft akkoord en zet pas daarna live.
Daar staat tegenover wat het voorkomt. Een dag offline op een drukke maandag, een betaalkoppeling die stilletjes stopt, of een halve dag repareren onder stress.
Reken het een keer door voor je eigen bedrijf. Wat kost een dag zonder website je aan gemiste aanvragen? Vrijwel altijd meer dan een testomgeving in een heel jaar kost.
Vraag je hostingpartij gewoon of het erbij zit. Die vraag kost een mailtje en levert vaak een functie op waar je al maanden voor betaalt zonder het te weten.
Werk jij nog rechtstreeks op je live website, of durf je daarom niets aan te passen? Beschrijf je situatie via het formulier hieronder. Ik kijk of je hostingpakket al een kopieerfunctie heeft en hoe je die inricht. Vaak zit het er gewoon bij en gebruikt niemand het. Vermeld je plaats, dan weet ik meteen waar je zit.
