PHP

Altijd als er een grote nieuwe PHP versie uitkomt, speelt bij Byte de vraag hoe we gaan zorgen dat de migratie voor klanten in goede banen geleid kan worden. De migratie leidt eigenlijk altijd tot kopzorgen bij gebruikers van slecht geschreven software. Helaas is dat nogal veel software 🙂 Of het is software die niet gemakkelijk aangepast kan worden, omdat de webshop altijd up moet zijn. In het geval van het migreren naar PHP 5.3 zijn er een aantal showstoppers:

  1. Sites gebruiken zelf-gecompilede PHP modules zoals pdflib.
  2. Sites draaien softwarepakketten die niet gemakkelijk te updaten zijn zoals:
    • Magento 1.3
    • Joomla! 1.0 of oude Joomla! 1.5 versies
  3. Oude zelfgeschreven code die nog uit de PHP4 tijd stamt.

Wat zijn de mogelijkheden om te migreren naar PHP 5.3?

Byte heeft een aantal mogelijkheden om  klanten door de migratie te leiden. De trouwe klant heeft de mogelijke technieken al een keer langs zien komen:

  1. Als de nieuwe techniek parallel naast de oude techniek kan lopen bieden we de klant een migratie tool aan.
  2. Als de nieuwe techniek niet parallel kan, dan richten we een staging server in.
  3. Als er geen staging server mogelijk is, gaan we big-bang over op een bepaald tijdstip.

Big Bang

Byte kiest eigenlijk nooit voor deze oplossing. Als het even kan, nemen we de parallelle route, anders de staging server route. Soms is het echter niet mogelijk. Soms door tijdslimieten, soms is het zo’n kleine verandering dat het een grote tijdsinvestering van het inrichten van staging servers niet rechtvaardigt. Of soms zijn er maar een paar klanten die er iets van gaan merken. Gelukkig zijn we creatief en hebben we daarom geen voorbeelden 🙂 We hebben het altijd weten op te lossen.

Parallel

Bij de migratie van PHP4 naar PHP5 hebben we de twee versies naast elkaar aangeboden. Dit was mogelijk omdat PHP deze mogelijkheid al ingebouwd had. Ook de Debian packages waren zo ingericht dat dit direct werkte. Op het Service Panel kon de klant kiezen met welke versie er gewerkt moest worden.

Ook toen we van MySQL 4 naar MySQL 5 zijn gemigreerd hebben we een parallelle periode gehad. Klanten konden zelf een kopie maken van hun database en een moment van overstappen kiezen.

Dit is altijd de meest wenselijke en meest flexibele oplossing, omdat de klant zelf kan kiezen wanneer zijn of haar site overgaat naar de nieuwe versie. Ook kan de klant gemakkelijk terug.

Staging server

Bij de migratie van Debian Etch naar Debian Lenny hebben we voor alle zekerheid staging servers ingericht. Dit zijn servers waarop de klant zelf kan zien hoe zijn of haar site werkt op het nieuw platform. Op een bepaald moment worden de servers een voor een overgezet naar de nieuwe versie.

Het nadeel is dat alle klanten op hetzelfde moment overgaan naar de nieuwe versie en dat klanten niet zelf kunnen bepalen wanneer een bepaalde site overgaat. Daarnaast is de manier van testen voor klanten veel ingewikkelder. We maken gebruik van een domein.nl.staging.bytenet.nl URL (te vergelijken met de testbyte.nl URL). Waar de testbyte.nl URL al voor veel klanten erg ingewikkeld is, daar is de staging.bytenet.nl al helemaal moeilijk. Het is ook moeilijk, want de nieuwe URL zit in de weg bij veel mod_rewrite rules en werkt niet met SSL.

Daarom is deze oplossing meestal niet te prefereren boven de parallelle route. Maar voor sommige migraties, zoals de etch/lenny migratie is het in elk geval een mogelijkheid.

Scan je eigen Magento shop op veiligheidslekken