Ontwikkelomgeving

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Elwin - Fratsloos

Elwin - Fratsloos

12/01/2016 11:21:02
Quote Anchor link
Op kantoor werken we met een team van developers. We maken gebruik van SVN (we zijn bezig met een overstap naar Git), maar bij het ontwikkelen lopen we toch nog vaak tegen een probleem aan. Ik ben benieuwd hoe anderen dat oplossen.

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.
 
PHP hulp

PHP hulp

12/02/2025 19:49:22
 
Ward van der Put
Moderator

Ward van der Put

12/01/2016 12:13:23
Quote Anchor link
Lang verhaal kort: ik denk dat je eerst de integrale overstap naar git moet afronden. Veel van je operationele problemen zijn dan namelijk al opgelost. Als je in het team duidelijke naamconventies voor git-branches afspreekt en iedereen aanleert om ook kleine wijzigingen snel te committen, kun je eigenlijk altijd zien wie waaraan werkt. Met meerdere developers tegelijk aan hetzelfde bestand werken is dan ook nauwelijks nog een probleem.

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.
 
Elwin - Fratsloos

Elwin - Fratsloos

12/01/2016 12:20:14
Quote Anchor link
Ward, bedankt voor je antwoord. Ik ben het eens met je antwoord, maar ik denk niet dat het één met het ander te maken heeft. Ook met Git blijf je volgens mij zitten met het feit dat je op de externe FTP-server bestanden overschrijft als meerdere developers tegelijk in een project bezig zijn. Vanzelfsprekend alleen als ze aan dezelfde bestanden werken.

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?
 
Ben van Velzen

Ben van Velzen

12/01/2016 12:34:49
Quote Anchor link
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.
 
Ward van der Put
Moderator

Ward van der Put

12/01/2016 13:06:16
Quote Anchor link
Overstappen naar git is niet slechts een technische aangelegenheid, maar vereist ook dat je conceptueel en zelfs mentaal knoppen omzet.

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.

Afbeelding

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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.