Staging: een kopie waar je fouten mag maken

Er staat een update klaar voor je website. Je klikt op bijwerken en de helft van je pagina’s valt uit elkaar. Je klanten zien dat live, midden op een dinsdagochtend. Terugdraaien lukt niet meer, want de oude versie is overschreven.

Dat scenario is de reden dat testomgevingen bestaan. Ze zijn niet bedoeld voor grote bureaus met strakke procedures.

Ze zijn bedoeld voor precies dit soort dinsdagochtenden. Je test op een kopie en pas daarna op het echte werk.

Het kost je vijf minuten extra per update. Het bespaart je een keer per jaar een halve dag paniek.

Staging uitgelegd in het webdesign woordenboek van Project Direct
Een kopie van je site waar je fouten mag maken.

Wat is staging?

Een stagingomgeving is een kopie van je site die op een apart adres draait. Alles is hetzelfde: je teksten, je plugins, je instellingen.

Het verschil is dat niemand hem bezoekt. Je kunt er dus rustig van alles slopen.

Waar hij staat

Meestal op een subdomein dat begint met het woord staging of test. Bij een fatsoenlijke hostingpartij maak je hem met een druk op de knop.

Hij draait op dezelfde server en met dezelfde instellingen. Dat is belangrijk, want anders test je een andere situatie.

Waarvoor je hem gebruikt

De vier momenten

  1. Bij updates van je systeem en je uitbreidingen.
  2. Bij een nieuw onderdeel, zoals een boekingsmodule.
  3. Bij een verbouwing van je vormgeving.
  4. Bij het uitproberen van een nieuwe uitbreiding.

Die eerste is de belangrijkste. Updates zijn de meest voorkomende oorzaak van een stukke site, zie plugin.

Waarom je niet live test

Omdat je bezoekers meekijken terwijl je bezig bent. Een half werkend formulier kost je direct aanvragen.

Bovendien kan Google net op dat moment langskomen. Wat hij dan ziet, kan dagen in de resultaten blijven staan.

Wijzigingen doorzetten

Er zijn twee manieren en het verschil is belangrijk. Je kunt de hele kopie terugzetten of alleen de bestanden.

Het wijzigingen doorzetten met alles erop en eraan overschrijft ook je nieuwe bestellingen en berichten. Dat is bij een winkel of een blog een probleem.

Wat ik meestal doe

Ik test op de kopie en voer de wijziging daarna handmatig door op de echte site. Dat klinkt omslachtig en het is veiliger.

Je weet dan namelijk precies wat er is veranderd. Bij een grote verbouwing gebruik ik wel het volledige terugzetten, in overleg en op een rustig moment.

Het verschil met een back-up

Een back-up is een momentopname die je bewaart voor het geval het misgaat. Een testomgeving is een werkplek waar je bewust dingen probeert.

Je hebt ze allebei nodig en ze vervangen elkaar niet. Zonder back-up ben je bij een echte fout alsnog nergens.

Hoe het samenhangt

Voor elke wijziging op de echte site maak ik alsnog een back-up. Ook als het op de kopie prima ging.

Dat is een gewoonte die twee minuten kost. Meer over die werkwijze lees je bij DTAP.

Afschermen voor Google

Dit is de valkuil bij deze werkwijze. Een testomgeving die vindbaar is, levert een dubbele versie van je site op.

Bij het afschermen voor Google zet je hem op no-index en achter een wachtwoord. Het tweede werkt het best, want het eerste is een verzoek.

De omgekeerde fout

Die is nog vervelender. Gaat een site live met de blokkade er nog in? Dan sluit je jezelf buiten Google.

Controleer dat dus na elke oplevering. Dat is een controle van dertig seconden, zie ook QA.

Hoe je die controle doet

Typ je domein in met robots.txt erachter en kijk of er niets wordt geblokkeerd. Meer daarover lees je bij robots.txt.

Dat gebeurt vaker dan je denkt. Je merkt het pas als je bezoek instort, en dan ben je weken verder.

Waarom een kopie op dezelfde server hoort

Anders test je een andere situatie dan je echte site. Andere versies leveren andere uitkomsten op.

Vraag je hostingpartij dus of ze dit ondersteunen. Bij een fatsoenlijk pakket is het een knop, zie CMS.

Ook de kleine wijzigingen

Een update van een uitbreiding lijkt onschuldig en is de meest voorkomende oorzaak van ellende. Juist die klik je zonder nadenken aan.

Neem daar dus die vijf minuten voor. Dat is de goedkoopste verzekering die je kunt afsluiten.

Meer vragen over Staging

Dit zijn de vragen die ik hierover het vaakst krijg. Ik werk ze los uit.

  • Wat is staging?
  • Waarom zou je een testomgeving gebruiken?
  • Hoe zet je wijzigingen van staging naar live?
  • Kost een stagingomgeving extra geld?
  • Komt mijn testomgeving in Google?
  • Wat is het verschil tussen staging en een back-up?
Omdat je bezoekers anders meekijken terwijl je bezig bent. Een half werkend formulier kost je direct aanvragen. Bovendien kan Google net op dat moment langskomen. Wat hij dan ziet, kan dagen in de resultaten blijven staan. Ik gebruik hem op vier momenten. Bij updates van je systeem en je uitbreidingen. Bij een nieuw onderdeel, zoals een boekingsmodule. Bij een verbouwing van je vormgeving. En bij het uitproberen van een nieuwe uitbreiding. Die eerste is de belangrijkste. Updates zijn de meest voorkomende oorzaak van een stukke site, en juist die klik je zonder nadenken aan. Gebruik hem in elk geval bij updates, ook bij kleine. Juist die klik je zonder nadenken aan. De vijf minuten die het kost, zijn de goedkoopste verzekering die je kunt afsluiten voor je site. Test er ook nieuwe uitbreidingen op voordat je ze op je echte site zet. Zo zie je vooraf of ze conflicteren. Zo voorkom je verrassingen op je echte site.
Een stagingomgeving is een kopie van je website die op een apart adres draait. Alles is hetzelfde: je teksten, je plugins, je instellingen. Het verschil is dat niemand hem bezoekt. Je kunt er dus rustig van alles slopen. Hij staat meestal op een subdomein dat begint met het woord staging of test. Bij een fatsoenlijke hostingpartij maak je hem met een druk op de knop. Hij draait op dezelfde server en met dezelfde instellingen. Dat is belangrijk, want anders test je een andere situatie dan je echte site. Het is niet iets voor grote bureaus met strakke procedures. Het is bedoeld voor de dinsdagochtend waarop een update je halve site sloopt. Vraag je hostingpartij of je een testomgeving kunt aanmaken. Bij een fatsoenlijk pakket is dat een knop. Zorg dat hij op dezelfde server draait als je echte site. Anders test je een situatie die niet klopt. Werk je nu rechtstreeks op je live site, dan is dit de eerste verbetering die ik zou doorvoeren. Het kost bijna niets.
Er zijn twee manieren en het verschil is belangrijk. Je kunt de hele kopie terugzetten of alleen de bestanden. De hele kopie terugzetten overschrijft ook je nieuwe bestellingen en berichten. Dat is bij een winkel of een blog een probleem. Ik test daarom op de kopie en voer de wijziging daarna handmatig door op de echte site. Dat klinkt omslachtig en het is veiliger. Je weet dan namelijk precies wat er is veranderd. Bij een grote verbouwing gebruik ik wel het volledige terugzetten. Dat doe ik in overleg en op een rustig moment, met een verse back-up ernaast. Zet bij een winkel of een blog nooit zomaar de hele kopie terug. Je overschrijft dan je nieuwe bestellingen en berichten. Voer wijzigingen liever handmatig door op je echte site. Dan weet je precies wat er is veranderd. Spreek vooraf af welke manier je gebruikt en op welk moment. Doe dat nooit op een drukke ochtend.
Een back-up is een momentopname die je bewaart voor het geval het misgaat. Een testomgeving is een werkplek waar je bewust dingen probeert. Je hebt ze allebei nodig en ze vervangen elkaar niet. Zonder back-up ben je bij een echte fout alsnog nergens. Voor elke wijziging op de echte site maak ik daarom alsnog een back-up. Ook als het op de kopie prima ging. Dat is een gewoonte die twee minuten kost. De combinatie is wat het veilig maakt. Je test vooraf op een kopie en je hebt een uitweg voor het geval er toch iets misgaat. Maak voor elke wijziging alsnog een back-up, ook als het op de kopie prima ging. De combinatie is wat het veilig maakt: vooraf testen en een uitweg achter de hand. Ze vervangen elkaar niet. Bewaar je back-ups bovendien ergens anders dan op dezelfde server. Anders verlies je bij een echt probleem allebei. Zo heb je altijd een uitweg achter de hand.
Dat kan, en dan heb je een dubbele versie van je site online staan. Zet hem daarom op no-index en achter een wachtwoord. Dat tweede werkt het best, want het eerste is alleen een verzoek. De omgekeerde fout is nog vervelender. Gaat een site live met de blokkade van de testomgeving er nog in, dan sluit je jezelf buiten Google. Dat gebeurt vaker dan je denkt en je merkt het pas als je bezoek instort. Controleer dat dus na elke oplevering. Typ je domein in met robots.txt erachter en kijk of er niets wordt geblokkeerd. Dat is een controle van dertig seconden. Zet je testomgeving achter een wachtwoord en niet alleen op no-index. Dat eerste is een slot, het tweede een verzoek. Controleer na elke oplevering of die blokkade niet is meeverhuisd naar je echte site. Dat is een controle van dertig seconden. Vraag je bouwer om dit expliciet op de opleverlijst te zetten. Het staat er zelden op en het is de goedkoopste controle die er is.
Werk je nu rechtstreeks op je live site en gaat het af en toe mis bij updates? Beschrijf je situatie via het formulier hieronder. Ik kijk of je hosting een testomgeving ondersteunt en hoe je die werkwijze inricht. Vermeld je plaats, dan weet ik meteen waar je zit.

Waar kan ik je mee helpen?