Versiebeheer & Uploads op centrale acceptatieomgeving; hoe?

[HendrikN]

Vervolg van: Versie beheer en werkwijze

Sinds enige tijd zijn wij (webontwikkelbedrijf met 14 man) deels overgestapt op versiebeheer (SVN), dit betekent dat zo'n 14 man een eigen VirtualBox/LAMP omgeving op de workstation heeft geïnstalleerd en er naar een centrale repository wordt gecommit. Wel maken we gebruik van een centrale MySQL-server waar al deze lokale webservers (en de acceptatieomgeving) naartoe connecten.

Op deze centrale repository staat een post-commit hook geïnstalleerd die na elke commit een export naar de acceptatieomgeving uitvoert. Op deze manier kunnen onze klanten op een regelmatige basis meekijken naar een (redelijk) stabiele versie met de laatste wijzigingen.

Opzich werkt dit allemaal prima, maar er is een uitzondering; de uploads-map. Wanneer klanten zelf (via ons CMS) bijvoorbeeld plaatjes of documenten uploaden op de acceptatieomgeving worden deze geïndexeerd door het CMS. Dit betekent dat er op de centrale MySQL-server referenties staan naar bestanden die alleen op de acceptatieomgeving te vinden zijn.

Een situatie voor ons is dat de (door de klant-toegevoegde bestanden) in de uploads-map worden toegevoegd aan de repository zodat deze ook verschijnen op de lokale webservers.

Ons gevoel ging vooral uit naar een aantal command's in een post-commithook die de uploads-map importeert naar de repository; helaas betekent dit ook weer dat er een post-commithook wordt uitgevoerd (een svn import is ook een commit ).

Hebben mensen ideeen over hoe zoiets is te implementeren? Wij zullen toch niet de enige zijn die op deze manier webdevelopen i.c.m. versiebeheer?

[LuCarD]

Ik heb hier geen ervaring mee....

Maar je zou in de post-commit hook een check kunnen maken of de directory upload word gecommit.
Zo ja, stop de post commit script en doe niks verder

[-FoX-]

Ik vind het een beetje vreemd dat er gewerkt wordt met een centale MySQL server. Dit houdt enerzijds ook in dat alle ontwikkelaars gebonden zijn aan deze centrale server en geen mogelijkheden hebben om zware wijzigingen door te voeren die nodig zijn voor het ontwikkelen?

Het zou me logischer lijken dat er een bepaalde folder structuur afgesproken wordt in het versiebeheer systeem (vb: etc/sql) en dat er daarin dan de nodige SQL files geplaatst worden, eventueel zelfs in sequentiële volgorde (vb: 01_cretabs.sql, 02_initdata.sql, etc). Deze SQL files worden dan bij elke nieuwe deployment uitgevoerd (als ze al dan niet veranderd werden).

Op die manier kan iedereen lokaal toch altijd met het laatste database schema werken, de nodige veranderingen aanbrengen; en blijft alles toch zo'n beetje geautomatiseerd?

[NetForce1]

Iedereen ontwikkeld dus op dezelfde database? Wordt het dan niet een grote zooi qua database-inhoud en schema-wijzigingen? Is het niet handiger om ieder developer, en dus ook de acceptatie-omgeving een eigen database te geven? Eventueel kan dat natuurlijk wel op een centrale server als je dat graag wilt.

[Janoz]

Het lijkt me sowieso een stuk voor de hand liggender om iig per omgeving een apart(e) database (account) te gebruiken. Alle ontwikkelaars werken dan op het ontwikkel account en de acceptatie omgeving verbind met het acceptatie account.

Sowieso wil ik nog wel een opmerking plaatsen. Alhoewel jullie erg goed bezig zijn vraag ik me af of jullie niet een omgeving missen. Persoonlijk zou ik liever hebben dat de acceptatie omgeving wat stabiel is. Wat jullie nu als acceptatie omgeving gebruiken lijkt mij een prachtige omgeving om op te testen, maar niet om op te accepteren. Het uitrollen op de acceptatie omgeving zou ik dan ook niet als post-commit hook implementeren, maar meer als een release script waarbij een speciviek (getaggde?) release naar acceptatie wordt gezet.

[HendrikN]

Janoz schreef op donderdag 18 februari 2010 @ 16:25:
Het lijkt me sowieso een stuk voor de hand liggender om iig per omgeving een apart(e) database (account) te gebruiken. Alle ontwikkelaars werken dan op het ontwikkel account en de acceptatie omgeving verbind met het acceptatie account.

Ik snap dat dit de ideale situatie zou zijn, maar onze klanten respecteren het altijd erg als ze al tijdens de ontwikkelfase een indruk kunnen krijgen van een echte gevulde site. Op deze manier houden we ook de looptijd van een project een stuk korter.

Daarnaast snappen de klanten ook dat deze omgeving niet een echte acceptatieomgeving is (onze domeinnaam van deze omgeving is behoorlijk descriptief) en vinden ze het eigenlijk nooit zo erg om hier en daar nog een error tegen te komen. Zo krijgen de klanten ook het gevoel dat er echt aan het project wordt gewerkt.

Sowieso wil ik nog wel een opmerking plaatsen. Alhoewel jullie erg goed bezig zijn vraag ik me af of jullie niet een omgeving missen. Persoonlijk zou ik liever hebben dat de acceptatie omgeving wat stabiel is. Wat jullie nu als acceptatie omgeving gebruiken lijkt mij een prachtige omgeving om op te testen, maar niet om op te accepteren. Het uitrollen op de acceptatie omgeving zou ik dan ook niet als post-commit hook implementeren, maar meer als een release script waarbij een speciviek (getaggde?) release naar acceptatie wordt gezet.

Op dit moment hebben wij een releasescript (d.m.v. Phing) om een project te uploaden naar onze productieomgeving. Als we zouden willen zou zoiets dus ook mogelijk zijn naar een "echte" acceptatieomgeving maar het liefst willen we dat dus niet.

In ieder geval bedankt tot zo ver voor de input, maar ik zoek nog steeds naar onze ideale oplossing

[Kalentum]

Dus elke ontwikkelaar bij jullie heeft een eigen ontwikkelomgeving maar een centrale database waarin de klanten ook testen?

Je zou dan, op het moment dat je in je ontwikkelomgeving bepaalde uploads mist, die uploads met behulp van rsync kunnen kopieren naar je eigen ontwikkelomgeving. Je krijgt dan alleen de nieuwe en gewijzigde uploads.

[Janoz]

Aangezien vooral het 'gevulde database' slaat op het eerste deel van mijn reactie zal ik daar zo verder op in gaan. De tweede opmerking die ik maakte was meer omdat ik zelf bij een acceptatie omgeving een ander beeld heb. Als het voor de klant duidelijk is wat de acceptatie omgeving bij jullie inhoud dan is dat natuurlijk geen enkel probleem.

Terugkomend op het gevulde database verhaal. Ik snap dat de client graag een gevulde site ziet. Wat ik niet snap is waarom dat een argument tegen verschillende databases is. Je zou toch kunnen beginnen met een kopie van een gevulde database? Vanaf daar kan de klant, maar ook de ontwikkelaar de boel compleet volstouwen zonder dat ze elkaar in de weg zitten. Het enige waar je nog rekening mee moet houden is dat je goede update scripts maakt voor wanneer de database wijzigd, maar dat zou je sowieso al moeten doen. het hebben van die acceptatie omgeving is vervolgens nog een prachtige test omgeving om ook daar nog eens de update scripts los te laten.

[GrooV]

Stel dat een programmeur een database wijziging doorvoert (Tabel wijzigen ofzo) dan zal het bij de andere 13man niet meer (goed)werken. Je kan beter iedereen op een eigen database latenwerken. SQL scripts in SVN zetten (of een ander versie beheer systeem) en deze moet iedereen dan uitvoeren als ze hun locale repo hebben geupdate.

Let wel op, je moet wel elke keer 2 scripts updaten. 1 groot script welke vanaf een lege database gedraaid kan worden en eentje welke vanaf een vorige revisie gedraaid kan worden

[Janoz]

GrooV schreef op vrijdag 19 februari 2010 @ 10:17:
Let wel op, je moet wel elke keer 2 scripts updaten. 1 groot script welke vanaf een lege database gedraaid kan worden en eentje welke vanaf een vorige revisie gedraaid kan worden

Dat is niet perse nodig. Het eerste script is immers niks anders dan het draaien van alle upgrade scripts achter elkaar. Ikzelf zou eerder afraden om 2 scripts te gebruiken. 2 verschillende dingen onderhouden die hetzelfde op moeten leveren gaat gegarandeerd fouten opleveren.

Het 'grote script' zou ik alleen per major release opbouwen. En dat opbouwen zou ik dan ook doen door een export te doen van een zojuist middels de update scripts gegenereerde database.