Zero downtime deployments met Magento

Kleinere ontwikkelingen met hogere frequentie op productie uitrollen houdt het risico (op bugs, maar ook dat er iets fout gaat tijdens deployment) laag en de voortuitgang erg tastbaar.

Om continuous integration mogelijk te maken moeten deployments (code gaat op de liveserver) zo kort mogelijk duren. Een uur downtime willen klanten liever niet. Dus worden dié deployments uitgesteld.

Tot we ze uiteindelijk woensdagochtend om 5 uur moesten doen.

Veilig ontwikkelen via versiebeheer

Om te voorkomen dat webshops een uur down zijn bij het uitrollen van nieuwe functionaliteit, hebben we deployments volledig geautomatiseerd. Niemand hoeft handmatig acties uit te voeren op de liveomgeving.

Wel zo veilig.

Deployments zijn gekoppeld aan het versiebeheersysteem, dat altijd de laatste code van een project bevat.

Programmeurs ontwikkelen lokaal op een kloon van de webshop die op hun computer draait en zetten nieuwe code als pakketje (een commit) in een versiebeheer archief. Deze repository ziet er uit als een tijdlijn met daarop alle wijzigingen die in de jaren aan de code zijn gedaan. Wanneer functionaliteit klaar is om getest te worden, worden alle codewijzigingen waaruit deze functionaliteit bestaat vanuit de repository direct op de server gedeployed.

Wanneer het om testbare functionaliteit gaat, dan wordt code uitgerold op de testomgeving. De klant (vaak de persoon in de rol van productowner) kan de functionaliteit gebruiken alsof deze live staat, zonder de productieomgeving te vervuilen.

Keurt de productowner functionaliteit goed, dan wordt via hetzelfde proces de functionaliteit uitgerold op de productieomgeving.

Een sterk voordeel van GIT (het versiebeheer systeem dat Reach Digital gebruikt) is dat het eenvoudig is om uitgerolde codewijzigingen terug te draaien.

Erg handig als we een functionaliteit uitrollen die toch nog niet werkt zoals bedoeld.

Automatische deployments voor Magento

Vanaf het versiebeheer systeem zetten we automatisch de nieuwe code over naar de server. Maar om de webshop up en running te krijgen met nieuwe functionaliteit, moeten er nog een aantal zaken gebeuren.

De cache flushen, bijvoorbeeld.

We gebruiken DeployHQ (een SAAS deployservice) om deze acties op de server uit te voeren:

Via een webhook wordt bij een commit op de Master branch automatisch de deployservice getriggert. Met een aantal acties, waaronder het aanmaken van een maintenance.flag, wordt de webshop offline gezet. De laatste code wordt direct vanaf Github overgezet naar de server.

Alle symlinks op de server worden verwijderd en Modman wordt gedraaid. Modman maakt development overzichtelijker doordat alle bestanden waaruit een Magento module bestaat in één map kunnen worden geplaatst. Het draaien van Modman (script) plaatst symlinks op de juiste locaties binnen de Magento installatie.

Via composer worden de benodigde PHP packages gedownload of geupdate. Externe Magento modules die gebruikt worden in het project, bijvoorbeeld.

De benodigde javascript packages (libraries en frontend componenten) worden gedownload en de frontend wordt gebuild (yarn/bower/polymer). We richten ons sinds ongeveer een jaar op component based development. Sommige van onze Magento 1 projecten maken al gebruik van polymer componenten. Bower gaat eruit wanneer we hebben geupgrade naar Polymer 3. Onderdeel van dit proces is ook het samenvoegen en compilen van javascript en css bestanden.

Via n98-Magerun draaien we upgradebestanden van Magento modules. Upgradebestanden voeren databasequeries uit. Een nieuwe versie van een module kan bijvoorbeeld een extra kolom aan de database toevoegen.

Verwijderen mappen. Een aantal folders wordt verwijderd als voorzorgmaatregel. Mochten een developer een folder die eigenlijk alleen nuttig is voor development meesturen, dan worden deze automatisch verwijderd.

We flushen cache en verwijderen de maintenance.flag, waarna de webshop weer te bezoeken is.

Het deploymentproces voor Magento 1 webshops is volledig lineair. Iedere actie wordt opvolgend uitgevoerd binnen een tijdspanne van een instelbaar aantal minuten.

0 downtime voor Magento 2 deployments

De wijze waarop Magento 2 projecten bij Reach Digital worden ontwikkeld is qua werkwijze gelijk aan die van Magento 1 projecten:

• Functionaliteit wordt lokaal Ontwikkeld
• Wijzigingen worden opgeslagen in versiebeheer
• Testbare functionaliteit gaat naar de Testomgeving
• Geteste functionaliteit gaat naar de Acceptatieomgeving
• Uitontwikkelde functionaliteit gaat naar de Productieomgeving

OTAP

Deployments voeren we uit met Jenkins. Een open source deploymenttool in eigen beheer die 100% controle biedt over de acties die we rondom een deployment kunnen uitvoeren.

Door de combinatie van Jenkins en het technische design van Magento 2, kunnen we functionaliteit uitrollen met zero downtime.

Het proces bevat net als de deployments voor Magento 1 een groot aantal stappen. Libraries downloaden, bestanden samenvoegen, bestanden compilen etc. Het grootste verschil: we zetten de website niet in maintenance mode (offline).

In plaats van de bestanden op de root van de server te vervangen, schrijven we alle bestanden in een nieuwe map op de root van de server. Gedurende een deployment is de magento webshop gewoon bereikbaar. En als bijkomend voordeel kunnen er meerdere deployments tegelijkertijd lopen. Één op de testomgeving en één op productieomgeving bijvoorbeeld.

Als de deployment is afgerond en de nieuwe codebase klaarstaat op de server, checken we of er sprake is van database updates. Indien dit niet het geval is, switchen we de webshop naar de folder waarin de deployment is uitgerold met een symlink. We wijzen een andere map als 'webroot' folder aan.

Met als resultaat dat de webshop ineens ... boom ... alle nieuwe functionaliteit biedt.

Zelfs tijdens het gebruik van de webshop door een bezoeker.

Check op databasewijzigingen

Bij elke deployment wordt gecontroleerd of er sprake is van databasewijzigingen:

• We lopen door alle modules en extenties heen en controleren of de versie van de module gelijk is aan die in de database.
• We doen een checksum op de configuratie file van Magento. Hierin is een verschil wanneer er modules worden in- of uitgeschakeld, of nieuwe modules worden toegevoegd.

Mocht er wél sprake zijn van databaseupdates, dan schakelen we de Magento maintenance mode aan nét voor database updates en direct weer uit bij het afronden ervan. De tijd dat de webshop offline is wanneer er sprake is van een deployment mét databasewijziging dan is de downtime ongeveer tussen de 10 en 15 seconden.

Instant rollbacks

Waar we voor Magento 1 projecten al heel snel konden schakelen wanneer we wilden terugdraaien (rollback), is er in het geval van Magento 2 in combinatie met Jenkins als deploytool zelfs spraken van instant rollbacks.

Met een klik op de knop linken wijzigen we de webroot verwijzing naar de oude codebase en flushen we caches.

We kunnen naast nieuwe functionaliteit uitrollen, dus ook terugdraaien in enkele seconden

Toekomst

Magento draait op MariaDB, een MySQL variant. Mogelijk is het in de toekomst mogelijk om met een andere variant (Percona) ook probleemloos de database te upgraden zonder downtime. Een wens die nog op de lijst van het developmentteam staat.

Voor nu zijn we heel enthousiast over de snelheid waarmee we nieuwe functionaliteit in productie kunnen zetten.

De nieuwe deploymentstrategie is reeds voor al onze Magento 2 klanten uitgerold.