Versie beheer en werkwijze

[orf]

Op dit moment werken wij als webontwikkel bureau niet met versiebeheer. We bouwen websites met PHP en MySQL en gebruiken hiervoor een IDE (PhpEd). We willen graag versiebeheer gaan gebruiken, maar tot nu toe zijn we tegen te veel dingen opgelopen waardoor we het niet gebruiken.

We zien de voordelen van versie beheer in, maar we willen er niet té veel nadeel van ondervinden in onze dagelijkse werkzaamheden.

Huidige situatie:
Nu hebben we een Small Business Server als domain controller, 14 PC’s met Windows Vista en een Linux ontwikkelserver in een gigabit netwerk. De home partitie van de ontwikkelserver is op iedere PC beschikbaar als netwerk locatie met een stationsletter.

Alle projecten hebben op de ontwikkelserver een eigen map en zijn een subdomein op het intranet.
Wanneer iemand een nieuwe website gaat bouwen, runt hij de installer zodat het CMS op de ontwikkelserver geïnstalleerd wordt. In zijn IDE maakt hij een nieuw project aan, waarbij wordt aangegeven dat de bestanden op de netwerk locatie staan.

De developer start met ontwikkelen van de website en bekijkt het resultaat in een browser. Elke wijziging wordt direct toegepast. Als we iets hebben wat we aan een klant willen tonen, dan kunnen we een subdomein beschikbaar maken voor de buitenwereld.

Wanneer de developer klaar is met ontwikkelen, maakt hij in ons administratiepakket een account aan. Op één van de live webservers wordt dat account aangemaakt en gekoppeld aan een domein.
De FTP gegevens stelt hij in in zijn IDE en met FTP wordt de website naar de live server geüpload.

Versie beheer
In de huidige situatie ontbreekt Source Control volledig. We hebben min of meer besloten om hier Subversion voor te gaan gebruiken. We hebben aardig wat tests en onderzoek gedaan en kwamen tot nu toe niet tot een heel goed werkbare situatie.

We hebben getest met een SVN server op de Linux ontwikkelserver. Een check-out maakt een ‘local’ working copy naar de netwerk share (op dezelfde ontwikkelserver). Probleem hierbij is dat uitchecken, committen, e.d. met de geteste client (Tortoise SVN) dit onwerkbaar traag is. Alles gaat van ontwikkelserver naar client PC en terug naar de ontwikkelserver. Wanneer we via Putty commandline de acties uitvoeren op de ontwikkelserver is alles wel snel. Maar ook dit is niet bepaald fijn werken: putty starten, inloggen op de server, commando’s uitvoeren.

Mogelijke oplossingen
We hebben gezocht naar een vervangende client voor Tortoise. We willen de acties direct uitvoeren op de server. Hiervoor heb ik geen geschikte client kunnen vinden, maar we denken dit zelf wel snel te kunnen maken. De werking zal dan ongeveer hetzelfde zijn als Tortoise, zonder de icoontjes op bestanden en mappen die de status aangeven.

Een andere oplossing is dat iedere developer de local working copy naar zijn eigen PC haalt en daarop werkt. Om te testen moet op de Windows PC dan een webserver draaien. In een Windows omgeving is dit niet ideaal vanwege verschillen tussen Windows en Linux. (include path, bestandspaden, Shell exec, etc). Een mogelijkheid is om op elke PC een virtual machine te draaien met daarop Linux en een webserver. De databases kunnen wel op de ontwikkelserver blijven draaien, zodat je geen problemen hebt met verschillende databases op de eigen PC en de ontwikkelserver (Database versiebeheer is sowieso nog wel een punt).
Wanneer een developer een commit doet op SVN, kunnen we automatisch een script laten draaien die de bestanden uit de repository rsynct met een map op de ontwikkelserver zodat daar ook altijd een werkende versie van de website staat.

Heeft iemand hier een mening over? We moeten iets met versie beheer en SVN lijkt een geschikt pakket om dit te gaan doen. Doordat we met SVN dingen kunnen automatiseren wordt bijvoorbeeld het live zetten van een website een stuk makkelijker. Ook kunnen we vrij makkelijk een acceptatie-omgeving inrichten, die met een druk op een knop geüpdate wordt.

Zijn er dingen waar ik nog niet aan gedacht heb die een mogelijke oplossing zijn voor versie beheer? Is het omgooien van onze huidige werkwijze (van centrale ontwikkelserver naar 14 lokale testservers) een goed idee?

[Kalentum]

orf schreef op woensdag 28 oktober 2009 @ 14:50:
Zijn er dingen waar ik nog niet aan gedacht heb die een mogelijke oplossing zijn voor versie beheer? Is het omgooien van onze huidige werkwijze (van centrale ontwikkelserver naar 14 lokale testservers) een goed idee?

Je gaat dan naar 14 lokale ontwikkelservers en dat lijkt me heel goed: elke developer werkt in zijn eigen omgeving, ook met een eigen database. Het ontwikkelen (en ook testen) kun je het beste doen in een omgeving die hetzelfde is als je productie. Als dat Linux is en je wilt niet volledig gaan werken met Linux dan is een VM een prima oplossing.

Ik werk zelf met Eclipse PDT onder Windows en daar kun je Subversion in gebruiken. Ik heb een tooltje in Eclipse die elke keer als ik een bestand opsla dit kopieert naar mijn Linux VM en dat werkt prima. Subversion werkt dus lokaal maar het debuggen en testen gebeurt onder Linux.

Als je op 0 begint met versiebeheer zou ik zeker overwegen om iets hippere versiebeheersystemen te evalueren zoals git en mercurial.

[Tharulerz]

In Visual Studio 2008 bestaat er een client VisualSVN, die nog een laag is op tortoise...

Deze gebruik ik altijd als ik develop in visual studio, en nog nooit problemen gehad met snelheid (duurt hoogstens 2-3 seconden om een heel project te committen of check out te doen).

Misschien moet je eens kijken of er geen tooltjes bestaan voor de IDE die je gebruikt, ipv dit zelf te gaan maken?

[Tubby]

rutgerw schreef op woensdag 28 oktober 2009 @ 15:37:
[...]
Je gaat dan naar 14 lokale ontwikkelservers en dat lijkt me heel goed: elke developer werkt in zijn eigen omgeving, ook met een eigen database. Het ontwikkelen (en ook testen) kun je het beste doen in een omgeving die hetzelfde is als je productie. Als dat Linux is en je wilt niet volledig gaan werken met Linux dan is een VM een prima oplossing.

Ik werk zelf met Eclipse PDT onder Windows en daar kun je Subversion in gebruiken. Ik heb een tooltje in Eclipse die elke keer als ik een bestand opsla dit kopieert naar mijn Linux VM en dat werkt prima. Subversion werkt dus lokaal maar het debuggen en testen gebeurt onder Linux.

Als je op 0 begint met versiebeheer zou ik zeker overwegen om iets hippere versiebeheersystemen te evalueren zoals git en mercurial.

Elke ontwikkelaar zijn eigen lokale omgeving is een goed uitgangspunt omdat andere dan geen last hebben van zijn ontwikkelfoutjes, een ontwikkelaar zal zijn set van wijzigingen pas committen als het voldoende werkt. De huidige ontwikkelserver krijgt dan meer functie in de hoek van test of acceptatie omgeving.

Het is overigens wel zinvol om een buildserver in te richten die op basis van de svn repository (semi)automatisch de acceptatie omgeving bijwerkt met de meest recente versie. Deze build server kun je zo inrichten dat je geen last hebt van de omgeving's specifieke dingen (paden e.d.). Hudson is een goede buildserver imho.

Als het decentraal werken echt een issue is kun je eventueel overwegen om met build scripts de lokale omgeving naar de server te uploaden (via ftp of samba). Dat duurt afhankelijk van het aantal wijzigingen ook maar een paar seconde over het algemeen. Binnen eclipse is goede integratie voor Ant build scripts.

[ Voor 9% gewijzigd door Tubby op 28-10-2009 16:02 . Reden: aanvulling mbt ant scripts ]

[AtleX]

orf schreef op woensdag 28 oktober 2009 @ 14:50:
We hebben getest met een SVN server op de Linux ontwikkelserver. Een check-out maakt een ‘local’ working copy naar de netwerk share (op dezelfde ontwikkelserver). Probleem hierbij is dat uitchecken, committen, e.d. met de geteste client (Tortoise SVN) dit onwerkbaar traag is.

SVN maakt in de huidige versie tientallen, zoniet honderden tempfiles aan. Dat gaat nu eenmaal erg traag over een netwerk. In SVN 1.7 komt er een soort SQLite database die de locks gaat beheren maar die versie komt pas ergens halverwege volgend jaar verwacht ik.

Ik zou gewoon voor de local development servers kiezen, ook als SVN 1.7 uit is. Het is voor ontwikkelaars veel handiger om lokaal te kunnen ontwikkelen en testen zonder rekening te hoeven houden met de andere developers. 1 Fout van een programmeur gooit dan niet de dev-omgeving van alle ontwikkelaars plat. Ook ga je met meerdere ontwikkelaars op 1 working copy een beetje voorbij aan het hele idee achter versiebeheer.

[ Voor 5% gewijzigd door AtleX op 28-10-2009 16:02 ]

[orf]

Dank voor de antwoorden
Ik ga een lokale testomgeving zeker overwegen. Developers sputteren nogal tegen als ik ze vertel over een virtual machine en een verandering van werkwijze, maar ik snap dat de local (maar toch niet local) working copy op een server share gewoon geen handige werkwijze is. Versiebeheer wordt dan niet afgedwongen en iederen zal er wel eens omheen werken. Iets wat ik juist wil voorkomen.

De centrale testserver heeft tot nu toe (en we bestaan al een flink aantal jaar) nog nooit echt voor problemen gezorgd. Met PHP krijg je een server niet zo snel omver. Je ziet hoogstens een parse error in je eigen script. In combinatie met versie beheer zal het gewoon niet goed werken en moeten we een alternatief.

rutgerw schreef op woensdag 28 oktober 2009 @ 15:37:
[...]Als je op 0 begint met versiebeheer zou ik zeker overwegen om iets hippere versiebeheersystemen te evalueren zoals git en mercurial.

Waarom zou ik die overwegen? Beter, sneller, leuker?

[mithras]

Je zou inderdaad ook git eens kunnen bekijken. Allereerst is het sneller en werkt het iets eenvoudiger (je kan gemakkelijker mergen, check out doen etc). Daarnaast heeft svn in elk mapje een .svn map staan met tientallen bestandjes. Grote projecten worden dus erg langzaam over het netwerk, dat heb je zelf ook gemerkt. Met git zou je hier veel minder last van hebben.

Wat je zou kunnen doen is op je Linux bak een share maken voor elke ontwikkelaar. Die kan daar eigen spul testen en via het netwerk alles benaderen. Dat zet je in git, waar je ook een centrale repository van hebt. Kan je over het netwerk ontwikkelen (geen vm nodig), maar zit je wel met versiecontrolebeheer.

[Herko_ter_Horst]

Hip is niet persé beter natuurlijk (leuker misschien wel, i.i.g. om een keer mee te spelen ). Ik zie de voordelen van die distributed version control systemen niet zo voor een relatief klein team dat helemaal niet distributed werkt. Bovendien is de tool support in IDE's voor die nieuwe systemen nog lang niet op niveau.

[orf]

Tubby schreef op woensdag 28 oktober 2009 @ 15:58:
[...]Als het decentraal werken echt een issue is kun je eventueel overwegen om met build scripts de lokale omgeving naar de server te uploaden (via ftp of samba). Dat duurt afhankelijk van het aantal wijzigingen ook maar een paar seconde over het algemeen. Binnen eclipse is goede integratie voor Ant build scripts.

Dit had ik even gemist.
Wat je omschrijft klinkt niet heel gek. De ontwikkelaar werkt lokaal aan de bestanden, maar de wijzigingen worden direct doorgevoerd op de centrale testserver. Dat ligt dichtbij de huidige werkwijze, terwijl versiebeheer op deze manier wel goed mogelijk is. Goed om ook te overwegen

mithras schreef op woensdag 28 oktober 2009 @ 17:36:
Je zou inderdaad ook git eens kunnen bekijken. Allereerst is het sneller en werkt het iets eenvoudiger (je kan gemakkelijker mergen, check out doen etc). Daarnaast heeft svn in elk mapje een .svn map staan met tientallen bestandjes. Grote projecten worden dus erg langzaam over het netwerk, dat heb je zelf ook gemerkt. Met git zou je hier veel minder last van hebben.

Git ga ik zeker nog even bekijken. Zojuist al even over gelezen en het lijkt erop dat dit wel wat sneller is.

Wat je zou kunnen doen is op je Linux bak een share maken voor elke ontwikkelaar. Die kan daar eigen spul testen en via het netwerk alles benaderen. Dat zet je in git, waar je ook een centrale repository van hebt. Kan je over het netwerk ontwikkelen (geen vm nodig), maar zit je wel met versiecontrolebeheer.

Op deze manier centraal werken scheelt weinig van hoe we nu doen. De Git commando's zullen we dan via Putty uit moeten voeren toch?

[Bryan Tong Minh]

Je kunt een locale checkout op de server maken, en die met een post-commit hook automatisch laten updated. Dit gebeurt geheel serverside, dus het schilt je een roundtrip.


Bryan

[Kettrick]

Volgens mij is git vooral bedoeld voor enorme projecten als bijvoorbeeld de linux kernel, waarbij patches heen en weer gaan tussen verschillende maintainers, om ook de "chain of command" te waarborgen.

Hoewel dat best leuk is moet je je afvragen of het nodig is voor 14 man, volgens mij is svn juist voor deze scenario's een betere tool.

[mithras]

RoeLz schreef op donderdag 29 oktober 2009 @ 14:34:
Volgens mij is git vooral bedoeld voor enorme projecten als bijvoorbeeld de linux kernel, waarbij patches heen en weer gaan tussen verschillende maintainers, om ook de "chain of command" te waarborgen.

Hoewel dat best leuk is moet je je afvragen of het nodig is voor 14 man, volgens mij is svn juist voor deze scenario's een betere tool.

Git is dan wel een distributed vcs, dat betekent niet dat je het in de TS de situatie niet kan gebruiken.

Punt is dat svn een hele hoop metadata genereert en (afaik) git dit veel minder doet. Als TS merkt dat svn traag wordt omdat het over het netwerk loopt, is dat natuurlijk logisch. Een oplossing is een vm gebruiken om te ontwikkelen. Een alternatief is om bijvoorbeeld eens git te testen. Git is daarnaast nieuwer, sneller en volgens een behoorlijk aantal ontwikkelaars makkelijker om mee te werken (minder commands voor hetzelfde doel). Helaas is de integratie met "oude" IDE's een stuk minder.

Het is gewoon een afweging tussen de verschillende opties die gemaakt moet worden

[Kettrick]

mithras schreef op donderdag 29 oktober 2009 @ 16:55:
[...]
Git is dan wel een distributed vcs, dat betekent niet dat je het in de TS de situatie niet kan gebruiken.

Ik zeg ook niet dat het niet kan, ik zeg alleen dat het er niet echt voor gemaakt is .

Punt is dat svn een hele hoop metadata genereert en (afaik) git dit veel minder doet. Als TS merkt dat svn traag wordt omdat het over het netwerk loopt, is dat natuurlijk logisch. Een oplossing is een vm gebruiken om te ontwikkelen. Een alternatief is om bijvoorbeeld eens git te testen. Git is daarnaast nieuwer, sneller en volgens een behoorlijk aantal ontwikkelaars makkelijker om mee te werken (minder commands voor hetzelfde doel). Helaas is de integratie met "oude" IDE's een stuk minder.

Juist het hele distributed verhaal van git maakt het in mijn optiek was lastiger als svn. Ik ken git verder niet heel erg goed, een een uurtje naar gekeken dus misschien heb ik het wel helemaal mis hoor . De metadata van svn is inderdaad wat lomp, maar ik heb dat zelf nooit als storend ervaren eigenlijk. Verder heb ik svn ook nooit als traag ervaren, een checkout van een enorm project duurt soms wel even, maar de meest gebruikte operaties gaan overal het algemeen "snel genoeg" (tm).

Het is gewoon een afweging tussen de verschillende opties die gemaakt moet worden

Klopt, maar om voor git te kiezen omdat het nieuwe/hipper is is denk ik niet de juiste keuze , als git om andere redenen goed in het plaatje past zou ik het vooral gaan gebruiken

[Verwijderd]

Een SVN working copy op een netwerk share is inderdaad niet the way to go. Dan haal je een beetje alle voordelen van versie beheer onderuit. Ontwikkelaars local een test server te laten draaien is inderdaad een beter idee. Je zou dit met een VM kunnen oplossen, maar je zou ook van Windows over kunnen stappen op Linux (als je alleen PHP files edit, dit kan net zo goed onder een Linux omgeving).

Het boek over Subversoin (hier) is ook een goed startpunt. Hierin staan de voordelen uitgelegd van versiebeheer, en hoe je dit implementeert in verschillende organisaties. Mocht je geïnteresseerd raken dan is het misschien ook een goed idee om te kijken naar XP (eXtreme Programming) en dan vooral het gedeelte over Continuous process.

[Alex)]

Iedere machine zijn eigen ontwikkelomgeving lijkt me wel een handige situatie, dit kan inderdaad perfect met een VM. Je zou VirtualBox of Microsoft's Virtual PC kunnen overwegen, die zijn beide gratis en bieden genoeg functionaliteit hiervoor.

In de VM ontwikkelen je developers (dat kan ook prima op de host, en dat ze opslaan en lokaal testen in de VM, dat is aan de devvers) en eens in de zoveel tijd committen ze naar versiebeheer. SVN is hiervoor dan prima geschikt, al genereert SVN inderdaad een hoop metadata.

[Koelkasten]

Hier op mijn werk ook tegen hetzelfde probleem aangelopen waarbij we een gelijke setup hebben. locale windows development machines. een network share die meteen de docroot is van de dev server waarmee met svn checkouts worden gedaan.

Probleem is idd de snelheid van SVN over het netwerk. wat al heel veel helpt is NFS gebruiken in plaats van SAMBA, enige zure appel waar je doorheen moet is dat onder XP NFS support echt een beetje oude troep is van MS maar het werkt wel (en stuk sneller).

Onder Vista en Windows 7 is het een stuk makkelijker een NFS share te mappen, alleen ben je dan opeens wel gepakt dat je de ultimate of enterprise versie van windows moet hebben de normale Buisniss of proffesional editie heeft geen NFS support.

[djc]

Ik zou ook voor iets hippers gaan. Mercurial en git zijn echt veel sneller, en hoewel git voor veel mensen lastiger is om te leren is Mercurial vaak heel eenvoudig op te nemen voor mensen die SVN al kennen.

Voordeel is met name dat je lokale geschiedenis hebt, waardoor veel dingen veel sneller zijn. Desondanks is een Mercurial clone over het algemeen kleiner dan een SVN checkout (en over het netwerk is Mercurial een stuk efficienter dan zowel SVN als git).

[ Voor 38% gewijzigd door djc op 29-10-2009 18:13 ]

[MrData]

Iemand nog een ideetje voor mijn situatie? Ik ben al een tijdje aan het zoeken en testen, maar ik heb 't idee dat ik ergens de klok heb horen luiden, maar...

We hebben:

1) Windows XP en Vista machines waarmee ontwikkeld wordt
2) Meerdere Linux webservers waar we op dit moment op ontwikkelen en sites hosten (direct via SFTP), een site wordt ontwikkeld in een testdomein en daarna live gezet in het live domein via Plesk.
3) Een Windows (2003 server meen ik) machine binnen het netwerk met genoeg schijfruimte waar ik Subversion op heb staan om daar de repo op te zetten. Deze was niet in gebruik, dus die heb wil voor het opslaan van de broncode gebruiken. Ik heb voor Subversion gekozen vanwege (het gebrek aan) kosten, het feit dat we met Aptana werken voor het PHP werk en die een plugin ervoor heeft, en we in de nabije toekomst met Visual Studio willen werken die ook een goede plugin heeft.

Nu natuurlijk de vraag: hoe kan ik dit het beste gaan opzetten.

Wat ik kan doen is lokaal gaan ontwikkelen, synchroniseren met de repo en exporten als een klant iets online moet gaan testen. Probleem hiermee is dat de ontwikkel- en online configuraties anders zullen zijn wat de boel weer onnodig onvoorspelbaar maakt. Ander probleem is het exporteren van een revision naar de Linux server via SFTP, dat kreeg ik niet direct via Subversion voor elkaar. Het is me via een omweg gelukt door via een ander programmatje de server te mounten op een driveletter in Windows, maar ik heb het idee dat dat toch niet de bedoeling kan zijn. Werkte ook erg onvoorspelbaar.

Ik had eerst het idee om het hele 'lokaal ontwikkelen' scenario te laten varen en het ontwikkelen toch nog op de Linux servers te laten plaatsvinden om zo het Windows<->Linux verschil weg te nemen, maar dat kreeg ik vanuit Aptana al helemaal niet voor elkaar. Ik meen in een ander topic ook gelezen te hebben dat synchroniseren met de repository alleen lokaal kan. Iets zegt me ook dat het niet bevorderlijk voor de snelheid zal zijn.

Een Virtual Machine-achtige oplossing introduceren om op te testen lijkt me ook niet ideaal, dat introduceert toch alleen maar meer complexiteit?

Iemand tips/suggesties?

[Tubby]

Niet om 't een of 't ander: het linux<->windows verschil in php is toch niet zo groot dat je er niet tegenaan kan ontwikkelen of wel? Imho kun je heel goed devven tegen een lokale (windows) php install en dan deployen naar een acceptatie omgeving die linux draait.

Maar wellicht schiet mijn php kennis dan tekort.

En anders moet je wellicht met osx gaan werken

[MrData]

Tubby schreef op maandag 02 november 2009 @ 08:52:
Niet om 't een of 't ander: het linux<->windows verschil in php is toch niet zo groot dat je er niet tegenaan kan ontwikkelen of wel? Imho kun je heel goed devven tegen een lokale (windows) php install en dan deployen naar een acceptatie omgeving die linux draait.

Maar wellicht schiet mijn php kennis dan tekort.

En anders moet je wellicht met osx gaan werken

Dat is eigenlijk m'n grootste twijfel in deze zaak. Ik zie 't nog wel gebeuren dat iets op de lokale omgeving wel werkt (of anders werkt), en op de webserver niet. Maar daar kom je toch pas achter als het zo ver is en dan valt het vast wel op te lossen. Ik denk dat ik het gewoon ga proberen

[mithras]

Je zet zo snel een pad verkeerd (/ vs \) dat je gegarandeerd zo'n situatie gaat krijgen. Natuurlijk, je kan altijd DIRECTORY_SEPARATOR gebruiken die het voor je regelt, maar je maakt snel een foutje.

Wat is de moeite om, in plaats van per project een domein op de server aan te maken, dit nu per ontwikkelaar te doen. Je zal met versiebeheer op een of andere manier "lokaal" moeten testen. En of lokaal nu écht lokaal is, een virtual machine of een gemounte externe server, dat maakt niet uit. Je wil dat niet iedereen in hetzelfde mapje zit te kutten en daarin fouten gaat maken.

Dus regel op je ontwikkelserver dat alle ontwikkelaars een eigen account hebben, dat ze een eigen virtual host hebben en mount dat op je lokale desktop. En dan kan je prima committen naar je svn

[orf]

Windows wil ik ook niet gebruiken als ontwikkelomgeving omdat de omgeving zoveel mogelijk gelijk moet zijn aan de uiteindelijke productieomgeving.

We hebben nu wat tests gedaan met een Virtual Machine, maar lopen nog tegen wat praktische problemen op. We gebruiken nu een shared folder op de moeder machine die de document root van de VM is. Dat geeft problemen met bestandsrechten en is niet bijster snel. (het is een soort samba van Sun VirtualBox).

Ook het mounten van een netwerk server gaan we testen. Dan moeten we ofwel een netwerkshare gebruiken voor de bestanden waarbij we weer tegen dezelfde problemen met snelheid aan zullen lopen of we gebruiken een ander netwerkprotocol zodat de bestanden wel echt lokaal staan.

De repositories wil ik graag centraal hebben (zoals met SVN) zodat ook andere mensen kunnen uitchecken. Daarnaast ben ik behoorlijk gecharmeerd van Phing. We kunnen hier erg mooie dingen mee doen om testversies automatisch te genereren na commit.

NFS als netwerkprotocol is helaas lastig. We werken op Windows Vista Business en zullen niet makkelijk ondersteuning hiervoor kunnen inbouwen.

We gaan nog even door met testen en onderzoeken.

[Verwijderd]

Ik vind mithras oplossing eigenlijk wel een hele mooie.

Je wilt eigenlijk dat iedereen een eigen working copy heeft (anders heeft versie beheer weinig zin). Daarnaast wil je het liefst dat elke ontwikkelaar een eigen test omgeving heeft. Je kunt een Linux servertje inrichten die qua configuratie gelijk is aan die van de productie server. Je geeft nu iedere ontwikkelaar een eigen virtual host op die server, waarin je ze een eigen working copy geeft. Deze share je met behulp van Samba over het netwerk. Samba is makkelijk snel genoeg voor het editen van wat plain-text bestanden.

Je hebt nu alle voordelen lijkt mij:
- De ontwikkelaars behouden hun eigen vertrouwde omgeving
- De configuratie voor hun test systeem is gelijk aan die van het productie systeem
- Je introduceert versie beheer
- Je hebt geen gekloot met VM's

[orf]

Grootste probleem is dat js SVN niet over het netwerk wilt hebben. Tortoise is echt niet mee te werken over een netwerk share. We werken nu ook over een netwerk share en dat is inderdaad snel genoeg voor editen.

[Verwijderd]

En die mensen hun eigen gejailde SSH omgeving geven binnen die virtual host? Dan kunnen ze gewoon via de commandline hun commits doen. Persoonlijk doe ik mijn SVN commits e.d. altijd via de commandline zodat ik precies weet wat hij doet.

[MrData]

Verwijderd schreef op maandag 02 november 2009 @ 12:15:
Ik vind mithras oplossing eigenlijk wel een hele mooie.

Ik heb deze opstelling nu draaien als test. Elke ontwikkelaar heeft een eigen domeintje op de Linux server die via Samba aan een Windows driveletter is gekoppeld.

Voordeel: geen lokale omgeving meer nodig en dus geen eventuele Windows/Linux verschillen.
Nadeel: de snelheid is duidelijk minder dan lokaal synchroniseren met de repository. Lokaal syncen gaat in een flits, de opstelling heeft wel een seconde of 5 nodig.

Verder testen zal het moeten uitwijzen, maar ik ben geneigd het nadeel te accepteren en dan maar wat langer te wachten bij een sync.

[orf]

Verwijderd schreef op maandag 02 november 2009 @ 12:56:
En die mensen hun eigen gejailde SSH omgeving geven binnen die virtual host? Dan kunnen ze gewoon via de commandline hun commits doen. Persoonlijk doe ik mijn SVN commits e.d. altijd via de commandline zodat ik precies weet wat hij doet.

Dat is een mogelijkheid. Dan moet ik dat er nog wel door zien te krijgen bij de developers. In de OP gaf ik al aan dat we wellicht zelf een tooltje maken die in het context menu beschikbaar is op bestanden en die de SVN commando's ook direct op de server aanroept.

We hebben nu een werkende VM draaien en gaan daar nog wat verder mee testen. Wellicht testen we ook nog met een centrale server die per developer een virtual host heeft gemount op een gedeelde map op de workstation. Ben benieuwd hoe dat performed over het netwerk.

[djluc]

Kan je alleen vertellen wat wij doen:
Per project 1 centraal git repository. Vervolgens klikt een developer op de knop ik wil werken. Hij krijgt dan een kopie hiervan om te werken + een kopie van de data (die plakken we er overheen). Zodra hij klaar is commit hij en bij de volgende update van de testomgeving door de project manager wordt zijn wijziging meegenomen.

Wij werken met SSH2/SFTP beveiligde communicatie middels certificaten en daarbij alles op servers in datacentra. Developers gebruiken dus een SSH tunnel waarover ze werken.