Van geen versiebeheer naar SVN lokaal naar hosted GIT

Iets waar elke ontwikkelaar mee te maken krijgt: code opslaan in versiebeheer. Dit wordt gedaan om verschillende redenen:

• Ontwikkelen met anderen. Doordat alle bestanden centraal in een repository zitten en worden gesynchroniseerd naar alle ontwikkelaars, is het makkelijk om met anderen te werken aan hetzelfde project.
• De mogelijkheid om revisies te maken, dus je kunt altijd terug naar een vorige versie mocht er iets kapot zijn of moeten terugkomen.
• Omdat iedereen zijn code moet controleren voordat deze naar de repository wordt gestuurd, is dit een extra kwaliteitscontrole.
• Schone overzichtelijke code, door oude code op te slaan in versiebeheer en niet met een “comment” de onnodige code uitzetten.
• Werken in meerdere omgevingen door gebruik van “branches”. Bijvoorbeeld: ontwikkelomgeving, testomgeving en live omgeving.
• Deployen naar meerdere servers en eventueel met verschillende branches. Maar het belangrijkst is dat er controle is wat waar staat.

Starten met SVN (Subversion) en werkwijze

Wij waren begonnen met SVN op aanraden van andere ontwikkelaars. Het is een grote stap als je nog niet eerder met het concept versiebeheer hebt gewerkt. De gedachtegang is anders.

Normaal werk je op een systeem. Dit back-up je van tijd tot tijd naar een andere locatie. Bij uitbreidingen en wijzigingen zet je de oude bestanden weg, verwijder je ze of worden ze aangepast. Vervolgens maak je dezelfde wijzigingen op de server. Als er met andere ontwikkelaars aan gewerkt wordt, zullen de bestanden onderling en op de server moeten worden uitgewisseld.

Met de overstap komt er een nieuwe entiteit bij: de repository die alles centraal houdt zonder dat men elkaars werk kan overschrijven of verkeerde versies op de productie omgeving terecht komen. Dit maakt alles minder foutgevoelig en er blijft controle over wat er waar gebeurt.

Dus we hebben lokaal op een linux server een SVN server geïnstalleerd en deze opengezet voor internet, zodat de productieservers ook toegang kunnen hebben tot de versiebeheer server. Voor het gemak hadden we alle projecten in 1 repository gezet. Het voordeel hiervan is dat alles sneller en makkelijker gaat. Het nadeel is dat de revisienummers niet meer oplopen en er kunnen geen individuele rechten worden ingesteld per ontwikkelaar.

Alle ontwikkelaars “committen” naar en “updaten” vanaf de SVN server. Op de productieserver wordt er een checkout gedaan op een branch van het project in de SVN server. Wanneer er een update is, wordt de productieserver geüpdatet naar de desbetreffende versie.

SVN naar GIT

Na enkele jaren gebruik te hebben gemaakt van SVN waren er toch een aantal ergenissen. Vooral het feit dat SVN overal .svn mappen aanmaakt om wijzigingen in op te slaan. Dit creëert een hoop troep. In Windows Verkenner kan het door deze mappen erg traag worden om wijzigingen te maken in de structuur van het project.

Ook wilden we af van alle projecten in enkele repository. GIT heeft geen .git map in elke map, maar enkel in de project root. Dit maakt alles al een stuk eenvoudiger. Ook de nodige tools zijn aanwezig (TortoiseSVN en TortoiseGIT) voor het beheren van de versies. Tevens wordt GIT prima ondersteund in onze ontwikkelomgevingen: Eclipse, Aptana Studio en Netbeans. De overstap gaat redelijk simpel. Er zit niet veel verschil in gebruik, behalve er na een “commit” gepushed dient te worden naar een repository. Het voordeel van een repository per project en geen .svn mappen overal is direct te merken in snelheid en frustratie.

Alternatieven

Naast SVN en GIT zijn er nog andere versiebeheersystemen waar wij geen ervaring mee hebben, zoals CVS en Mercurial.

Zelf hosten of niet?

Dan bestaat er nog het dilemma om de GIT of SVN server lokaal te draaien op je pc of server, of om toch kiezen voor een online oplossing. Wij hebben gekozen voor een online oplossing omdat het minder zorgen oplevert en je niet hoeft te backuppen. Tevens is de verbinding naar de online servers sneller en de betere GIT hosting leveranciers bieden diverse handige tools zoals deployen met (s)FTP naar meerdere servers, zoeken door revisies en beheer van rechten voor gebruikers, en je hoeft er geen systeem voor in te richten.

Omdat wij GIT gebruiken zaten we te twijfelen tussen Beanstalk en GitHUB. Uiteindelijk gekozen voor Beanstalk vanwege de grotere ruimte die ze bieden. 6GB per project bij Beanstalk ten opzichte van de 4GB bij GitHUB. Let wel op bij de keuze dat je kiest voor “Private repositories”. “Public repositories” zijn benaderbaar voor iedereen. Met name interessant voor open source projecten.

Conclusie

Het is duidelijk dat er alleen maar voordelen zijn aan versiebeheer. Ook als je alleen werkt en kleine projecten hebt. Het is een werkwijze die je forceert zorgvuldig om te gaan met gegevens en is minder foutgevoelig. Ik zou ook aanraden meteen GIT te gebruiken. Qua moeilijkheidsgraad scheelt het niet veel.