[Subversion] De complete oplossing, hoe?

[Verwijderd]

Hallo mede GoT-ers,

Een tijdje terug heb ik voor collega's Subversion opgezet (Linux server). Daarvoor heb ik nooit met Subversion gewerkt, ik ben dus nog een "rookie"

Nu Subversion echt in gebruik wordt genomen lopen we tegen wat problemen aan. Ik zal hier het verhaal schetsen:

Mijn collega's zijn webdevelopers (Windows XP clients). Ze programmeren in PHP en gebruiken Subversion om er samen tegelijk aan te kunnen werken.
We maken gebruik van Branches, Tags en een Trunk directory.

Elke gebruikers heb ik een eigen Branch directory gegevens (Branches/<gebruikersnaam>) waaronder ze kunnen werken (copy van Trunk). Dit hebben we gedaan omdat gebruikers vaak in dezelfde files zitten te editen. Opzich werkt dit ook wel wanneer je één Branch gebruikt maar dan moet je bij elke commit opletten wat er gewijzigd is en dat samenvoegen.
Wanneer elke gebruiker een eigen Branch heeft kunnen ze telkens committen en wanneer iets echt "klaar" is kunnen ze het mergen met de Trunk (maar wat als de één een wijziging heeft gedaan in zijn eigen Branch, die gemerged is met de Trunk, en de ander heeft dit nodig om verder te kunnen in zijn al gewijzigde Working Copy?)

Hier zitten we momenteel op te broeden.. we weten niet precies hoe we het in moeten richten.

Tevens zitten we met het probleem hoe de websites te testen.
Momenteel heb ik een VMWare Virtual Machine gemaakt met Debian GNU/Linux. Hierop draait Apache, MySQL, phpMyAdmin.
Elke developer heeft deze machines lokaal staan.
Tijdens het booten van de Virtual Machines wordt de Working Copy van de Branch gemount op /var/www/. Hierdoor kunnen ze telkens testen. Het probleem wat je hierbij hebt is dat de rechten niet altijd goed staan (Windows Share gemount waarop je de Linux permissies niet kunt wijzigen/goed staan).

Kan dit ook anders?

Hopelijk wordt dit een levende discussie.. want helder is het mij nog niet

[Gonadan]

Zelf heb ik maar één branch gebruikt, je moet dan inderdaad conflicten oplossen maar dat geldt alleen als svn het zelf niet kan mergen, dat is eigenlijk nog amper voorgekomen.

Maar dat is nu een beetje te laat gok ik.

[user109731]

Verwijderd schreef op woensdag 13 juni 2007 @ 10:49:
Dit hebben we gedaan omdat gebruikers vaak in dezelfde files zitten te editen. Opzich werkt dit ook wel wanneer je één Branch gebruikt maar dan moet je bij elke commit opletten wat er gewijzigd is en dat samenvoegen.

Editen in hetzelfde bestand is meestal geen probleem, dat word netjes gemerged. Als de edits elkaar in de weg zitten heb je wel een conflict, maar ook die zijn volgens mij redelijk snel handmatig op te lossen en dat lijkt me handiger dan een complete branch achteraf te moeten mergen

edit: ongeveer wat ^^ zegt dus

[GX]

Het idee is juist dat je in de trunk werkt en branches gebruikt voor grondige wijzigingen e.d. Anders zou je allemaal net zo goed zelf een kopie kunnen maken en af en toe alles samenvoegen en afvragen wat er nu gebeurd is..

[BCC]

SVN gaat niet je conflicten oplossen, het maakt het mogelijk om zelf een proces rond je versiebeheer op te zetten.

Wanneer er features nodig zijn die op elkaar nodig hebben, dan is het veel logischer omdat met twee programmeurs in dezelfde branch te doen. Moeten dan altijd alle programmeurs maar alles in de trunk gaan doen? Nee. Wie bepaald dan wanneer je moet branchen en wanneer niet? Daar ben jezelf de aangewezen persoon voor. Bekijk wat je wilt ontwikkelen en wat de impact ervan gaat zijn. Is het erg als de trunk breekt? Is het handig als ik dit op mijn eigen houtje in een losse branch ontwikkel? SVN gaat je helpen als je iets besloten hebt, meer niet.

En kijk eens naar xampp voor amp development onder windows.

[ Voor 4% gewijzigd door BCC op 13-06-2007 12:07 ]

[Verwijderd]

Hmm ok... je kan dus samen gaan werken in de Trunk en wanneer je een grote wijziging wil gaan doorvoeren is het slim om een Branch op te bouwen (als ik het goed heb).

Heb zonet even getest hoe het gaat wanneer je met 2 personen dezelfde file gaat editen. Dit gaat erg goed moet ik zeggen. Ook wanneer er conflicten zijn is de mergetool duidelijk.

We gaan eerst maar werken met één Trunk.

[Beowulff]

Het is juist de bedoeling van subversion dat je bij elke commit oplet wat er gewijzigd is en dan alles samenvoegt. Subversion's taak is het om het je makkelijk te maken om jouw working copy te mengen met de wijzigingen die je collega's hebben aangebracht sinds you het voor het laatst hebt opgehaald (svn update). Eigenlijk (zoals anderen al hebben aangegeven) heb je branches eigenlijk zelden nodig, tenzij je echt lange-termijn wijzigingen aan het doen bent (zeg in de orde van enkele weken i.p.v. enkele dagen), voor de rest is de gewone svn work cycle meestal voldoende (checkout, edit, update, commit).

Wat betreft je VMs: je zou die ook in je subversion archief kunnen stoppen, of in ieder geval de scripts die automatisch de site op de VM installeren. Op die manier kun je daarin dus bijvoorbeeld de rechten aanpassen waar nodig, en dit ook nog eens onder versiebeheer houden.

[Verwijderd]

Beowulff schreef op woensdag 13 juni 2007 @ 13:05:
Wat betreft je VMs: je zou die ook in je subversion archief kunnen stoppen, of in ieder geval de scripts die automatisch de site op de VM installeren. Op die manier kun je daarin dus bijvoorbeeld de rechten aanpassen waar nodig, en dit ook nog eens onder versiebeheer houden.

Dit gaat niet werken... want waarschijnlijk bedoel je het gebruik van Hook scripts.
Een post-commit hookscript kan de VM updaten met de nieuwe files maar we willen dus eerst de Working Copy testen en als het daar werkt, dan past commiten naar de Trunk.

[GX]

Op m'n werk hebben we altijd 3 omgevingen:

* Ontwikkel: Hier zit de eigen programmeur
* Zandbak: met post-commit automatisch checkout op een testlocatie
* Productie: Handmatig wegzetten van de code

Dat laatste doen we dmv releases in tags (eigenlijk branches, we zijn te lui om tags te gebruiken ) en doen we alleen als de zandbak goed werkt. Dit lijkt nu eigenlijk bijna altijd goed te gaan

[Verwijderd]

GX schreef op woensdag 13 juni 2007 @ 13:43:
Op m'n werk hebben we altijd 3 omgevingen:

* Ontwikkel: Hier zit de eigen programmeur
* Zandbak: met post-commit automatisch checkout op een testlocatie
* Productie: Handmatig wegzetten van de code

Over wat voor omgevingen heb je het hier?
Zijn dit 3 repositories? En heb je per ontwikkelaar dan ook weer een repository?

[Beowulff]

Verwijderd schreef op woensdag 13 juni 2007 @ 13:37:
[...]


Dit gaat niet werken... want waarschijnlijk bedoel je het gebruik van Hook scripts.
Een post-commit hookscript kan de VM updaten met de nieuwe files maar we willen dus eerst de Working Copy testen en als het daar werkt, dan past commiten naar de Trunk.

Hook scripts had ik niet aan gedacht, ik zat eigenlijk meer te denken aan een deployment script. Iedere developer heeft toch een eigen VM? Zie dit als een working copy van de VM. Dit deployment script installeert dan de website op de juiste plek in die VM met de juiste rechten (eventueel na de directory eerst leeg gemaakt te hebben). Dit script kun je bijvoorbeeld aanroepen na elke checkout of update, vanuit je make file/ant file/automatisch test script of gewoon met de hand. Dit script moet dan gewoon onder versiebeheer staan, want ongetwijfeld moet je het af en toe aanpassen als je dingen verandert aan de site. Pas als de gebruiker tevreden is met hoe de site reageert op zijn eigen, lokale VM wordt de boel gecommit. Niets houdt je natuurlijk tegen om dit script ook uit een post-commit hook aan te roepen om de nieuwste versie automatisch op een centrale VM of test server te installeren, en hetzelfde script zou je kunnen gebruiken om de site uit te rollen op een productie server, als je zover bent.

[Verwijderd]

Beowulff schreef op woensdag 13 juni 2007 @ 14:54:
[...]
Iedere developer heeft toch een eigen VM? Zie dit als een working copy van de VM. Dit deployment script installeert dan de website op de juiste plek in die VM met de juiste rechten (eventueel na de directory eerst leeg gemaakt te hebben).

Wacht even... iets heb ik nog niet duidelijk in dit verhaal (zie vet gedrukt). Waar doe je nu de checkout (Working Copy)?
Momenteel doen we deze lokaal op de C: schijf (met een sync script die bij het afsluiten van Windows een kopie maakt naar de Windows Server zodat deze mee wordt genomen op tape).

Deze Working Copy gaan we delen zodat vanuit de VM deze share gemount kan worden op /var/www/.

[Beowulff]

Verwijderd schreef op woensdag 13 juni 2007 @ 15:09:
[...]


Wacht even... iets heb ik nog niet duidelijk in dit verhaal (zie vet gedrukt). Waar doe je nu de checkout (Working Copy)?
Momenteel doen we deze lokaal op de C: schijf (met een sync script die bij het afsluiten van Windows een kopie maakt naar de Windows Server zodat deze mee wordt genomen op tape).

Deze Working Copy gaan we delen zodat vanuit de VM deze share gemount kan worden op /var/www/.

Hmm, ok, daar zit dus de spraakverwarring - ik ging er dus vanuit dat iedere developer een eigen VM heeft, met eigen data - niet met data uit een of andere gesharede directory. Ik denk niet dat dat goed gaat werken - hoe kan een developer dan testen hoe zijn wijzigingen eruitzien vóór die commit? Want committen moet je alleen maar doen als je tevreden bent met wat je gewijzigd hebt - en op die manier houd je dus een trunk die altijd naar tevredenheid is. Dat is het idee achter versiebeheer met subversion.

Dus geeft elke developer zijn eigen VM (waarschijnlijk is het een goed idee om de configuratie van die VM in subversion op te slaan, zodat iedereen altijd de laatste versie van die VM heeft, en eventuele wijzigingen aan de VM ook weer kan delen met collega's) en op die VM kan de developer dan naar hartelust zijn eigen wijzigingen testen.

Neemt niet weg dat het een goed idee is om een share of een server aan te wijzen als referentie, waarop je via een post-commit script altijd de laatste stabiele versie hebt staan. Dan kan iedereen zijn wijzigingen daarmee vergelijken. Ook zou je zo'n centrale VM of server kunnen voorzien van allerlei test scripts die je al dan niet automatisch wil runnen, bijvoorbeeld elke nacht.

[GX]

Verwijderd schreef op woensdag 13 juni 2007 @ 13:46:
[...]


Over wat voor omgevingen heb je het hier?
Zijn dit 3 repositories? En heb je per ontwikkelaar dan ook weer een repository?

"Locaties" waar het geproduceerde heen gaat. In ons geval is het één repository (per product, site of programma maken we een repository) die altijd op alle 3 de locaties voorkomt. Één voor ontwikkeling, één voor testen en één voor productie, werkt prima.

[Verwijderd]

Beowulff schreef op woensdag 13 juni 2007 @ 15:59:
[...]
ik ging er dus vanuit dat iedere developer een eigen VM heeft, met eigen data

Om het iets duidelijker te maken:
- Elke developer heeft een eigen Windows XP werkstation
- Elke developer heeft bovenop zn Windows XP een eigen Virtual Machine met Debian GNU/Linux
- Wanneer een developer een Checkout heeft gedaan (en dus een Working Copy heeft) wil hij de wijzigingen kunnen testen voordat het gecommit wordt. Je moet dus je Working Copy op één of andere manier in de Virtual Machines zien te krijgen. Dit kun je inderdaad met een script doen die alles "upload" naar je VM maar dan moet je elke keer voordat je wilt testen handmatig het script starten. Dat is niet de bedoeling. Vandaar dat ik er aan zat te denken de Working Copy op Windows XP te sharen en deze te mounten in de VM. Ik zie nog niet in hoe ik het goed voor elkaar kan krijgen.

PS: ik gebruik een VM om de Windows XP station "schoon" te houden. Wanneer je XAMPP gebruikt staat er gelijk weer veel "troep" op je systeem.

[DJ Buzzz]

Een hele andere oplossing om het wat centraler aan te pakken. Je maakt een centrale linux fileserver waarbij je de productieomgeving zo veel mogelijk reproduceert. Verder exporteer je hierop via Samba de home directories en via b.v. http://server/~username kan iedereen daar ook bij via de webserver.

Het enige nadeel hiervan is dat je ervoor moet zorgen dat de applicaties die je maakt netjes om moeten kunnen gaan met het feit dat ze niet altijd in de root directory van een VirtualHost staan. Maar goed, een goeie applicatie heeft hier natuurlijk ook geen problemen mee .

Als je in deze setup permissie problemen krijgt, zullen deze ook meestal in dezelfde vorm op productie voorkomen (omdat je ook een soort shared hosting systeem hebt). Dit geeft je dus extra informatie over wanneer zaken mis kunnen gaan bij het remote installeren.

Verder zou ik ook sterk adviseren het deployment proces te automatiseren. Elke keer als je tijdens het developen een probleem tegen komt, dit expliciet in code / script vorm fixen en in je deployment script gooien. Zo kun je zaken automatiseren en ga je geen dingen vergeten.