Versiebeheer en website deployment voor kleine website

[Barryvdh]

Ik heb de afgelopen tijd veel gelezen over versiebeheer en website deployment, maar er waren een aantal zaken die ik me afvroeg, aangezien ik geen ervaring met Git heb.

Nu werk ik met een Live server, en gaat het in de meeste gevallen om mkb websites, met de volgende workflow (na het akkoord van concept):
- Nieuwe user via DirectAdmin, standaard boilerplate/framework wordt neergezet, ftp gegevens worden verstuurd naar een ontwikkelaar.
- Database koppelen aan CMS
- Ontwerper zet concept in html/css op basis van framework.

Dat is dus allemaal redelijk straightforward en de meeste wijzigingen naderhand gaan via het CMS, of kleine puntjes (logo wat verschuiven, ander plaatje etc).
Bij grotere projecten is het vaak onhandiger, bijvoorbeeld door een v2 of dev subdomein, met een kopie van de website, en dan overkopieren.

Nu ben ik het wel mee eens, dat versiebeheer altijd moet, maar ik vroeg me af hoe je dat op de beste manier doet voor simpele projecten, waar je ook met grotere projecten mee vooruit kan. En dan met name zorgen dat ook kleine website niet teveel overhead krijgen, en het voor de ontwerper (soms een stagiair bijvoorbeeld), het ook nog snapt.

Ik zat zelf te denken aan deze manier:

- Per gebruiker een eigen VM, met een soortgelijke installatie als de live server
- Een lokale server, ook gelijk aan de live server, met daarnaast centrale git repositories en issue tracker
- De live server, houden zoals die nu al is.

Dan zou de workflow dus zijn:
- Nieuw user aanmaken in DirectAdmin, via script git reposity maken en framework klonen?
- Ipv de ftp gegevens, de git repository mailen naar de ontwikkelaar
- Ontwikkelaar haalt repo op, voert werk uit, controleert op zijn VM, commit daarna naar de testserver.
- Na controle op de testserver, de liveserver updaten vanuit Git

Maar omdat je met een CMS werkt, maak je het liefst verbinding met de mysql db van de live server, anders moet je steeds een export/import doen, of kan dit makkelijk automatisch?
En de content die je upload via het cms (in map /content), wil je niet steeds overkopieren, maar wel zien tijdens het testen. Bijvoorbeeld door met .htaccess de url te rewriten naar de live server?

Zijn er verder nog dingen waar ik rekening mee zou moeten houden, of die waarschijnlijk zo niet werken.

[ Voor 1% gewijzigd door Barryvdh op 23-02-2012 19:14 . Reden: Duidelijke naamgeving mbt gebruiker/ontwikkelaar ]

[Boss]

Met 'gebruiker' bedoel je dan ontwikkelaar of eindgebruiker (klant)?

Het hangt denk ik echt vanaf hoe groot jouw bedrijf is. Werk je met een paar ontwikkelaars en niet gelijktijdig aan dezelfde projecten dan kan je prima samenwerken op een ontwikkelserver. De wijzigingen daarvan kan je in 1x naar de productieserver sturen via (s)ftp of via iets als Git.

Ik kan niet helemaal uit de tekst opmaken of alle klanten het CMS (framework) ook delen of dat per klant een hele losse omgeving is die zij gebruiken?

[Barryvdh]

Ik bedoelde daar ontwikkelaar, heb de tekst even iets aangepast.

Het CMS is centraal, en wordt dus gedeeld met andere klanten. Het (kleine) framework dat we standaard in het begin plaatsen, zijn alleen een aantal scripts voor de standaard modules, meertaligheid, standaard html pagina ( op basis van html5 boilerplate) en grid/basis css (op basis van bootstrap). Die worden aangepast, dus hoeven niet meer centraal geüpdatet worden naderhand.

Aangezien we meestal bij elkaar op kantoor zitten (of anders via Skype overleggen) en het meestal 1 frontend (html/css) ontwikkelaar is, en 1 backend (php/mysql), werken we meestal niet tegelijk aan dezelfde code. In dit geval zou je dus bijvoorbeeld 1 lokale ontwikkelserver op kantoor zetten, en daar (via ftp of gedeelde map) kunnen ontwikkelen, en dan vanuit daar committen naar de master.
Dit zou het wel een stuk minder complex maken, maar nadeel is dan wel dat je in een issue tracker, niet meer makkelijk bijhoudt van wie de wijging af komt.

[Boss]

Je kan op de ontwikkelserver ook met verschillende ontwikkelaars allemaal vanuit een eigen folder werken. Dan deel je php/mysql en heeft iedereen een eigen repository met zijn files. Dan kan iedere ontwikkelaar gewoon committen. Alleen met (brekende) veranderingen aande database zal je dan moeten opletten als je aan hetzelfde project werkt.