Samenwerken met Git (deel 2)

Enige tijd geleden beschreef ik in deel 1 van samenwerken aan een WordPress site met Git de eerste stapjes. In dit deel beschrijf ik hoe je echt kunt samenwerken (push en pull), hoe je de code op de stage en live sites zet en hoe je je database in sync houdt. Daar gaan we!

Git push en git pull

bitbucket-logoDe laatste keer zijn we geeindigd met het mergen van de develop branch in de release branch. Echter, laten we er eens van uit gaan dat een andere developer ook aan jouw code verder wil werken voor het daadwerkelijk naar de klant gaat. Dan is het van belang dat jouw code beschikbaar is voor de ander. Dit kun je bereiken door je code te pushen naar een (online) repository waar de ander ook toegang toe heeft. Er zijn verscheidene online tools voor (zoals Bitbucket, GitHub etc.). Wij gebruikten Bitbucket (ook voor prive repo’s gratis) en na het instellen en de eerste push gaat dit heel gemakkelijk.

Met het commando

git push origin develop

kun je jouw lokale develop branch kopieren naar de online opslagplaats. De andere developer kan deze dan ophalen met commando

git pull

De normale workflow is om tegen de tijd dat een ander door moet gaan met jouw werk je code (na committen) te pushen en wanneer je start de laatste updates op te halen met een pull.

Deployment

Tot nu toe hebben we weliswaar gewerkt met git, verschillende branches gemaakt en code gedeeld (via Bitbucket) met een andere developer, maar alle code staat nog steeds alleen lokaal. Stel je voor dat de site klaar is voor gebruik, maar je deze eerst op een geisoleerde omgeving wilt zetten waar alleen jij en de klant bij kan. Daar is de stage omgeving voor. Als de definitieve site bijvoorbeeld op www.domeinnaam.nl komt te staan kun je de stage omgeving opzetten als subdomein, i.e., www.stage.domeinnaam.nl.

Ga nu naar de release branch en zorg dat de laatste commits van de develop branch (of die commits die het systeem in een testbare en stabiele toestand hebben gebracht) zijn gemerged. Nu kun je ofwel via FTP de code naar de stage omgeving kopieren (handmatig en dus foutgevoelig) ofwel kun je een deployment tool gebruiken. Zo’n tool (Google maar eens op deployment tools) kan bijvoorbeeld zodra je de release branch pusht naar Bitbucket de aanpassingen direct uploaden naar de staging site.

Wanneer de klant nu zijn akkoord heeft gegeven voor de livegang, kan de release branch in de master branch worden gemerged en kan de master site naar de live site worden gestuurd. Dit doe je typisch wel met de hand omdat je niet wilt dat de livesite automatisch wordt geupdate na een mogelijk foutieve commit!

De WordPress database

Tot nu toe hebben we het gehad over het samenwerken en synchronizeren van de code van de site. In het geval van WordPress is er ook nog een database waarin naast je berichten en afbeeldingen, je configuratie van de site zit. Wanneer je via het backend van WordPress een aanpassing maakt (bijvoorbeeld in de instellingen van een plug-in of de algemene instellingen van je site), dan worden er aanpassingen in de database doorgevoerd. Ook deze aanpassingen moet je collega developer hebben om de volgende keer op hetzelfde punt waar jij bent gestopt door te kunnen werken. Wij gebruiken de WordPress premium plug-in van Delicious Brains: WP Migrate DB Pro. Met deze plugin kun je heel eenvoudig databases kopieren van de ene naar de andere server (ook lokaal). De plug-in is dus geinstalleerd op de lokale WordPress installaties, op de stage en live omgevingen.

We komen wel een issue tegen wat tot op heden nog lastig is. Stel je voor dat ik vandaag wat templates aanpas en een plugin update al werkend in de develop branch. De code is nog niet ver genoeg om te mergen met release, dus ik push slechts de develop branch. De database push ik niet naar release, want de bijbehorende code aanpassing heb ik nog niet gepusht. Dat betekent dat mijn collega die morgen verder gaat werken wel de nieuwe code heeft, maar niet de plug-in update. Dat is in dit voorbeeld niet zo erg, maar stel dat ik niet simpelweg een plug-in heb geupdate, maar voor onze eigen plug-in waar we mee aan het werk zijn wat tabellen heb aangepast of uitgebreid, dan is het van groot belang dat de andere developer ook die aanpassingen in zijn database krijgt om verder te kunnen werken op mijn eerdere code. De huidige oplossing is om dan toch maar een merge met release te doen en de database te pushen zodat in elk geval de code en database synchroon zijn op de stage omgeving. Als iemand hier een betere oplossing voor heeft dan horen wij die graag. Hetzelfde weerhoudt ons nu ook om tegelijk in het WordPress backend te werken omdat je beide aanpassingen maakt in de database.


Mijn Twitter profiel Mijn Facebook profiel
Pim Hooghiemstra Webdeveloper and founder of PLint-sites. Loves to build complex webapplications using Vue and Laravel! Laatste bericht
Sorting table dates in a Vue CLI project

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *