Versiebeheer inrichten

[maarten_v]

Ik wil een vraag voorleggen over hoe we het beste ons versiebeheer kunnen inrichten.
Ik werk bij een reclamebureau waar we veel websites maken en onderhouden. We hebben een paar servers met Slackware / Apache / Mysql waar de websites staan.
Tot nu toe is het altijd zo geweest dat we daar rechtstreeks op ontwikkelen en omdat het meestal maar één persoon was die tegelijkertijd aan het ontwikkelde, was dat niet zo'n probleem.
Nu we vaker met meer mensen ontwikkelen is wel een versiebeheer systeem gewenst.
Als ik zo kijk op bv GoT lijkt Git een van de betere systemen. Veel mensen gebruiken alleen een ontwikkelomgeving lokaal en voeren hun wijzigingen daarna door naar de server.
Ik wil eigenlijk niet dat iedereen op zijn eigen computer z'n ontwikkelomgeving heeft ivm modules die wel/niet geïnstalleerd zijn en db-koppelingen ed.
Liefst zou ik als we een website aan het ontwikkelen zijn dan een paar omgevingen op de server aanmaken, bv:
www.sitenaam.nl (ontwikkelomgeving)
piet.sitenaam.nl
henk.sitenaam.nl
jan.sitenaam.nl

Waarbij iemand dan geregeld zijn wijzigingen dan door kan voeren naar de Git-server en de nieuwste versie daar weer van ophalen. Zelf kan ik dan de laatste versie van de Git-server weer "exporteren" naar de ontwikkelomgeving www.sitenaam.nl.

Als ik alles op de server zelf doe in plaats van dat mensen lokaal hun ontwikkelomgeving hebben, betekent dat ook meteen dat ik altijd alles via de ssh-console op de server moet doorvoeren? Dat zou wel onhandig zijn omdat ik dan denk ik niet makkelijk de wijzigingen en eventuele problemen kan zien. Of zou bijvoorbeeld iedereen dan zijn eigen wijzigingen van zijn ontwikkelomgeving naar zijn lokale git-server op zijn eigen computer moeten halen en dan van daar weer naar de ontwikkelomgeving? Dan zou het sowieso wel met een Git GUI kunnen op Windows/Mac.

Wat raden jullie aan?

[Standeman]

Tenzij het filesystem, services,etc op je server goed transparant kan maken zou ik development gewoon lokaal houden. Niets is zo irritant om voor een logfile weer via ftp ofzo naar je server te moeten gaan om 'm in te kunnen zien. Ook debuggen werkt lokaal vak makkelijker dan op een server omdat vaak de firewall dingen blokkeert.

Ik heb een aantal keer noodzakelijk moeten ontwikkelen en testen op een externe server en elke keer liep ik weer over van frustratie.

[syith]

-bericht verwijderd-

[ Voor 75% gewijzigd door syith op 29-06-2011 16:31 ]

[CodeCaster]

maarten_v schreef op woensdag 29 juni 2011 @ 16:10:
Ik wil eigenlijk niet dat iedereen op zijn eigen computer z'n ontwikkelomgeving heeft ivm modules die wel/niet geïnstalleerd zijn en db-koppelingen ed.

Hoe doe je dan een herinstallatie als je webserver eruit klapt? Je moet toch ergens bijhouden welke modules noodzakelijk zijn om jullie sites te draaien? Die kun je vervolgens in een vloek en een zucht installeren op ieders pc. Ik vind, als ik aan webdevelopment doe, het lokaal hebben draaien van een (kopie van de live-)server toch wel ideaal.

[ameesters]

ik stel het volgende voor:

op het interne netwerk op het werk, zet je de development server, dat een 1 op 1 kopie is (kwa software, modules e.d) van de live web servers, je kan ook VM's verschaffen aan de developers zodat ze op hun eigen pc/laptop kunnen ontwikkelen, maar een dev server is makkelijker te onderhouden. Het nadeel van VM's uitdelen is dat sommige met een verouderde VM kunnen gaan werken...

Kwa hardware specs zou ik de development servers iets minder geven dan de webservers, dit vanwegen de prestatie van de webapplicatie, als hij op de dev server vlot is, zal hij dat ook zijn op de web servers...

Wat ook kan is dat je de dev server als een soort van staging gebruikt... beeld u de volgende setup in:

- ontwikkelaar ontwikkeld lokaal een (gedeelte van een) applicatie.
- deze checkt hij uit op de staging(dev) servers, waarop hij kan testen of zijn applicatie 100% naar behoren functioneert met de huidige software(staging server dient nog steeds 100% 1op1 te zijn met de webservers(de software dan)),
dit is ook de plek waar eventuele unit-testing plaats vind, Quality Control Assurance e.d.
mocht daar wat uitkomen kan hij lokaal verder een herziende versie ontwikkelen(of een andere developer kan het uitchecken en er verder mee stoeien)...
- mocht de applicatie naar wens functioneren, de versie op de dev server uitchecken op de webserver

Maar vraag mij a.u.b niet op te kiezen tussen svn of git, git vind ik lokaal prettig werken omdat je ook via git svn kan updaten, weet niet of dat andersom ook werkt... maar svn zou evengoed werken... het is zeg maar kiezen tussen Debian of Ubuntu. De veteraan, of de soldaat die zich nog moet bewijzen.

[ameesters]

CodeCaster schreef op woensdag 29 juni 2011 @ 16:37:
[...]

Hoe doe je dan een herinstallatie als je webserver eruit klapt? Je moet toch ergens bijhouden welke modules noodzakelijk zijn om jullie sites te draaien? Die kun je vervolgens in een vloek en een zucht installeren op ieders pc. Ik vind, als ik aan webdevelopment doe, het lokaal hebben draaien van een (kopie van de live-)server toch wel ideaal.

Daar bak je je eigen iso voor he die heb ik ook gemaakt op het werk, voor de servers, zo werk je overal met gelijke versies... op een test servers rol ik updates uit, kijk of alles stabiel werkt, kijk naar een aantal bijzondere dependenties waar sommige software die wij gebruiken van gebruik maken(heb ik een test script voor geschreven)... Als alles ook is, updten(de iso niet vergeten natuurlijk)

[YopY]

Wat ook heel goed zal werken als je productieomgeving complex is mbt de geïnstalleerde zut: virtuele machines. één iemand zet je een paar dagen op het reproduceren van de productieomgeving (mbt modules en software e.d.) die dat allemaal in een (lichtgewicht) VM (zoals VirtualBox) installeert, die image geef je vervolgens door aan de andere devs. Met wat automatisering worden lokale wijzigingen in de VM gezet, en kunnen de devs zo het resultaat zien.

Een VM is ook makkelijk als je webserver eruitklapt, gewoon een nieuw blik servers opentrekken en je VM erop opstarten. Maar da's de theorie, daar heb ik verder geen ervaring mee.

[CodeCaster]

ameesters schreef op woensdag 29 juni 2011 @ 22:39:
[...]


Daar bak je je eigen iso voor he

Daar hintte ik ook naar. Hoe complexe je serveromgeving ook, die moet uiteraard wel reproduceerbaar zijn. En als je in dat stadium bent, is het een kleine moeite om die omgeving ook voor ontwikkeldoeleinden te reproduceren.

Of dat nu een image is voor bare metal (lastig met verschillende hardware wellicht) of een VHD voor een virtualisatieplatform is aan de TS. Toch kan ik het aanbevelen om lokaal te ontwikkelen op een kopie van de productieserver, en vervolgens je voortgang te pushen naar een (eventueel lokale) (integratie)testserver, die al dan niet bereikbaar is voor klanten.

[djc]

Volgens mij maakt het niet echt uit of je je ontwikkelomgeving lokaal of op een server draait, zolang maar iedere developer zijn eigen ontwikkelomgeving heeft. Als je echter nog geen versiebeheer gewend bent is het gebruik van GUIs misschien wel makkelijk, dan heeft een lokale omgeving wel voordelen (hoewel ook dat via een netwerkshare kan, gok ik).

Overigens zou ik ook zeker Mercurial overwegen; dat is substantieel makkelijker in het gebruik dan git en werkt beter op Windows. Volgens mij is de GUI (TortoiseHg) ook een stuk beter dan bij Git.

[Anoniem: 42791]

YopY schreef op donderdag 30 juni 2011 @ 08:26:
Wat ook heel goed zal werken als je productieomgeving complex is mbt de geïnstalleerde zut: virtuele machines. één iemand zet je een paar dagen op het reproduceren van de productieomgeving (mbt modules en software e.d.) die dat allemaal in een (lichtgewicht) VM (zoals VirtualBox) installeert, die image geef je vervolgens door aan de andere devs. Met wat automatisering worden lokale wijzigingen in de VM gezet, en kunnen de devs zo het resultaat zien.

Een VM is ook makkelijk als je webserver eruitklapt, gewoon een nieuw blik servers opentrekken en je VM erop opstarten. Maar da's de theorie, daar heb ik verder geen ervaring mee.

Ik heb zelf goede ervaringen met werken op deze manier. Bijkomend voordeel is dat je niet hebt dan je ontwikkelaars op Windows zitten te ontwikkelen terwijl de servers (zoals bij de TS) Slackware draaien. Niet dat dat altijd een probleem hoeft te zijn, maar het is wel een goed uitgangspunt om je lokale omgeving zo gelijk mogelijk aan de productie-omgeving te hebben.

Je kunt al die images nog laten connecten met een centrale database op een dev server, zodat niet iedereen zijn eigen database draait. Je kunt dan iets makkelijker productiedata naar dev halen, zodat iedereen weer up-to-date data ziet. Je moet dan natuurlijk wel opletten dat de db structuur/data op dev zelf niet veranderd is en je die veranderingen weggooit.

Wat versiebeheer betreft heb ik goede ervaringen met SVN. Je laat je developers vanaf hun lokale machines wijzigingen committen in SVN en als je een nieuwe versie van de applicatie releast trek je die uit SVN. Kind kan de was doen

Het idee van een subdomein per developer lijkt me niet zo goed. Je moet dan bij elke personele wijziging aan de slag en omgevingen inrichten en weghalen. Maak dan gewoon een OTAP (Wikipedia: Ontwikkeling, test, acceptatie en productie) of een "OP" straat als je niet meteen vier servers wil neerzetten.

[ Voor 4% gewijzigd door Anoniem: 42791 op 30-06-2011 17:27 ]

[maarten_v]

De ontwikkelservers bij ons staan al bijna "intern".
We hebben een directe glasvezellijn naar de servers dus bij bestanden opslaan hoeven we nooit te wachten, en we hebben ze in eigen beheer.

Maar ik zal toch inderdaad ervoor zorgen dat iedereen lokaal zijn ontwikkelomgeving heeft.
Eventueel met VM images. In dat geval zal ik dat dan wel met Ubunto oid willen doen. Als ik daarvoor weer Slackware gebruik kan ik vervolgens weer niet mergen en dergelijke met behulp van een Git GUI of wel?
Dat lijkt me erg onhandig, zeker voor de front-end developers die niet gewend zijn met een terminal te werken.

[frickY]

Wij draaien hier ook met 1 ontwikkelomgeving waarop iedereen zijn eigen workingcopy heeft, die bereikbaar is via een netwerkschijf/mount. Daarnaast hebben we 1 centrale workingcopy die als soort staging dient van waaruit zaken live worden gezet.

Ieders workingcopy is bereikbaar via bijv www.sitenaam.nl.dev-piet. Van de netwerkmount worden wijzigingen gecommit. Als er getest wordt update iemand de centrale workingcopy bereikbaar op www.sitenaam.nl.dev.

Dat werkt an sich prima, maar het kent natuurlijk ook zijn beperkingen.

Wij werken hier overigens naar volle tevredenheid met SVN, maar heb ook geen ervaring met Git.

[ Voor 10% gewijzigd door frickY op 30-06-2011 16:37 ]

[sanzut]

Wij hebben ook lokale ontwikkelversies, die we committen naar een centrale server.
Dit werkt voor ons perfect, alleen lopen wij tegen het probleem met databasestructuur wijzigingen in de SQL Server aan. Hoe houden jullie deze bij?

[CodeCaster]

sanzut schreef op donderdag 30 juni 2011 @ 16:41:
Wij hebben ook lokale ontwikkelversies, die we committen naar een centrale server.
Dit werkt voor ons perfect, alleen lopen wij tegen het probleem met databasestructuur wijzigingen in de SQL Server aan. Hoe houden jullie deze bij?

De databaseaanpassingsscripts mee inchecken met een commit? Als je code incheckt die een bepaalde nieuwe kolom uit een tabel nodig heeft, dan veroorzaakt die code fouten wanneer die op een oudere database wordt uitgevoerd. Ergo, de databaseaanpassing hoort bij die changeset.

PhpMyAdmin laat ook mooi de code zien als je een tabel/view/SP toevoegt of aanpast, die kun je dan mooi meteen in een .sql-bestandje opslaan en mee inchecken.

[ Voor 11% gewijzigd door CodeCaster op 30-06-2011 16:52 ]

[sanzut]

Probleem is dat wij werken met MS SQL server. Deze genereert geen herbruikbare change scripts..

[Anoniem: 42791]

maarten_v schreef op donderdag 30 juni 2011 @ 16:14:
De ontwikkelservers bij ons staan al bijna "intern".
We hebben een directe glasvezellijn naar de servers dus bij bestanden opslaan hoeven we nooit te wachten, en we hebben ze in eigen beheer.

Maar ik zal toch inderdaad ervoor zorgen dat iedereen lokaal zijn ontwikkelomgeving heeft.
Eventueel met VM images. In dat geval zal ik dat dan wel met Ubunto oid willen doen. Als ik daarvoor weer Slackware gebruik kan ik vervolgens weer niet mergen en dergelijke met behulp van een Git GUI of wel?
Dat lijkt me erg onhandig, zeker voor de front-end developers die niet gewend zijn met een terminal te werken.

Jawel hoor. Je kunt als developer of front-ender gewoon in je Windows omgeving werken aan de code die op je VM staat. Je gebruikt je Windows IDE, je Windows GIT (of SVN) interface, et cetera. Het verschil is alleen dat je in je IDE niet een project maakt met code op je lokale harde schijf, je maakt een project met de code die op je VM staat.

Je kunt de harde schijf (teminste 'hard', stiekem is het natuurlijk een zachte schijf, want hij is virtueel) van je VM in je Windows omgeving laten verschijnen met behulp van Samba en dan een drive mapping.

Voor je IDE bijvoorbeeld is het dus transparant. Je maakt gewoon een project aan en vertelt hem dat de code op P:\projects\jouwproject staat of iets dergelijks en dan is P: dus je VM.

[ Voor 4% gewijzigd door Anoniem: 42791 op 30-06-2011 18:49 ]

[CodeCaster]

sanzut schreef op donderdag 30 juni 2011 @ 17:06:
Probleem is dat wij werken met MS SQL server. Deze genereert geen herbruikbare change scripts..

Echt wel. Zit in SQL Server Management Studio. In 2008 althans wel. Alle changes kun je opslaan als script, en wel met deze knop:


Lastiger wordt data exporteren.

Tools als hieronder genoemd zijn ook een uitkomst, en een koppeling tussen SQL Server en Team Foundation Server is ook nuttig.

[ Voor 29% gewijzigd door CodeCaster op 01-07-2011 10:49 ]

[Remus]

sanzut schreef op donderdag 30 juni 2011 @ 16:41:
Wij hebben ook lokale ontwikkelversies, die we committen naar een centrale server.
Dit werkt voor ons perfect, alleen lopen wij tegen het probleem met databasestructuur wijzigingen in de SQL Server aan. Hoe houden jullie deze bij?

Je kan ook kijken database change management tools zoals bijvoorbeeld http://www.liquibase.org/

[maarten_v]

We zijn een paar maanden verder, bedankt voor de voor de hulp.
We hebben het uiteindelijk ingericht zoals ameesters voorstelde icm Git.
Iedereen heeft zijn eigen ontwikkelversie van elke website waar hij aan werkt op onze ontwikkelserver die intern staat, en als de wijzigingen OK zijn worden ze naar de live-server gepusht.
Dat doet diegene dan met Git GUI op de ontwikkelserver die hij via VNC benadert.

Werkt allemaal erg goed. Het enige lastige is dat de klanten zelf met FckEditor afbeeldingen uploaden in de images map. Die map negeren we nu in Git zodat we niet de afbeeldingen van de klant overschrijven.
We hadden al wel gezien dat je dit soort van op kunt lossen door in de cron op de server automatisch elk halfuur een commit uit kunt voeren.

[fleppuhstein]

maarten_v schreef op zondag 09 oktober 2011 @ 16:59:
We zijn een paar maanden verder, bedankt voor de voor de hulp.
We hebben het uiteindelijk ingericht zoals ameesters voorstelde icm Git.
Iedereen heeft zijn eigen ontwikkelversie van elke website waar hij aan werkt op onze ontwikkelserver die intern staat, en als de wijzigingen OK zijn worden ze naar de live-server gepusht.
Dat doet diegene dan met Git GUI op de ontwikkelserver die hij via VNC benadert.

Werkt allemaal erg goed. Het enige lastige is dat de klanten zelf met FckEditor afbeeldingen uploaden in de images map. Die map negeren we nu in Git zodat we niet de afbeeldingen van de klant overschrijven.
We hadden al wel gezien dat je dit soort van op kunt lossen door in de cron op de server automatisch elk halfuur een commit uit kunt voeren.

De images die een klant upload mede als de artikelen, of andere applicatie input valt onder back-up, en niet onder versie beheer zou ik zeggen. Klinkt logischer om het mogelijk te maken om de images van de klant ook gesynchroniseerd op je ontwikkel station te hebben. Misschien met een Rsynch optie ? Of anders buut een hele map over scp'en als het om een klein aantal files, inclusief een bijpassend bestands formaat gaat.

[maarten_v]

@fleppuhstein Via rsync is inderdaad veel logischer. Ingesteld en werkt super!