Illustratieve afbeelding Veiligheidsupdates

Drupal veiligheidsupdates

Wanneer Drupal een nieuwe veiligheidsupdate uitbrengt wordt bij Your Source een vast proces doorlopen om ervoor te zorgen dat de update op tijd wordt uitgerold naar alle sites die door ons ondersteund worden. Een groot deel van dit proces is geautomatiseerd om ervoor te zorgen dat alle stappen doorlopen worden en de kans op menselijke fouten zo minimaal mogelijk gehouden wordt. In dit artikel wordt dit proces in stappen uiteengezet vanaf het moment dat de veiligheidsupdate gepubliceerd wordt tot aan de uiteindelijke deployments.

In het BPMN (Business Process Model and Notation) schema dat we hieronder hebben geplaatst is te zien hoe we dat bij Your Source doen.

Stap 1: Monitoren publicatie veiligheidsupdates

Via een automatisch proces met behulp van Drush en cron wordt elke nacht gekeken of er nieuwe veiligheidsupdates zijn. Als dit zo is, worden de veiligheidsupdates vanzelf door automatische processen (GitLab CI) klaargezet om doorgevoerd te worden op de acceptatieomgevingen (zie ook de Wikipedia pagina over de OTAP-straat voor uitleg over acceptatieomgevingen) van de ondersteunde websites.

Stap 2: Impact-analyse

Wanneer de werkdag van start gaat staan er al meldingen van de veiligheidsupdates in het chatprogramma dat door het hele team wordt gebruikt. De impact van de veiligheidsupdates wordt beoordeeld en aan de hand daarvan worden afspraken gemaakt met de klant. Soms kan een veiligheidsupdate namelijk zonder merkbare downtime doorgevoerd worden, maar in andere gevallen moet een website tijdelijk in onderhoudsmodus om de updates soepel uit te kunnen rollen. Daarnaast wordt de urgentie van de updates beoordeeld zodat we er zeker van zijn dat de afgesproken deadlines voor de doorvoer worden gehaald.

Stap 3: Lokale tests

Voordat de veiligheidsupdates op de acceptatieomgevingen worden uitgerold wordt eerst even door een collega gekeken wat er gebeurt na het toepassen van de update. Er wordt gekeken of de database bijgewerkt moet worden en of de site blijft werken zoals voorafgaand aan de update. Als hij problemen tegenkomt worden deze onderzocht en opgelost. In zeldzame gevallen kan de update niet zomaar uitgevoerd worden en wordt met de klant een nieuwe oplossing besproken om er toch voor te zorgen dat de site veilig blijft.

Stap 4: Regressietest in OTAP-straat

Naast de handmatige tests worden ook geautomatiseerde tests uitgevoerd op de server voor het codebeheer (GitLab). Dit proces bestaat uit drie onderdelen:

  • Visuele tests. Er wordt een vergelijk gemaakt tussen de grafische weergave van vooraf ingestelde pagina's op de live site en op de acceptatieomgeving, waar de veiligheidupdates zijn uitgevoerd. Deze vergelijking wordt in meerdere resoluties gedaan, zodat ook verschillen in weergave op tablets en smartphones opgemerkt worden. Voor deze visuele regressietests wordt Wraith ingezet.

  • Functionele tests. Een aantal vooraf gedefinieerde scenario's worden uitgevoerd op de acceptatieomgeving, waarbij automatisch een foutmelding wordt gegenereerd wanneer het resultaat niet aan de verwachtingen voldoet. Voor de functionele test wordt de Behat test-tool ingezet. Hiermee kunnen menselijke handelingen als navigatie en het aanklikken van elementen worden ge├»miteerd. Wanneer functionaliteit stuk gaat, kan de update niet verder toegepast worden en moeten eerst de problemen verholpen worden.

  • 'Build'-tests. Op een groot deel van de websites in ons beheer wordt gebruik gemaakt van Kraftwagen om het updaten van modules of Drupal core en het toepassen van patches te automatiseren. In de tests voor veiligheidsupdates wordt gekeken of de site ook opnieuw opgebouwd kan worden met behulp van Kraftwagen. Dit wordt de 'build'-test genoemd. Omdat het uitrollen van wijzigingen in de code altijd gepaard gaat met het opnieuw opbouwen van de site met behulp van Kraftwagen, is het van belang dat dit eerst goed getest wordt.

Stap 5: Acceptatie

Wanneer alle tests doorlopen zijn wordt de veiligheidsupdate toegepast op de codebase op de acceptatieomgeving en doorgevoerd naar de productieomgeving.

Stap 6: Backup, deployment, rollback scenario's.

Voordat de update naar de live site gaat, wordt altijd een backup gemaakt van de database. Afhankelijk van de soort toegang die we hebben naar de site, wordt al dan niet een backup van de code gemaakt. Wanneer we alleen met FTP nieuwe bestanden kunnen uploaden, worden eerst de bestaande bestanden gedownload. Deze kunnen dan teruggezet worden als er toch een rollback plaats moet vinden. Wanneer de site ook bereikbaar is via SSH kunnen we ons versiebeheersysteem Git inzetten. Mocht er dan iets teruggedraaid moeten worden, dan kunnen we teruggaan in onze Git-geschiedenis en de oudere versie opnieuw uitrollen.

Stap 7: Laatste controles

Wanneer de veiligheidsupdates zijn uitgerold wordt nog even door de website geklikt om te kijken of alles goed is gegaan. De nodige e-mails worden verstuurd om de klant op de hoogte te stellen dat de updates zijn uitgevoerd, met name als de site ook in onderhoudsmodus moest.

Rolverdeling

Voor de veiligheidsupdates is een duidelijk omlijnde rolverdeling ingevoerd in het team om ervoor te zorgen dat er geen taken in het luchtledige blijven hangen. Elke betrokkene heeft inzichtelijk welke taken hij/zij precies heeft en kan deze puntsgewijs langslopen.

Vraag een offerte aan