Toon posts:

Versiebeheer inrichten

Pagina: 1
Acties:

Onderwerpen


  • maarten_v
  • Registratie: Februari 2003
  • Laatst online: 26-05 09:38
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
  • Registratie: November 2000
  • Laatst online: 23:45

Standeman

Moderator Wonen & Mobiliteit

Prutser 1e klasse

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.

The ships hung in the sky in much the same way that bricks don’t.


  • syith
  • Registratie: December 2007
  • Laatst online: 18-05 19:27
-bericht verwijderd-

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


  • CodeCaster
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

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.

https://oneerlijkewoz.nl
I have these thoughts / so often I ought / to replace that slot / with what I once bought / 'cause somebody stole my car radio / and now I just sit in silence


  • ameesters
  • Registratie: Juni 2008
  • Laatst online: 05-01-2022
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
  • Registratie: Juni 2008
  • Laatst online: 05-01-2022
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
  • Registratie: September 2003
  • Laatst online: 16-05 09:43
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
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

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.

https://oneerlijkewoz.nl
I have these thoughts / so often I ought / to replace that slot / with what I once bought / 'cause somebody stole my car radio / and now I just sit in silence


  • djc
  • Registratie: December 2001
  • Laatst online: 28-07-2022
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.

Rustacean


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
  • Registratie: Februari 2003
  • Laatst online: 26-05 09:38
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
  • Registratie: Juli 2001
  • Laatst online: 18:19
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
  • Registratie: December 2006
  • Laatst online: 13:15

sanzut

It's always christmas time

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
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

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]

https://oneerlijkewoz.nl
I have these thoughts / so often I ought / to replace that slot / with what I once bought / 'cause somebody stole my car radio / and now I just sit in silence


  • sanzut
  • Registratie: December 2006
  • Laatst online: 13:15

sanzut

It's always christmas time

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
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

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. :P Zit in SQL Server Management Studio. In 2008 althans wel. Alle changes kun je opslaan als script, en wel met deze knop:
SQL Server Mgmt Stdio 2008 Generate Change Script

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]

https://oneerlijkewoz.nl
I have these thoughts / so often I ought / to replace that slot / with what I once bought / 'cause somebody stole my car radio / and now I just sit in silence


Acties:
  • 0Henk 'm!

  • Remus
  • Registratie: Juli 2000
  • Laatst online: 15-08-2021
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
  • Registratie: Februari 2003
  • Laatst online: 26-05 09:38
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
  • Registratie: Januari 2002
  • Laatst online: 07-05 09:51
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
  • Registratie: Februari 2003
  • Laatst online: 26-05 09:38
@fleppuhstein Via rsync is inderdaad veel logischer. Ingesteld en werkt super!
Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee