Doorontwikkeling door Reach Digital

Overdracht codebase en database

De eerste stap is de overdracht van de database (klantgegevens, productgegevens etc) en codebase (Magento core code, templates, geinstalleerde modules). Het meest efficient is wannneer er toegang wordt verleend tot de server van de liveomgeving, via SSH. Deze informatie kan worden opgevraagd bij de huidige developmentpartij of bij de hostingpartij. Onze developers installeren tools waarmee ze eenvoudig een dump van de database kunnen maken en alle bestanden van de server kunnen downloaden. De live webshop ondervindt geen downtime van het maken van een backup en het downloaden van deze informatie. Mocht er geen toegang zijn tot de SSH gegevens, of zijn er geen rechten op de server, dan kunnen onze developers bestanden downloaden via FTP. Deze manier van werken is toereikend, maar kost een aantal uur meer.

Eerste sprint meeting, werken volgens scrum

Overstappen naar Reach Digital betekent vaker bij elkaar komen, en face-to-face de werkzaamheden bespreken. We bepalen gezamelijk hoeveel tijd we een periode (sprint) zullen besteden en waaraan we werken in onze eerste sprint meeting; de sprint 1 planning.

Meer over het scrumproces

Opzetten lokale ontwikkel­omgeving

Onze developers zetten vóór de eerste sprintmeeting een lokale omgeving op. Dit betekent dat een gedownloade kopie van de liveomgeving (codebase en database) als volledig functionerende webshop op de computer van een developer worden geinstalleerd. De lokale omgeving waarop de programmeur is een Vagrant Box (simulatie) van een perfect geoptimaliseerde Magento server - vergelijkbaar met de configuraties van door ons geadviseerde hostingpartijen.​Omdat deze inspanning vereist dat een developer al relatief diep in de materie duikt, worden - afhankelijk van de gereserveerde tijd - een punten direct opgepakt:

Indien er PHP of javascript errors ontstaan die de werking van de webshop breken, dan worden deze opgelost. Deze errors kunnen bijvoorbeeld ontstaan door verschillende in de foutieve configuratie van de huidige liveomgeving en de correct geconfigureerde lokale omgeving.

De developer schoont de codebase op. Grote logbestanden worden verwijderd en caches worden opgeschoond voor betere performance.

​De developer controleert de database op exponentieel grote tabellen. Tabellen die kunnen worden opgeschoond of zijn volgelopen met logs. Deze tabellen worden indien mogelijk leeg gemaakt voor een kleinere database en betere performance.

​Sporen van niet langer gebruikte modules worden verwijderd. Dit bestanden zijn (templates, XML configuraties), attributen in de database of tabellen in de database. Het komt voor dat deze sporen effect hebben op de snelheid van de webshop, wat zonde is als een module niet meer wordt gebruikt.

​Problemen met indexeringen worden opgelost. Het komt in praktijk voor dat door configuraties of modules een error veroorzaken bij het draaien van een van de indexeringen. Waardoor de indexering niet meer kan worden gedraaid. Door het probleem met de indexering op te lossen, kunnen gerelateerde problemen (verouderde prijzen, niet kloppende productinformatie, slechte zoekresultaten) soms worden opgelost.

​Inschakelen "Use Flat Catalog Category" en "Use Flat Catalog Product". Twee configuraties die vaak worden uitgeschakeld omdat ze voor foutmeldingen zorgen bij bijvoorbeeld het installeren van een nieuwe module. Echter; ze zijn bepalend voor de wijze waarop Magento intern werkt. Indien ze zijn ingeschakeld, bouwt Magento onder andere categoriepagina's op uit een platte tabel met alle productinformatie (de flat catalog tabel, vergelijkbaar met een groot excel bestand). Dit is erg belangrijk voor de snelheid van de webshop.

Security patches installeren na overdracht

Een overstap naar een ander ontwikkelbureau zoals wij is vaak een nieuwe inpuls voor een project. Het is mogelijk, maar niet altijd direct mogelijk om de laatste security patches te installeren of te upgraden naar de laatste versie van Magento. Hoewel patchen de voorkeur heeft, wordt er vaak voor gekozen om deze inspanningen te verdelen over een aantal sprints. Zo kunnen resources worden besteedt aan zaken die belangrijker worden geacht door de klant, zoals snelheid, problemen met voorraad, koppelingen, betaalmethoden etc.

Overstappen van Windows server naar Linux server

Magento is ontwikkeld voor Linux (http://docs.magento.com/m1/ce/user_guide/magento/system-requirements.html). In de praktijk komt het voor dat webshops door hostingpartijen worden gehost op een Windows omgeving. Een Windows ISS webserver is trager dan Apache of Nginx in het serveren van Magento. Wij zullen daarom altijd een project verhuizen naar een Linux omgeving. Windows is case-insensitive in het lezen en schrijven van bestandspaden. Dit veroorzaakt problemen bij modules waarbij namespacing incorrect is of bijvoorbeeld productafbeeldingen. Afbeeldingen die worden geupload via het Magento adminpanel, worden op de server opgeslagen op een locatie gebaseerd op de bestandsnaam. Een Windowsserver zal bijvoorbeeld een productafbeelding schrijven in de map /B/a/Barkruk_Revolver.jpg, maar een volgende productafbeelding barkruk_dutchbone.jpg ook in deze /B/a/ folder zetten. Linux zou hiervoor een aparte folder /b/a/ voor maken. Bij het verhuizen van de webshop naar een Linux omgeving lossen we deze problemen op.

Kosten van het overstappen naar een nieuwe ontwikkelpartij

Er komen geen bijzondere kosten kijken bij het overstappen naar Reach Digital als ontwerpbureau en ontwikkelbureau, anders dan de tijd die we nodig hebben om de webshop volledig te verhuizen. Tijdens de sprint planning zullen we bepalen hoeveel tijd er besteedt moet en kan worden om performance te optimaliseren en problemen op te lossen die werking op een nieuwe omgeving blokkeren. Hoe we omgaan met het inschatten van issues is te lezen als onderdeel van onze werkwijze.

Licenties aangeschafte third party modules overdragen

In verband met support rondom third party modules of kostenloze upgrades, is het geadviseerd om de aanschaf te laten verlopen via accounts die in eigen beheer zijn. Mochten modules aangeschaft zijn door de voriger ontwikkelpartij, dan kan contact opgenomen worden met de developer om de licentie op een eigen account over te zetten. Door goede contacten met de belangrijkste moduleontwikkelaars, kunnen we hierin begeleiden.

Copyrights vormen geen probleem voor een overstap

Op de huidige webshop berusten (hoogstwaarschijnlijk) copyrights van de vorige ontwikkelpartij. Het intellectueel eigendom ligt bij hen, het onbeperkte gebruikersrecht bij u. Dit betekent dat we op de bestaande code kunnen doorbouwen, wijzigingen kunnen maken en nieuwe functionaliteit kunnen toevoegen. Copyrights zijn in onze ervaring nooit een beperkende factor geweest voor het overstappen naar een nieuwe ontwikkelpartij.

Gebruik maken van Reach Digital modules

Bij Reach Digital hebben we een uitgebreid assortiment aan modules ontwikkeld die we voor de projecten van onze klanten gebruiken. Door over te stappen naar Reach Digital, kunnen we bespreken welke innovaties voor het project interessant zijn en kijken hoe we onze modules het best kunnen inzetten. Een overzicht van onze modules is hier te vinden.

Opdoen van kennis over het bestaande platform

Gedurende de ontwikkeling van de webshop worden continue implementatiekeuzes gemaakt door de desbetreffende ontwikkelaar. Er zit dus veel kennis bij deze partij, die verloren gaat bij een overstap naar Reach Digital. Dit is jammer, maar geen belemmering voor de verdere doorontwikkeling. Veelal zijn beslissingen rondom de werking van functionaliteit terug te beredeneren uit broncode, of - als de partij versiebeheer heeft gebruikt - uit commit messages af te leiden. Wél kan het het helpen om gedurende de doortontwikkeling van complex maatwerk contact te hebben met de vorige developer, zodat vragen sneller beantwoord zijn.

Development velocity en technische schuld

De wijze waarop functionaliteit is gebouwd en de beslissingen die zijn gemaakt met betrekking tot architectuur vertegenwoordigen de kwaliteit van software. Hoe langer software wordt doorontwikkeld en hoe slechter de kwaliteit is, hoe trager doorontwikkeling ervan is. Er moeten meer resources worden besteedt aan operationeel houden van hetgeen dat al bestaat. Deze snelheid waarmee nieuwe functionaliteit kan worden toegevoegd noemen we development velocity. De development velocity heeft een directe relatie met de hoeveelheid technische schuld veroorzaakt door slechte kwaliteit. ​Technische schuld bestaat in ieder softwareproject. Wanneer er een overstap wordt gemaakt naar Reach Digital, dan zorgen we dat een beeld krijgen van de omvang en impact van gemaakte implementatiekeuzes. Bij het inschatten van de issues in de sprint houden we er rekening mee dat we tijd nodig hebben om wellicht zaken te herschrijven, zodat de stabiliteit van de software op ten duur toeneemt. Het is dus niet noodzakelijk om de overstap naar Reach Digital te combineren met een migratie naar nieuwe Magento 2 webshop.