Share
In deze serie bekijken we de verschillende praktijken die worden gebruikt in de professionele ontwikkeling van WordPress. In het vorige artikel hebben we een aantal strategieën en referentiemateriaal besproken die nuttig zijn bij het bouwen van thema's, plug-ins en op WordPress gebaseerde toepassingen.
In dit artikel zullen we kijken naar versiebeheer en omgevingsconfiguraties die het gemakkelijk maken om ons werk te ontwikkelen, testen en inzetten om het aantal fouten dat de weg naar de definitieve versies van ons werk vindt te minimaliseren..
Dit onderwerp is niets nieuws. Sterker nog, ik durf te beweren dat de meeste lezers hier bekend zijn met Subversion en / of Git (vooral met de populariteit van GitHub). Als zodanig is het punt van dit artikel niet zozeer om een rondleiding door de verschillende broncontrolesystemen te geven of om een zaak te bedenken voor welke je zou moeten gebruiken, maar het is de bedoeling om een pleidooi te houden voor waarom u zou broncontrole moeten gebruiken en hoe het gerelateerd is aan onze omgevingen.
Als je helemaal nieuw voor het concept van versiebeheer, laten we een eenvoudige definitie geven van waaruit we kunnen werken zodat we allemaal op dezelfde pagina staan:
Versiebeheer is een momentopname van uw broncode op elk gewenst moment waarmee u terugdraait wanneer een bug wordt geïntroduceerd en aan een nieuwe functie wordt gewerkt zonder bestaande code te overtreden.
Binnen de WordPress-community zijn mensen vaak verdeeld over het al dan niet overwegen van thema's en / of plug-insoftware of veredelde websites. Persoonlijk ben ik van mening dat ze een vorm van software zijn, aangezien ze onderhevig zijn aan veel van dezelfde praktijken:
Daartoe moet het ontwikkelen en onderhouden van WordPress-specifiek werk als zodanig worden behandeld en is het een industriestandaard om een niveau van versiebeheer van software te bieden.
Bovendien werkt versiebeheer hand in hand met het werken aan uw project, het testen ervan en het vervolgens implementeren op een live server zodat anderen het kunnen gebruiken.
De meeste ontwikkelaars zijn bekend met de verschillende omgevingen, zelfs als ze de exacte terminologie niet gebruiken. Eenvoudig gedefinieerd:
Simpel genoeg.
Het punt is dat elk van deze omgevingen ook nauw verwant is met versiebeheer op een zodanige manier dat, wanneer correct beheerd, u de overhead van het onderhouden van versies en implementaties van uw werk kunt minimaliseren.
De ontwikkelomgeving is de machine waarop u uw project daadwerkelijk ontwikkelt. Het bevat een kopie van WordPress, de webserver, databaseserver, IDE en gerelateerde tools die u gebruikt om uw project te bouwen.
In deze specifieke omgeving moet je regelmatig commits doen. Hiermee bedoel ik dat elke keer dat u een belangrijke wijziging aanbrengt, of het nu een nieuwe functie is, een bugresolutie of iets soortgelijks, u de code in de repository moet plaatsen.
Hier heeft het voordeel dat u eenvoudig wijzigingen kunt terugdraaien, identificeren en onderscheiden, mocht er iets misgaan tijdens het proces.
Zodra u een groot aantal wijzigingen hebt doorgevoerd (waarbij u of uw team bepalen wat "significant" is), is het tijd om de reeks wijzigingen te markeren en in de stagingomgeving te implementeren..
De stagingomgeving is een aparte server die lijkt op de productieomgeving, maar wordt gebruikt om het project te testen voordat het wordt vrijgegeven. Het bevat de nieuwste versie van de code, testgegevens en is bedoeld voor gebruikers om het project te evalueren voordat het wordt vrijgegeven. Hier mag geen ontwikkeling plaatsvinden.
Hoewel hier geen ontwikkeling zou moeten plaatsvinden, is het niet ongebruikelijk om verschillende foutopsporingshulpmiddelen te gebruiken om logboekberichten te genereren of om te bekijken wat er binnenkomt en uit de database komt terwijl u op de site werkt.
Omdat ontwikkelaars vaak een reeks wijzigingen in de repository plegen, moeten ze worden getest. Dit is waar de Staging-omgeving in het spel komt. Over het algemeen komt de Staging-omgeving vaak overeen met de nieuwste set wijzigingen die in de repository zijn vastgelegd.
Maar dit roept twee vragen op:
Ten eerste is dit een goede zaak - het betekent dat de Staging-omgeving zijn doel heeft gediend! Bovendien geeft dit ons de kans om onze broncode te bekijken om te bepalen of een bug moet worden opgelost of dat een nieuwe functie moet worden geïntroduceerd.
En dit is waar bronbesturing van pas komt.
Als er een bug is opgetreden, kunt u ervoor kiezen om de wijziging terug te draaien, maar dat is in de Staging-omgeving niet nodig. In plaats daarvan zoekt u eenvoudig waar de bug zich bevindt, lost u deze op, maakt u de code vast en wordt de code opnieuw ingezet voor testen in de Staging-omgeving..
U herhaalt dit proces totdat er geen fouten zijn of, nauwkeuriger, u kunt geen fouten vinden.
Als je geen fouten kunt vinden, dan heb je in wezen een zogenaamde stabiele build. Op dit punt kunt u een versie van uw code labelen - of stempelen, labelen of op elke conventie van uw bronbesturingssysteem toepassen en deze in de productieomgeving implementeren..
Natuurlijk bestaat de kans dat een bug kan worden ontdekt nadat deze is geïmplementeerd in de productieomgeving. In dat geval moet speciale actie worden ondernomen.
De productieomgeving is synoniem met de live-site. Dit is waar echte gebruikers echte gegevens maken, beheren en gebruiken. Hier mag geen ontwikkeling plaatsvinden.
Er is heel weinig te zeggen over de productieomgeving wat betreft ontwikkeling. Immers, dit zou niets meer moeten zijn dan waar de broncode wordt ingezet die anderen kunnen gebruiken.
Maar er is een kans dat hier een bug kan worden vrijgegeven. Wanneer dit gebeurt, deze is wanneer een rollback zou moeten plaatsvinden. Simpel gezegd, een terugdraaien is wanneer u de nieuwste reeks wijzigingen neemt en de implementatie letterlijk ongedaan maakt door het project terug te zetten naar de vorige staat.
Voorafgaand aan het uitvoeren van een rollback, is het de moeite waard om eventuele recreatieve stappen op te merken, zodat u deze kunt reproduceren in zowel de Staging-omgeving als de ontwikkelomgeving om het probleem goed op te lossen.
Voer vanaf hier de ontwikkeling uit die nodig is om het probleem op te lossen, een andere wijziging uit te voeren, het in de Staging-omgeving te implementeren en het in de productieomgeving te implementeren, ervan uitgaande dat het tests doorstaat.
Vanzelfsprekend dekt deze specifieke post concepten op een hoog niveau: we onderzoeken niet welke versiecontrolesystemen het beste zijn, noch kijken we welke tools het beste zijn voor jouw specifieke besturingssysteem. Deze onderwerpen vallen buiten de scope van dit bericht en verdienen elk een eigen serie.
Binnen het concept van Professional WordPress Development kunnen deze praktijken uiteraard nuttig zijn bij het ontwikkelen, testen en implementeren (en terugdraaien) van versies van uw project..
In het laatste bericht zullen we enkele van de verschillende beschikbare hulpmiddelen bekijken die ons in staat stellen om vele fouten in onze lokale ontwikkelingsomgeving te diagnosticeren met de bedoeling te voorkomen dat velen van hen zelfs de stagingomgeving bereiken..
Accentsconagua