[Svnadmin] Van webserver naar webserver

[stixx]

Hier op mijn werk, willen we graag gebruik gaan maken van een svn server. Deze server is inmiddels geconfigureerd maar nu vragen we ons af hoe we het volgende mogelijk kunnen krijgen:

We willen namelijk alle aanpassingen die we doen gelijk opslaan naar webserver 1 (om zo nodig te testen) en pas als alles is goedgekeurd commiten naar webserver 2. Het probleem hierbij is dat we webserver 1 niet lokaal willen laten draaien. Is dit mogelijk om vanuit een IDE van een testserver naar een productieserver te commiten en zo ja hoe moet ik dit dan aanpakken?

[DiedX]

Ik denk dat een post-commit script het beste is voor jullie om direct je testserver te updaten. Het updaten van je productieserver kan je eventueel doen met 'svn update' op die server?

[stixx]

De bedoeling is eigenlijk als volgt:

- Iedere developer heeft zijn eigen versie op de test server in zijn eigen home dir dus bijv. /home/stixx
- Als je naar stix.development.test.nl gaat dan kan ik dus ontwikkelen aan mijn eigen versie
- Mijn wijzigingen commit ik dan naar de acceptatie omgeving, de repo dus en die is weer te bereiken onder development.test.nl

Van de testserver doen we weer een commit naar de productieserver.

Maar normaal kun je zoiets bijvoorbeeld als je lokaal LAMP draait zodat je het lokaal kan testen en dan committen naar de acceptatie. Alleen als hier elke pc met lamp uitgevoerd moet worden is ook niet echt de beste oplossing denk ik.

De bedoeling is dus dat ik vanuit mijn IDE (Zend Studio bijv) met ingebouwde FTP oid files bewerk in mijn home dir /home/stixx bijv. en dan het liefst vanuit mijn ide commit naar de acceptatie repo.

Iemand die het begrijpt of een idee heeft?

[krvabo]

Kun je niet gewoon een netwerkdrive gebruiken direct op de webserver? Dit vervangt dan dus de lokale lamp-setup bij je developers.

Je kunt dan gewoon als commit-url de acceptatie-repo opgeven.

Anders kun je nog wel iets fixen door een web-GUI te bouwen die je draait op server1, en via de website met een knopje/link wat acties uitvoert via shell op webserver1 om alles naar webserver2 te krijgen. Zo werkt in ieder geval 1 bedrijf waar ik heb gewerkt.

[DiedX]

Ik heb nog een paar keer over je tekst gelezen:

* Je centrale repository is dus development.*?
* Je bewerkt je uitgecheckte bestanden op /home/$username. Daarna commit je ze naar de lokale repo?

Vervolgens komt er nog 1 vaag stuk over het committen naar je acceptatieserver. Dit kan - zover ik weet - niet. Je commit naar development.*, maar niet naar development.* en acceptatie.*.

[Kalentum]

Committen != kopieren. Je kan niet iets committen naar een andere omgeving. Het lijkt nu net alsof jullie drie svn repositories hebben?
Je acceptatieomgeving kun je dan met svn update bijwerken. Als de acceptatietest OK is, kun je de code kopieren naar productie (of ook releasen vanuit Subversion).

Ik snap niet helemaal wat je probleem is. Ik werk ongeveer zo: er zijn drie omgevingen:
- Een developmentomgeving (Windows machine waar ik met vmware een LAMP-server (debian) op heb staan)
- Een testomgeving (extern gehoste LAMP-server)
- Een productie-omgeving (ook extern gehoste LAMP-server)

En daarnaast een SVN repository die vanaf elke omgeving te benaderen is.

Vanuit mijn IDE commit ik naar de Subversion repository. Als ik een bepaalde feature af heb, doe ik een 'svn update' op de testomgeving. Die wordt getest door een tester en als dat allemaal OK is doe ik een svn update op de productie.

Is zo'n opzet niet iets voor jullie?

[ReenL]

Je kunt voor elke gebruiker een samba share maken naar zijn directorie op de ontwikkel server.

Vervolgens de samba share mounten op de workstations van de developers.

Deze setup draaide ik vorig jaar, alleen Zend Studio was toen niet vooruit te branden, schijnt nu wel verbeterd te zijn.

Enige probleem is dat samba niet echt heel snel is. Netbeans heeft een oplossing waarbij hij een lokale kopie maakt van het project en over SFTP verstuurd naar de development server. Echter heb je dan geen svn functionaliteit in je IDE.

Er zijn ook verschillende manieren waarop je met SVN kunt werken. Zo zou je alle gebruikers een eigen branch kunnen geven.

Bij ons op werk doen we in principe alles op de trunk. Dus iedereen commit en checkt uit van de trunk. Vervolgens wordt besloten om iets op de test server te zetten en krijgt de test omgeving een svn up. Als dit getest en goedgekeurd is wordt er een tag aangemaakt.

Meer info:
http://stackoverflow.com/...tag-and-trunk-really-mean
http://svnbook.red-bean.c...04.html#svn-ch-5-sect-6.1

[djc]

stixx schreef op vrijdag 04 februari 2011 @ 18:12:
De bedoeling is eigenlijk als volgt:

- Iedere developer heeft zijn eigen versie op de test server in zijn eigen home dir dus bijv. /home/stixx
- Als je naar stix.development.test.nl gaat dan kan ik dus ontwikkelen aan mijn eigen versie
- Mijn wijzigingen commit ik dan naar de acceptatie omgeving, de repo dus en die is weer te bereiken onder development.test.nl

Van de testserver doen we weer een commit naar de productieserver.

Iedere dev zijn eigen test-omgeving (SVN working dir) op de dev-server klinkt logisch, daarna committen naar SVN lijkt me ook logisch. Een "commit doen" van de testserver naar de productieserver klinkt een beetje raar, het lijkt me logischer om daarvoor twee aparte SVN branches te gebruiken, waarbij de ene server een working dir van de ene branch draait en de andere server een working dir van de andere branch.

(Als je vraag is hoe je SVN servers in sync kunt houden, daarvoor kun je het best svnsync gebruiken.)

[Verwijderd]

Ik reageer ook even namens Stixx want dat is mijn collega. Hij heeft het probleem een beetje verkeerd uitgelegd. We doen op de productieserver als er een versie klaar is en getest is een checkout naar de laatste, geteste revisie.

De bedoeling -en de vraag ook meteen- is om iedere developer een eigen test omgeving te gevens. Dus kees.development.test.nl en stixx.development.test.nl bijvoorbeeld.

Wat ik zojuist geprobeerd heb is het volgende:

* Apache configureren dat de juiste url ook naar de home dir gaat van de user en geserveerd word
* In de home dir van de user een checkout van de laatste revisie
* In windows een SFTP share gemaakt met een programma (ExpanDrive)
* In NetBeans een project aangemaakt en verwezen naar de share

Dit werkt op zich goed, je kunt bestanden wijzigen en opslaan en dan meteen testen op de test server en als je het commit kan het getest worden op development.test.nl (als soort van acceptatie omgeving). Echter werkt het nog niet helemaal lekker en ik ben bang dat het komt doordat we een SFTP share gebruiken. NetBeans is bijvoorbeeld heel de tijd bezig met 'scanning for projects'..

Het doel is eigenlijk om versiebeheer te gebruiken (logisch) en dat iedere developer zijn eigen test omgeving is. Het lokaal draaien van LAMP vind ik erg bewerkelijk en kan om bepaalde redenen ook niet werken. Ik weet dat ze bij andere bedrijven ook op een remote server werken/testen en dan committen.

Zijn er developers die een soortgelijke omgeving hebben? En hoe hebben zij dit aangepakt?

[Kalentum]

Ik gebruik ook Expandrive maar dan in combinatie met Eclipse en Filesync (een Eclipse plugin). In mijn Eclipseproject geef ik aan dat de bestanden gesynchroniseerd moeten worden met een andere drive. Mijn working copy staat lokaal. Elke keer als ik in Eclipse een bestand opsla, toevoeg of verwijder wordt dat gesynchroniseerd met mijn T:\ drive, die gekoppelt is aan mijn homedirectory op de LAMP-server. Dus werken in de code doe ik lokaal, en elke wijziging wordt ook uitgevoerd op de LAMP-server. Ik gebruik een Subversion client in Eclipse, dus ook updaten en committen gebeurt vanuit de IDE. Dit werkt erg goed.

Ik weet niets van Netbeans maar het lijkt erop dat remote synchronization zit ingebouwd, zodat je Expandrive niet eens meer nodig hebt.

quote: http://blogs.sun.com/netb...ry/remote_synchronization

Seriously, from now, every change (create, edit, rename, delete) should be immediately propagated to your remote server.

[FragFrog]

Verwijderd schreef op zondag 06 februari 2011 @ 20:05:
Het doel is eigenlijk om versiebeheer te gebruiken (logisch) en dat iedere developer zijn eigen test omgeving is. Het lokaal draaien van LAMP vind ik erg bewerkelijk en kan om bepaalde redenen ook niet werken. Ik weet dat ze bij andere bedrijven ook op een remote server werken/testen en dan committen.

Volgens mij heb je al een aardig systeem nu. Dat het via SFTP traag gaat zou kunnen, de meeste bedrijven waar ik gewerkt heb gebruiken hiervoor samba shares. Dat werkt doorgaans prima, al heb ik het dan wel over samba shares in een lokaal netwerk.

Als snelheid echt vervelend wordt kun je eens kijken naar een SSD voor je SVN checkouts. Laatst eentje in mijn lokale developmentomgeving gezet, in plaats van tien, twintig seconden lopen wachten voor ik kan comitten gaat het nu ongeveer instant. Echt een verademing