Bij mij op het werk hebben we 2 manieren van werken:
SVNPer product hebben we de volgende mappen structuur in Subversion:
In Branches ontwikkelen we aan issues die in JIRA staan. De branches hebben het nummer van het issue in JIRA (in ons geval DEV-123). Iedere ontwikkelaar heeft een VM die op een server in het netwerk staat waarop ontwikkeld wordt. Aanpassen van code op de VMs doen we door middel van Samba shares.
Ook staat er in Branches een rc branch waar de DEV-branches naar gemerged worden. De rc is zoals de naam al doet vermoeden de release candidate voor de volgende release.
Wanneer de rc volledig is en deze gereleased gaat worden mergen we deze naar de Trunk. Daar staat het product zoals dat op dat moment is.
In Tags houden we de vorige versies van de producten bij.
We hebben bij klanten een productie en een TA (test/acceptatie) omgeving. Ongeveer 2 weken voor een release zetten we de rc op de TA omgeving zodat er met echte data van de klant getest kan worden. We laten de klant zelf hier ook op testen en gebruiken feedback van hen om bugs te kunnen fixen en kleine wijzigingen nog door te kunnen voeren. De release wordt daarna op de productieomgeving gezet.
Het updaten van de productie en TA-omgevingen doen we door middel van een SVN update. Door middel van PuTTY zetten we een tunnel op naar onze lokale Subversion server om de SVN update uit te kunnen voeren.
GitWe zijn pas net begonnen met Git, dus het is misschien allemaal nog niet volgens de regels. We draaien onze Git repositories bij Bitbucket omdat dit goed integreert met JIRA.
We hebben de volgende branches:
- master: Gebruiken we als rc branch. Door middel van Bitbucket pipelines worden zaken als phpunit automatisch gedraaid.
- staging: Deze branch deployed automatisch naar een staging server bij onze hoster zodat we op een echte omgeving kunnen testen. Over het deployen later meer.
- acceptance: Vergelijkbaar met de TA-omgeving zoals benoemd bij Subversion. Ook deze branch wordt automatisch gedeployed.
- production: De productie-omgeving, wordt wederom automatisch gedeployed.
- DEV-123: development branches. Wanneer ontwikkeling aan een branch klaar is maken we een pull request aan zodat deze naar de master gemerged kan worden.
We gebruik bitbucket pipelines om automatisch te deployen maar ook om zaken als phpunit te draaien. Pipelines werkt door middel van Docker containers. Aangezien de projecten die in Git staan enkel Laravel projecten zijn gebruiken we daar de laraedit container voor.
In de Git repo staat een bestand bitbucket-pipelines.yml die er ongeveer zo uit ziet (dit laat maar 1 branch zien):
image: laraedit/laraedit
pipelines:
branches:
acceptance:
- step:
script:
- composer install --no-progress
- wget http://deployer.org/deployer.phar
- chmod +x deployer.phar
- ./deployer.phar deploy acceptance
Voor het deployen maken we ook gebruik van
Deployer. Hiermee kun je in PHP opgeven welke stappen er uitgevoerd dienen te worden tijdens het deployen, zoals het aanmaken van mappen of het migreren van je database (php artisan migrate).
Op iedere server is een SSH private key gegenereerd die in Bitbucket pipelines bekend is waardoor deployer op de server kan inloggen over SSH en de gedefinieerde stappen uit kan voeren.
Zoals eerder benoemd hebben we in Git momenteel aan Laravel projecten staan. Om daarvoor te ontwikkelen hebben we een
homestead VM op onze laptops staan. De homestead image beheren door gebruik te maken van Vagrant (zoals eigenlijk iedereen die Homestead met Laravel gebruikt). Vagrant maakt het mogelijk om folders op je machine te mappen naar folders binnen de VM. Je past dus bestanden lokaal op je systeem aan en die bestanden zie je ook in de VM.
Heel verhaal, maar misschien dat iemand er iets aan heeft
zonder een idee te hebben wat je nog precies moet doen.
Mijn huidige project draait op twee servers: dev en main. De main is al via internet beschikbaar (de dev ook, maar dat weet niemand 
).
).
