[SVN]Versioning van LAMP project

[mithras]

Hallo allemaal,
Op dit moment ben ik met een groepje aan het ontwikkelen aan een CMS. Er staat niets in svn en dat wil ik veranderen. De huidige manier van werken is dat we een "live" cms hebben en een "dev" cms. Beide hebben eigen url, map, aparte ftp account en eigen database. Iedereen rommelt wat in de dev en wanneer het voldoende functioneel is gaat het "live". Dit is verre van ideaal.

Ik wil graag in svn aan de slag waarbij alle ontwikkelaars eigen functionaliteiten kunnen ontwikkelen in eigen branches. Deze gebruikers moeten ook een eigen plek hebben om, voordat ze committen, te kunnen testen of het wel werkt. Dat wilde ik doen met de userdir mod van Apache. De daarin geteste code kunnen ze submitten naar de eigen branch en later ook weer mergen met trunk.

Nu zit ik met een probleem van de database. Ik heb [PHP / SVN] Versiebeheer databaseschema's gezien, maar kom er niet uit hoe ik het beste de database versies kan bijhouden. Alle ontwikkelaars moeten dus een eigen database checkout doen. Wanneer ze het cms testen, moet er een database beschikbaar zijn voor ze.

Ik heb oplossingen gezien van database versioning waarbij ze met xml documenten werkte, maar dit lijkt me niet ideaal: je zal het keer op keer weer moeten importeren en mysql ermee updaten.

Hoe is deze workflow het beste te regelen? Is er een oplossing voor mijn database probleem? Of zit ik uberhaupt op de verkeerde manier te denken?

[Janoz]

De eerste knop die je om moet zetten is de gedachte dat je altijd tegen dezelfde database aan moet werken. In een ontwikkelomgeving is het heel normaal om je hele db te droppen en opnieuw te genereren. Je database schema neem je dus mee in je versiebeheer. Naast je schema sla je ook je stamgegevens op en wat dummy gegevens zodat een developer gelijk met een wat gevulde database aan de slag kan.

Naast het genereer script zul je je ontwikkelaars ook een conversie script moeten laten maken. Dit is een script dat de database vanaf een bepaalde versie naar een andere versie update. Het testen hiervan is redelijk simpel aangezien je in je versiebeheer wel een compleet gevulde database van de vorige versie hebt. Hierop laat je je conversie los en kijk je of alles in de nieuwe versie goed werkt.

Tot slot nog een opmerking over het branchen. Ik wil je aanraden om dit niet per developer te gaan doen. Ten eerste reflecteerd de branche dan niet wat er veranderd wordt, maar wie dat doet. Ook kunnen meerdere devvers dan niet aan dezelfde taak werken en tot slot mis je dan veel van de voordelen van versie beheer.

Branchen zou ik sowieso per versie doen en eventueel per (grote) taak. Het hoeft helemaal geen probleem te zijn dat meerdere developers elk in een eigen checkout van dezelfde branch werken.

[matthijsln]

Janoz schreef op maandag 12 januari 2009 @ 10:56:
Tot slot nog een opmerking over het branchen. Ik wil je aanraden om dit niet per developer te gaan doen. Ten eerste reflecteerd de branche dan niet wat er veranderd wordt, maar wie dat doet. Ook kunnen meerdere devvers dan niet aan dezelfde taak werken en tot slot mis je dan veel van de voordelen van versie beheer.

Branchen zou ik sowieso per versie doen en eventueel per (grote) taak. Het hoeft helemaal geen probleem te zijn dat meerdere developers elk in een eigen checkout van dezelfde branch werken.

Branchen betekent ook mergen. Als iedereen in de trunk werkt merge je bij iedere commit eigenlijk ook, maar omdat dat veel vaker en met kleinere wijzigingen (en - verplicht) gaat, is dat beter bij te houden voor iedereen.

[Janoz]

Precies, helemaal mee eens.

Er zijn echter enkele uitzonderingen. Vooral grote aanpassingen of aanpassingen waarbij de kans redelijk groot is dat ze helemaal niet doorgevoerd gaan worden zou ik wel in een branche doen. Om er voor te zorgen dat de merge niet een hel wordt blijft het dan wel handig om regelmatig de trunk met je branch te blijven mergen.

[mithras]

Ja, ik zal natuurlijk kleine wijzigingen in de trunk doorvoeren, maar er zijn een aantal personen bezig aparte modules te ontwikkelen die sommige functionaliteiten kunnen breken.

Ik zit nu ook verder te kijken naar LiquiBase, wat er op het eerste gezicht wel goed uitziet. Helaas blijft de ontwikkeling van een IDE (als Eclipse plugin) nogal achter, waardoor dat voor ons nog niet echt bruikbaar is lijkt me (programmeurs zijn nu niet zo ervaren, ik wil niet alles 100x moeten voordoen ).

Zijn er andere systemen die wel goed zijn in dit soort dingen (liefst geïntegreerd in Eclipse)? In ieder geval bedankt voor het meedenken

[Janoz]

Als mensen met aparte modules bezig zijn dan zie ik niet in waarom dat elkaar in de weg zou kunnen lopen eigenlijk. Je moet goed beseffen dat mensen misschien wel op dezelfde branch zitten, maar dat betekent niet dat ze ook daadwerkelijk met dezelfde fysieke bestanden bezig zijn.