Ontwikkelomgeving
Situatieschets
We hebben nu altijd een www en een dev subdomein, met allebei een eigen database. Tijdens de ontwikkeling publiceren we de bestanden van de lokale computer naar de dev-omgeving. Bij een oplevermoment wordt met behulp van versiebeheer de www geüpdatet.
Probleem
Wanneer meerdere developers tegelijkertijd werken aan hetzelfde project werken, wilt het nog wel eens voorkomen dat ze in het zelfde bestand moeten zijn. Waar dit erg vaak mee gebeurt is met de CSS/LESS bestanden. In eerste instantie is er geen probleem, de developers kunnen allemaal lokaal de wijzigingen aanbrengen en vervolgens naar de dev publiceren. Daar kan getest worden.
Maar wanneer een tweede of derde developer zijn wijzigingen publiceert zijn die van de eerste niet meer online zichtbaar, omdat het CSS-bestand overschreven wordt op de FTP.
In het versiebeheer is dit op te lossen met 'mergen', maar online testen is zo lastig. Daar zit mijn probleem dan ook.
Oplossing
Wat ik op internet heb gevonden zijn er globaal twee oplossingen mogelijk voor het 'FTP-probleem':
1) De developers werken lokaal (op de ontwikkelcomputer) met een eigen webserver;
2) De developers werken online op een eigen virtual server, bv. dev-jan.domein.nl en dev-kees.domein.nl.
Beide methodes hebben zo hun voor- en nadelen. Vooral qua beheer en toegang tot het project. Deze wil ik (nog) niet uitdiepen in dit topic.
Vraag
Wat ik dus wel graag zou willen weten is hoe anderen dit probleem getackeld hebben, of wat hun voorkeur zou zijn bij deze twee opties.
Gebruik een grafische git-client zoals SourceTree (warm aanbevolen). Dan heb je beter overzicht over de totale git-workflow en een goede synchronisatie tussen ontwikkelcomputers en servers.
Als alle developers tegelijkertijd aan een project werken, en dat project heeft maar één server waarop getest wordt (dev.domein.nl), dan zullen ze nog steeds bestanden overschrijven op de FTP. Of je he in Git nu helemaal netjes hebt, of niet.
Voorbeeld: dev-1 en dev-2 werken aan een ander deel van de front-end. Beide dev's moeten in de LESS-bestanden zijn en publiceren de CSS ervan naar de FTP. Dan overschrijven ze elkaars voortgang op de FTP, waardoor het testen lastiger (lees: onmogelijk) wordt. In het versiebeheer komt het dan nog steeds goed met een merge.
En dat is dan mijn vraag: hoe los je die situatie op? Lokaal ontwikkelen/testen, of meerdere virtual hosts?
De oplossing daarop kan een combinatie zijn. Wat in het bedrijf waar ik werkte gewoon gold was dat elke dev zijn eigen omgeving had op een development server. De staging omgeving was een combinatie van commits die door verschillende developers waren gepusht. Niet al het werk dat je doet push je, alleen wat "afgerond" is. Hiervoor is het uiteraard belangrijk om aan te houden dat 1 commit 1 idee is. Dit is mooi op te lossen als je je commits voor 1 idee gewoon blijft amenden en de specifieke commit pas pusht als deze klaar is. De uiteindelijke live omgeving was ook gewoon een bepaalde revisie van staging. In het hele verhaal komt FTP niet eens aan de orde.
In een succesvolle git-workflow (deze moet je eens lezen) zijn er niet meer slechts twee versies in omloop (development versus productie), maar minstens evenveel versies als er nodig zijn voor features, bugfixes, hotfixes en minor plus major releases.
De belangrijkste vuistregel is dat je branches maakt van de develop en naar de develop commit en merged, nooit naar de master. Op het moment dat dev1 en dev2 aan hetzelfde bestand werken, doen ze dat niet in de develop-branche, maar in hun eigen feature- of bugfix-branche van de develop. Op dat moment zijn er van de develop (en dat bestand) minstens drie versies in omloop. Is dev1 al verder gevorderd, dan kan dev2 ook besluiten die feature- of bugfix-branche af te splitsen. Het tweesporenbeleid met twee versies bestaat bij git niet meer en moet je vergeten (dus dat is je mentale uitdaging).
Nou begrijp ik je praktische probleem ook wel: hoe test je het geheel dan? Dáárvoor zou ik een klassieke oplossing gebruiken: zet een derde testserver tussen de developmentserver en de productieserver.
Mijn voornaamste advies is echter toch: zet eerst die git-workflow op poten en laat iedereen uitgebreid en goed wennen aan de nieuwe manier van werken.