Git workflow met lokale server

[Rann]

We zijn op het werk bezig om een (betere) develop omgeving op te richten op basis van Docker hierop draait een server die de website host op een alleen lokaal te bereiken URL. Deze Docker is gelijk aan de online omgeving zodat we zo natuurgetrouw mogelijk kunnen testen.

Hier hebben we inmiddels een goeie server draaien. Alleen we zitten nog te stoeien met het doorvoeren van wijzigingen. We willen het vooral voor de front-enders zo makkelijk mogelijk houden. Ze kunnen nu met twee commando's een Docker starten, en op de Docker een website(via git) binnenhalen, zodat ze deze lokaal kunnen bereiken en er mee aan het werk gaan.

Om daadwerkelijk files te kunnen wijzigen gebruiken we VSCode met een FTP extensie, elke wijziging die je opslaat, word dan automatisch geüpload naar de Docker. Zo heb je constant de nieuwste versie beschikbaar in je browser. Hiernaast werken we lokaal met gitKraken zodat de front-enders makkelijker kunnen comitten

Nu het probleem.
Als we lokaal de wijzigingen comitten, dan worden deze naar een branch gecommit. De wijzigingen staan dan ook al op de Docker door de FTP connectie.
Echter als je vervolgens een git pull doet op de Docker omgeving, om bijvoorbeeld het werk van een collega binnen te halen, zal hij deze niet kunnen binnenhalen, omdat hij alle changes die je (via FTP) al hebt gedaan, niet kan overschrijven/discarden.

Ik dacht vervolgens met een 'git checkout -f' dat het dan wel alles zou overschrijven, maar helaas blijft hij zeuren over dat er untracked files zijn op de Docker die hij niet.

Ik heb hem uiteindelijk met een 'git reset --hard <commit>' geforceerd, maar is dit wel zo verstandig?


Het doel is uiteindelijk om een makkelijke lokale server te hebben, zodat iedereen snel een website aan kan slingeren, met git functionaliteit. Hebben jullie nog tips? Of kan ik git op één of andere manier hard forceren naar de allerlaatste commit.

(Voor de duidelijkheid, we committen dus niet op de Docker)

[qless]

Of git of ftp, maar niet beiden, dat gaat zo niet. Waarom werk je niet volledig met git, en laat dan vscode bij release build een docker starten die dat dan test?

[Kwistnix]

Zonder in te gaan op de oplossingsrichting, kan je niet uit de voeten met simpelweg git add . in de root gevolgd door git stash. Dan kan je desgewenst ook nog eenvoudig terug naar de lokaal gewijzigde versie die via FTP is neergezet. Of een verse Docker container starten en de boel opnieuw uit Git trekken.

[Rann]

qless schreef op dinsdag 12 maart 2019 @ 10:21:
Of git of ftp, maar niet beiden, dat gaat zo niet. Waarom werk je niet volledig met git, en laat dan vscode bij release build een docker starten die dat dan test?

Omdat alle wijzigingen die we doen, graag direct op de lokale Docker/website willen zien. Dus ik maak bijvoorbeeld een nieuwe CSS file aan, (word dus ook direct naar de Docker gekopieerd), en ik zie gelijk de opmaak op de lokale site verschijnen. Zo ook met het editen van php files..

We gebruiken de Docker dus echt als lokale ontwikkelomgeving i.p.v. Xampp te gebruiken.

Kwistnix schreef op dinsdag 12 maart 2019 @ 10:22:
Zonder in te gaan op de oplossingsrichting, kan je niet uit de voeten met simpelweg git add . in de root gevolgd door git stash. Dan kan je desgewenst ook nog eenvoudig terug naar de lokaal gewijzigde versie die via FTP is neergezet. Of een verse Docker container starten en de boel opnieuw uit Git trekken.

Ik durf het niet te zeggen of git add . dan gaat werken, word dan de timestamp niet anders, en gaat hij alles als modified markeren en conflicten op een git pull.
Een nieuwe Docker container is niet ideaal voor ons, om dat bij het nieuw binnenhalen van een website, ook een kopie van de live database word gemaakt, en dan ben je dus al je database wijzigingen op je develop kwijt. ;-) Ook moet je dan elke keer veel data pullen vanuit git, dan kan ik net zo goed een rm -rf * doen en opnieuw de data binnenhalen, maar het liefst zou ik dat willen voorkomen.

[Ramon]

Ik ben geen docker expert maar je kan docker ook gebruiken met een soort shared folders. Dan hoef je dus niet te ftp'en maar wordt een wijziging in je lokale git repo automatisch opgepakt als normaal.

Verder worden database wijzigingen natuurlijk vast gelegd in migraties zodat als je een nieuwe docker container binnenhaalt je met een paar commando's weer verder kan waar je was.

[MaffeMaarten]

Je hoeft in je docker toch nooit git pull te doen? Als je de docker-drive echt ziet als (ftp)mirror van je lokale bestanden, is het meest logische om dan ook lokaal de git-pull (of welke git commando's dan ook) te doen.

Of al je git commando's lokaal, of al je git commando's in de docker. (Of misschien een lokale directory als volume mounten in je docker, zodat je echt in dezelfde bestanden bezig bent)

docker run -ti --rm -u developer -v ~/proj/website:/home/developer/website rannimage

Nu ik erover nadenk, misschien als je zorgt dat de .git directory ook netjes gemirrord wordt via ftp, dat het dan ook wel goed gaat.

[ Voor 8% gewijzigd door MaffeMaarten op 12-03-2019 11:50 . Reden: opmaak en voorbeeld ]

[Ed Vertijsment]

Stop met wat je aan het doen bent en ga eerst even wat concepten van docker uitzoeken.

Momenteel gebruik je docker als hippe vps. Gebruik dan gewoon een vps. Docker werkt enkel goed als je all the way je workflow op orde hebt. Goed dus dat je een topic opent maar ga in ieder geval niet op deze manier door.

Zoals eerder genoemd:

Ftp of git, niet allebei

De reden dat je git niet wil pullen is omdat dat gaat conflicteren met locale changes door ftp. Git weet niet wat deze wijzigen zijn en vraagt om een oplossing.

1 ontwikkelomgeving of meerdere

Je zit nu in een flow waarin iedereen één omgeving gebruikt. Het lijkt mij handig hier van af te stappen en ieder lokaal te laten werken (zelf de docker opspinnen). Als je dan op een centrale plek wilt testen/demoën kan je altijd nog een docker opstarten die een specifieke branch draait. Hier zijn oplossingen voor.

Containers for everyone!

Wat ik zou doen is eerst ftp droppen en iedereen lekker op feature branches in git te laten werken. Zodra mensen dat in de vingers hebben heb je een houvast om mee te werken. Vervolgens zorg je ervoor dat je dockerfile in git staat en gemakkelijk (eventueel met een helper script) op gestart kan worden en de lokale omgeving van de dev in kwestie uitserveert.

Op je de centrale test/demo omgeving richt je de docker/scripts zo in dat je een arbitraire branch kan starten om die te laten zien. Je zou zelfs op verschillende poorten verschillende branches naast elkaar kunnen draaien zodat je makkelijk kan vergelijken.

[Rann]

Ed Vertijsment schreef op dinsdag 12 maart 2019 @ 12:57:

1 ontwikkelomgeving of meerdere

Je zit nu in een flow waarin iedereen één omgeving gebruikt. Het lijkt mij handig hier van af te stappen en ieder lokaal te laten werken (zelf de docker opspinnen). Als je dan op een centrale plek wilt testen/demoën kan je altijd nog een docker opstarten die een specifieke branch draait. Hier zijn oplossingen voor.

Elk van onze developers start zijn eigen docker, zodat we onafhankelijk van elkaar dingen kunnen bouwen.
Dat gebeurd dus al..

Containers for everyone!

Wat ik zou doen is eerst ftp droppen en iedereen lekker op feature branches in git te laten werken. Zodra mensen dat in de vingers hebben heb je een houvast om mee te werken. Vervolgens zorg je ervoor dat je dockerfile in git staat en gemakkelijk (eventueel met een helper script) op gestart kan worden en de lokale omgeving van de dev in kwestie uitserveert.

Dit gebeurd allemaal ook al


Het punt is, we zoeken een manier, waarop we de wijzigingen die we doen aan een website voor iedereen kunnen laten werken. Het ideaalst zou het zijn als iedereen op zijn eigen Docker inlogt, en direct daar werkt, en via de CLI alles commit etc. Helaas is Nano niet het ideaalste programma, en kunnen we niet van elke front-ender ook verwachten dat hij commits etc. doet via de CLI..

Vandaar dat we naar een soort van workaround aan het kijken zijn. Hoe kunnen ze met de tools die ze kennen (VSCode/GitKraken), dit werkend maken.

Het idee van een gedeelde map heb ik ook vaker gehoord, echter schijnt dat een behoorlijke performance hit te zijn omdat we op Windows draaien, en de Docker op Linux, dat is niet wenselijk.

Vandaar dat we naar andere manieren aan het zoeken zijn. VSCode met een FTP plugin was ideaal, tot het moment dat je op je op je docker de laatste changes wil binnenhalen die een collega heeft gedaan op zijn eigen docker.. Een soort forced pull op de Docker is misschien het ideaalst, omdat je verder toch geen git bijhoud op de Docker. Alle wijzigingen en commits doe je namelijk op je eigen PC..

[Hydra]

Zet ajb gewoon een fatsoenlijke deployment pipeline op met een CI/CD tool. Als je binnen een Docker container dingen gaat doen, dan gebruik je sowieso Docker niet op de manier waarop het bedoeld is. Docker is geen virtualisatie; het is een standaard formaat voor applicaties.

Het idee is dus dat je met je CI/CD tool (op dit moment gebruik ik Gitlab maar 'pick your poison') op het moment dat er een push naar je centrale repository gedaan wordt deze automatisch bouwt in een Docker image. Dit image kan je dan, als het ware een executable, op verschillende servers deployen. Test, productie, whatever. Het idee is dus dat je die specifieke container, met alle code daarin, daarna niet meer aanraakt. Dit betekent dus dat je heel makkelijk als er bijvoorbeeld een bug in de code blijkt te zitten een vorige versie kunt deployen.

Als developers zelf lokaal ook Docker willen gebruiken om in te werken; prima. Maar dat kunnen ze prima zelf lokaal doen. Wat belangrijk is dat je een vaste build-straat is, waarin code gecompiled wordt, test gerund worden (en de build faalt als deze falen!) een docker image gebouwd wordt en deze gedeployed wordt op een test omgeving. Van de productie deployment kun je dan een stap in je build maken die je handmatig triggered.

[Rann]

Hydra schreef op woensdag 13 maart 2019 @ 08:58:
Zet ajb gewoon een fatsoenlijke deployment pipeline op met een CI/CD tool. Als je binnen een Docker container dingen gaat doen, dan gebruik je sowieso Docker niet op de manier waarop het bedoeld is. Docker is geen virtualisatie; het is een standaard formaat voor applicaties.

Het idee is dus dat je met je CI/CD tool (op dit moment gebruik ik Gitlab maar 'pick your poison') op het moment dat er een push naar je centrale repository gedaan wordt deze automatisch bouwt in een Docker image. Dit image kan je dan, als het ware een executable, op verschillende servers deployen. Test, productie, whatever. Het idee is dus dat je die specifieke container, met alle code daarin, daarna niet meer aanraakt. Dit betekent dus dat je heel makkelijk als er bijvoorbeeld een bug in de code blijkt te zitten een vorige versie kunt deployen.

Als developers zelf lokaal ook Docker willen gebruiken om in te werken; prima. Maar dat kunnen ze prima zelf lokaal doen. Wat belangrijk is dat je een vaste build-straat is, waarin code gecompiled wordt, test gerund worden (en de build faalt als deze falen!) een docker image gebouwd wordt en deze gedeployed wordt op een test omgeving. Van de productie deployment kun je dan een stap in je build maken die je handmatig triggered.

Ik snap je verhaal, alleen we hebben een omgeving nodig waarin we gewoon lokaal kunnen ontwikkelen (Bijvoorbeeld voor Magento), waar je je changes direct ziet, en Docker lokaal draaien werkt daar wel heel mooi voor.. Fuck je iets up, verse container starten en weer door. Updates aan een server? Image ook updaten en je developers werken lokaal met de laatste updates die ook op de online omgeving staan.

Het is dus puur alleen voor lokaal te werken, een soort verkapte Xampp om maar zo te zeggen, alleen dan 10x sneller en makkelijker naar collega's te zetten..

De verdere pipeline word aan gewerkt, maar dat is een ander verhaal

[MaffeMaarten]

Hydra schreef op woensdag 13 maart 2019 @ 08:58:
Zet ajb gewoon een fatsoenlijke deployment pipeline op met een CI/CD tool. Als je binnen een Docker container dingen gaat doen, dan gebruik je sowieso Docker niet op de manier waarop het bedoeld is. Docker is geen virtualisatie; het is een standaard formaat voor applicaties.

Het idee is dus dat je met je CI/CD tool (op dit moment gebruik ik Gitlab maar 'pick your poison') op het moment dat er een push naar je centrale repository gedaan wordt deze automatisch bouwt in een Docker image. Dit image kan je dan, als het ware een executable, op verschillende servers deployen. Test, productie, whatever. Het idee is dus dat je die specifieke container, met alle code daarin, daarna niet meer aanraakt. Dit betekent dus dat je heel makkelijk als er bijvoorbeeld een bug in de code blijkt te zitten een vorige versie kunt deployen.

Als developers zelf lokaal ook Docker willen gebruiken om in te werken; prima. Maar dat kunnen ze prima zelf lokaal doen. Wat belangrijk is dat je een vaste build-straat is, waarin code gecompiled wordt, test gerund worden (en de build faalt als deze falen!) een docker image gebouwd wordt en deze gedeployed wordt op een test omgeving. Van de productie deployment kun je dan een stap in je build maken die je handmatig triggered.

Ik lees nergens dat Rann dit allemaal nog niet heeft. (Als hij dit niet heeft, dan is dit inderdaad waar ie snel moet mee beginnen hoor, daar niet van).
De vraag van dit topic gaat eigenlijk alleen over de lokale debug omgeving voor de ontwikkelaars.

Als developers zelf lokaal ook Docker willen gebruiken om in te werken; prima. Maar dat kunnen ze prima zelf lokaal doen

Dat dus precies, en dat wil TS graag zo makkelijk mogelijk maken voor ze.

Een git-folder delen via een niet-git-weg is wel een probleem, als je vanuit beide kanten git commando's wilt kunnen draaien. Vooral als je dan ook nog eens over de Windows-Linux grens heen gaat. (Dit zou waarschijnlijk ook een probleem zijn met een volume mount)

Dus nogmaals mijn tip voor deze situatie: In de debug-situatie uitsluitend git commando's op je lokale systeem doen, vertrouwen op de ftp-sync, als je iets nieuws op wilt halen, doe dat lokaal en wacht op de ftp sync.

Echter als je vervolgens een git pull doet op de Docker omgeving, om bijvoorbeeld het werk van een collega binnen te halen, zal hij deze niet kunnen binnenhalen, omdat hij alle changes die je (via FTP) al hebt gedaan, niet kan overschrijven/discarden.

Doe dit dus op Windows....

[Hydra]

Rann schreef op woensdag 13 maart 2019 @ 09:06:
Ik snap je verhaal, alleen we hebben een omgeving nodig waarin we gewoon lokaal kunnen ontwikkelen (Bijvoorbeeld voor Magento), waar je je changes direct ziet, en Docker lokaal draaien werkt daar wel heel mooi voor.. Fuck je iets up, verse container starten en weer door. Updates aan een server? Image ook updaten en je developers werken lokaal met de laatste updates die ook op de online omgeving staan.

Dan snap ik het probleem niet. Mount gewoon die directory waar de code staat als volume in je draaiende container. Dan heb je altijd de laatste code.

Edit: FTP sync? Why? Docker heeft volume mounts...

[ Voor 3% gewijzigd door Hydra op 13-03-2019 09:19 ]

[MaffeMaarten]

Hydra schreef op woensdag 13 maart 2019 @ 09:12:
[...]
Edit: FTP sync? Why? Docker heeft volume mounts...

Hij schrijft zelf

Het idee van een gedeelde map heb ik ook vaker gehoord, echter schijnt dat een behoorlijke performance hit te zijn omdat we op Windows draaien, en de Docker op Linux, dat is niet wenselijk.

Klinkt alsof ie het nog niet geprobeerd heeft, lijkt me niet dat dit een grotere performance hit geeft dan ftp-sync inderdaad, maar goed.

[Kalentum]

MaffeMaarten schreef op woensdag 13 maart 2019 @ 09:22:
Klinkt alsof ie het nog niet geprobeerd heeft, lijkt me niet dat dit een grotere performance hit geeft dan ftp-sync inderdaad, maar goed.

Lijkt mij ook een raar verhaal. Meten is weten. Het is niet dat bij saven van edit het hele project opnieuw gecompileerd hoeft te worden. Ik vermoed dat hij veel met een 'edit-save-reloadbrowserwindow' workflow te maken heeft en dan is de performance impact minimaal.

[Hydra]

MaffeMaarten schreef op woensdag 13 maart 2019 @ 09:22:
Klinkt alsof ie het nog niet geprobeerd heeft, lijkt me niet dat dit een grotere performance hit geeft dan ftp-sync inderdaad, maar goed.

Dat volume mounts bij het draaien van Linux containers op Windows of MacOS een performance 'issue' hebben klopt. Alleen dat is natuurlijk puur relatief in de zin dat je dat niet wil doen om productie te draaien. Voor lokaal werk (en ik heb best grote databases in Docker op m'n mac gedraait) is het helemaal prima.

rutgerw schreef op woensdag 13 maart 2019 @ 09:26:
Lijkt mij ook een raar verhaal.

Neuh, het is een bekend issue dat de vertaling naar Linux IO naar Mac/Windows IO een overhead heeft. Maar dat is iets waarom je er geen productie op wil draaien, je merkt er in development niks van tenzij je erg zware IO doet.

[ Voor 24% gewijzigd door Hydra op 13-03-2019 09:29 ]

[MaffeMaarten]

Ik zou voor op de ontwikkel systemen liever die hit hebben dan bij elke save een vertraging door de ftp-sync.

Maar daar gaat het niet om hier. Je krijgt dan nog steeds problemen waarschijnlijk als je zowel op windows als in de docker git-commando's op dezelfde directory uit gaat voeren.

De vraag is ook waarom je dat zou doen. @Rann : Gaat het misschien om een script dat op de docker draait?
(Ik stel me een script voor dat ergens bijvoorbeeld sass en Typescript compilatie doet, en daarvoor nog een git pull ofzo.)
Dan is dat script waarschijnlijk niet (helemaal) van toepassing in de debug-situatie en zit daar je probleem.

[Hydra]

MaffeMaarten schreef op woensdag 13 maart 2019 @ 09:49:
Maar daar gaat het niet om hier. Je krijgt dan nog steeds problemen waarschijnlijk als je zowel op windows als in de docker git-commando's op dezelfde directory uit gaat voeren.

Is ook nergens voor nodig. Alles wat 'ie op z'n eigen machine doet, heeft die docker container ook als 'ie volume mounts gebruikt.

[mcDavid]

Rann schreef op woensdag 13 maart 2019 @ 08:51:

Het punt is, we zoeken een manier, waarop we de wijzigingen die we doen aan een website voor iedereen kunnen laten werken. Het ideaalst zou het zijn als iedereen op zijn eigen Docker inlogt, en direct daar werkt, en via de CLI alles commit etc. Helaas is Nano niet het ideaalste programma, en kunnen we niet van elke front-ender ook verwachten dat hij commits etc. doet via de CLI..

Vandaar dat we naar een soort van workaround aan het kijken zijn. Hoe kunnen ze met de tools die ze kennen (VSCode/GitKraken), dit werkend maken.

Het maakt op zich niet zoveel uit of je een GUI client of CLI client voor git gebruikt toch? Als mensen maar weten hoe ze een merge request kunnen maken en de upstream changes kunnen pullen.

Ik zie niet helemaal in wat je behalve dat nog meer nodig zou hebben?

Ja deployen vanuit CI pipelines en alles maken het leven tig keer makkelijker, maar zijn niet strikt noodzakelijk om fatsoenlijk colaborative te werken met GIT.

[edit] overigens kan ik me niet voorstellen dat een coder (of dat nou een frontender of backender is) niet kan leren hoe een command line interface werkt... maar goed, misschien is dat mijn bubble.

[ Voor 16% gewijzigd door mcDavid op 13-03-2019 10:37 ]

[Ed Vertijsment]

Volgens mij is wat je wil is dat je lokaal een productie-like omgeving hebt met daarin de latest and greatest wat betreft codebase.

Ik raad je aan dit op te splitsen in 2 requirements.

1. Je wilt dat je server config rewrite rules en alle operationele meuk gewoon lokaal werkt zoals in productie.
2. Je wilt altijd up2date werken.

Stap 1: Maak een docker(file) van de config en spin die op met een lokale mount naar de codebase van de dev in kwestie. Vergeet even de performance hit, dat is premature optimization.

Stap 2: Hoe doe je dit nu? Download je FTP bestandjes in visual studio en ga je daar op door? Prima, dan blijf je dat zo doen als dat bevalt. Wil je kunnen dealen met verschillende branches/tijdlijnen (dan bestaat er dus niet echt iets als up2date meer) dan ga je naar Git.

Mijn inziens moet alles gewoon in versiebeheer, en gebruik gewoon Git tenzij je een goede reden hebt om iets anders te gebruiken. Of je devs met gitrkaken of een cli gebruikt is aan hun om te bepalen. Maar kunnen werken met Git is volgens mij wel een beetje basiskennis geworden. Mocht je team daar behoefte aan hebben wil je dus wellicht even een klasje organiseren om het een en ander uit te leggen.

Hoe je stap 2 implementeert staat verdere helemaal los van hoe je het uitserveert, want je wilt namelijk gewoon met je lokale files werken als waarheid. Inloggen in een docker is niet echt best practice (en geeft ook een hit), daarnaast kun je dat net zo goed direct op Linux werken.

P.S. Ik weet niet hoe je het nu doet maar denk er ook over na hoe je lokaal je database bijhoud. Hebben jullie iets als migraties om mee te werken zodat iedereen lokaal zijn database makkelijk bij kan houden?

[Rann]

MaffeMaarten schreef op woensdag 13 maart 2019 @ 09:22:
[...]


Hij schrijft zelf
[...]


Klinkt alsof ie het nog niet geprobeerd heeft, lijkt me niet dat dit een grotere performance hit geeft dan ftp-sync inderdaad, maar goed.

Klopt inderdaad, ik kon het nog niet voor elkaar krijgen. Na aanleiding van de reacties hier toch weer ingedoken en het werkt, en ook zeker werkbaar! Performance heeft ook zeker een hit gekregen, maar is nog steeds te doen.

Nu hoeft iedereen alleen maar éénmalig op zijn/haar PC de docker runnen met het -v "c:/path/to/local/:/data/web/repository/" image/name commando toegevoegd.

Verder kunnen ze de lokale GitKraken gebruiken om alles te blijven updaten.

rutgerw schreef op woensdag 13 maart 2019 @ 09:26:
[...]


Lijkt mij ook een raar verhaal. Meten is weten. Het is niet dat bij saven van edit het hele project opnieuw gecompileerd hoeft te worden. Ik vermoed dat hij veel met een 'edit-save-reloadbrowserwindow' workflow te maken heeft en dan is de performance impact minimaal.

Precies dit

Ed Vertijsment schreef op woensdag 13 maart 2019 @ 12:07:
P.S. Ik weet niet hoe je het nu doet maar denk er ook over na hoe je lokaal je database bijhoud. Hebben jullie iets als migraties om mee te werken zodat iedereen lokaal zijn database makkelijk bij kan houden?

Nog niet, wijzigingen (bijv nieuwe modules, import tests), worden eerst op test (local) gedaan, en dan indien succesvol, dezelfde handeling word dan online uitgevoerd. (DB backup, site onbereikbaar maken voor buiten partijen,,db wijzigingen uitvoeren, indien mislukt, backup terugplaatsen).

In de Docker heb ik al wel standaard een script die gemakkelijk de laatste database kan ophaalt en de vervolgens de base-urls goed zet voor lokaal, dat scheelt al veel

[Donderpoes]

Misschien kan je het builden / runnen van de container(s) nog iets versimpelen voor je collega's door docker-compose te gebruiken.

En zet idd een fatsoenlijke CI/CD(/CM) straat op, waarin je alle linting/testing/compiling/transpiling/building aftrapt, bv in Jenkins, Travis, CircleCI, Gitlab CI etc...

[ Voor 40% gewijzigd door Donderpoes op 14-03-2019 22:24 ]