De livegang van een website of applicatie is misschien wel het belangrijkste moment in de levenscyclus van een project.
Wekenlang werk je intensief samen met de klant en collega’s om een mooie website of applicatie neer te zetten. Vooral de laatste week voor een livegang kan hectisch zijn.
In dit blog geef ik inzicht in hoe zo’n livegang aan onze kant verloopt. Wat doet de ontwikkelpartij? Wat is de rol van onze hostingpartij? Wat verwachten we van onze klant?
Ik spreek in dit blog over de ontwikkeling van een nieuwe website voor de klant. Voor de website gebruiken we meestal WordPress, waarbij wij ons eigen thema maken, en soms gebruik maken van een zelfgemaakte plugin voor extra functionaliteit.
Onze salesafdeling heeft een nieuwe klant binnen gehaald. Fijn! Deze klant wil graag de website in een nieuw jasje gestoken hebben en zijn onder de indruk van het uiterlijk, de werking en de gebruiksvriendelijke inrichting van ons portfolio. Na de eerste gesprekken beginnen we met het eerste ontwerp, dat direct in HTML gemaakt wordt.
Zodra we samen met de klant tot een uiteindelijk ontwerp zijn gekomen begint de bouw. Op een bepaald moment zijn alle functionaliteiten gebouwd en kan de klant gaan testen en vullen op de acceptatie-omgeving. Als dat afgerond is, en als alle partijen zich kunnen vinden in de uiteindelijke versie op de acceptatie-omgeving, dan gaan we een moment plannen voor de livegang.
Het moment van livegang plannen we op een doordeweekse dag, van maandag tot en met donderdag. Bij voorkeur ’s ochtends, zodat we de hele middag nog hebben om eventuele acute feedback door te voeren. Soms vult de klant ’s ochtends nog de laatste zaken, en gaan we direct na de lunch, met een gevulde maag, live.
In de dagen voor de livegang regelen we nieuwe omgeving op de webserver. Tegenwoordig is dat altijd met SSL (beveiligde verbinding). Zodra de hostingomgeving aangemaakt is en wij de gegevens ontvangen hebben, kunnen we beginnen met inrichten van deze omgeving.
Het inrichten van de productie-omgeving houdt de volgende zaken in:
- uploaden en installeren van WordPress, altijd laatste versie
- database-gegevens instellen
- database overzetten
- aanmaken thema-map (eerst nog leeg)
- autodeployment inregelen
- eerste deployment doen
- installeren van standaard plugins
- overzetten uploads
Uploaden en installeren van WordPress
Hiervoor halen we de meest recente versie naar de productie-server en pakken deze uit. Dit zorgt ervoor dat WordPress in de basis werkt. We verwijderen de standaard meegeleverde thema’s van WordPress.
Database-gegevens instellen
We bewerken het bestand wp-config.php. Hierin staan een aantal basis-instellingen van de site, waaronder databasegegevens. Deze databasegegevens hebben we van onze hostingpartij ontvangen en vullen we in. We zetten WP_DEBUG op false, zodat we op productie geen foutmeldingen zien. We nemen de Authentication Unique Keys and Salts over van de acceptatie-omgeving.
Database overzetten
We maken een export van de database van acceptatie en plaatsen deze op productie. Alles wat de klant op acceptatie gevuld heeft, komt nu ook op productie te staan. Deze actie vindt vlak voor de daadwerkelijke livegang nogmaals plaats.
Aanmaken thema-map
We maken een thema map aan voor ons thema. Deze map is eerst nog leeg en wordt bij de volgende stap (autodeployment) gevuld.
Autodeployment inregelen en eerste deployment doen
Uiteraard regelen we ook autodeployment in voor de productie-omgeving. Lees meer hierover in mijn vorige blog. Als de eerste deploy gelukt is, is de themamap gevuld.
Installeren van standaard plugins
Ons thema geeft zelf aan welke standaard plugins geïnstalleerd moeten worden. Er wordt de vraag gesteld om deze plugins te installeren, en met een druk op de knop is dat ook gebeurd. Bij deze standaard plugins valt te denken aan: Login Lockdown, WordPress SEO, Regenerate Thumbnails, Gravity Forms en Advanced Custom Fields PRO. Soms zijn er voor een specifiek project nog extra plugins nodig. Deze voegen we handmatig toe.
Overzetten uploads
De klant heeft op acceptatie-omgeving afbeeldingen en andere bestanden geüpload. Deze worden nu alvast overgezet naar de productie-omgeving. Dit gebeurt vlak voor livegang nog een keer.
De dag van live gaan is aangebroken. ’s Ochtends checken we nog even met de klant of de website is zoals het moet zijn. De laatste puntjes worden nog doorgevoerd, de laatste teksten doorgenomen. Ongeveer een uur voor de geplande livegang (of bijgestelde livegang) vragen we akkoord aan de klant. Het is belangrijk dat de klant ongeveer een kwartier voor livegang stopt met invoeren van content. Het kan namelijk zijn dat dit niet wordt meegenomen naar de productie-omgeving.
De laatste stap is de DNS-gegevens aanpassen. We hebben een paar dagen eerder de TTL (time to live) van het A- en AAAA-record al verlaagd. Door het wijzigen van de DNS-records, vertellen we alle DNS-servers op de wereld dat de domeinnaam naar een ander ip-adres (computer) moet gaan leiden. Vaak duurt het dan nog minimaal de TTL, of een paar uren, voordat iedereen de nieuwe website ziet. We gebruiken hiervoor de tool dnschecker.org om te checken of de DNS-wijzigingen daadwerkelijk zijn doorgevoerd.
De website staat live! We feliciteren de klant met de nieuwe website. Vaak begint dan een traject van nazorg en aanvullende wensen van de klant. Deze leveren we altijd eerst op op acceptatie-omgeving.