Git workflow

[Mas-ih]

Hallo medetweaker,

Omdat mijn webapplicatie steeds groter wordt qua functionaliteit en up-time steeds belangrijker wordt, wil ik het test en deployment procedure gaan verbeteren. Op dit moment ontwikkel ik en test ik lokaal en als alles goed gaat zet ik de changes naar productie. Dit doe ik middels git.

In het begin heb ik het als volgt opgezet. Op de server een repo gemaakt en deze ge-cloned naar mijn laptop. Op mijn laptop maak ik dus changes, merge het naar master en push het naar productie. Zo werk ik al ruim een jaar en werkt op zich prima.

Ik had nog een rpi liggen en heb hier een servertje van gemaakt met dezelfde versie van apache, php en mysql als op de server waar de applicatie op draait. Hier heb ik de git repo naar toe gekopieerd (mapje .git vanuit de server naar rpi via ftp). En ook de applicatie op de rpi gezet.

Nu werk ik op de volgende manier. Op mijn laptop maak ik vanuit 'master' een 'feature' branch. Deze test ik lokaal en als het goed is, merge ik het naar een 'test' branch en push ik het naar de rpi. Hier doe ik dan nog meer testen (bedoeling is om ook automatische tests te ontwikkelen). Als alles goed gaat, merge ik 'test' naar master en push ik master naar productie.

Nu is mijn vraag of dit de juiste manier van werken is? Hebben jullie tips om dit op een betere manier op te zetten? Ik ben geen ontwikkelaar in mn dagelijkse leven en heb alles mezelf aangeleerd uit interesse/hobby

Sorry voor de lange post en alvast dank voor jullie feedback!

[Voutloos]

Je gebruikt feature branches en gaat heel bewust om met test en prod versies. Je werkt in je eentje en hebt geen langlopende parallele branches of rewrites?

Je model klinkt redelijk, delivery gaat netjes. Dus werk inderdaad aan tests en CI en ga zo door zou ik zeggen.

Anders moet je iets specifieker benadrukken waar je issues ervaart...

[armageddon_2k1]

Werkt het voor jezelf goed of loop je tegen problemen aan? Het klinkt als een goede methode en wij doen dit ook grotendeels in ons team van 5. Niet gaan over engineeren als het niet nodig is

[Johnny]

De terminologie die je zoekt zijn CI (Continous Integration) en CD (Continious delivery). Als wat je nu hebt goed werkt kan je het niet veel beter maken. Mijn ervaring is dat wanneer je eenmaal een workflow hebt die werkt je beter niet teveel aan kan veranderen want je nieuwe workflow zal onverwachte problemen hebben die je moet wegwerken.

De meeste informatie die je zal vinden over dit soort processen is bedoeld voor grotere teams met meerdere servers voor testing/staging en ook meerdere web/databaseservers in de productieomgeving en zal overkill zijn voor jouw huidige situatie.

Als uptime belangrijk is, heb je monitoring daarvoor? Je kan bij een dienst zoals Uptimerobot gratis email alert krijgen als je website down is.

Hoe ga je nu om met database-migraties? Of is dat niet van toepassing?

Zijn er caches op de server die moeten worden geleegd na de deployment? Zo nee, dan zou je de performance waarschijnlijk wel kunnen verbeteren door die wel te gebruiken, maar de deployment wordt dan complexer.

Gaat de webapplicatie in "maintenance mode" tijdens de deployment? Wat krijgen bezoekers die halfverwege de merge de applicatie gebruiken?

[Haan]

Het mergen van een feature branch naar een test branch, enkel om dat naar een testomgeving te deployen is het enige dat niet heel logisch is. Aangezien je toch alleen werkt zou je je feature branch ook direct moeten kunnen deployen naar een testomgeving. Dan hoef je daarna alleen naar master te mergen.

[ThomasG]

Haan schreef op maandag 5 oktober 2020 @ 10:34:
Het mergen van een feature branch naar een test branch, enkel om dat naar een testomgeving te deployen is het enige dat niet heel logisch is. Aangezien je toch alleen werkt zou je je feature branch ook direct moeten kunnen deployen naar een testomgeving. Dan hoef je daarna alleen naar master te mergen.

Of je wel of niet alleen werkt is helmaal geen argument. In veel gevallen is het hebben van een test branche handig, ook als je alleen werkt.

[Nick_S]

Mas-ih schreef op zondag 4 oktober 2020 @ 16:45:
Op de server een repo gemaakt en deze ge-cloned naar mijn laptop. Op mijn laptop maak ik dus changes, merge het naar master en push het naar productie. Zo werk ik al ruim een jaar en werkt op zich prima.

Wil je even controleren dat op de productieserver je .git directory niet publiekelijk (zonder authenticatie) beschikbaar is? Anders kunnen mensen vrij makkelijk je git repository clonen en je history doorpluizen. Daaruit haal je vrij snel wachtwoorden, library versies (waar dus exploits op kunnen zijn) of andere zwakheden in je applicatie.

Toestemming nodig voor bekijken van YouTube

Op deze plek staat ingesloten content die van YouTube afkomstig is. Het tonen van deze inhoud kan ertoe leiden dat YouTube persoonlijke gegevens zoals je IP-adres verwerkt en/of cookies op jouw computer of ander apparaat zet. Hiervoor moet je eerst expliciet toestemming geven voor Sociale media.

Open cookievoorkeurenBekijk op YouTube

Git Happens - Public .git Repositories

[ Voor 8% gewijzigd door Nick_S op 05-10-2020 11:05 ]

[Voutloos]

Nick_S schreef op maandag 5 oktober 2020 @ 11:03:
Wil je even controleren dat op de productieserver je .git directory niet publiekelijk (zonder authenticatie) beschikbaar is?

Schadelijk advies, want dit is een blacklist.

De goede manier om op dit issue te wijzen:
Wil je controleren dat enkel een expliciete publieke map geserveerd wordt? Zodoende lek je je .git niet, maar ook niet je configuratie, code en alles waar je nu niet aan denkt.

[Hydra]

Je wil je .git dir uberhaupt niet op je productieserver hebben. 'Gewoon' een kwestie van een echte deployment inrichten. Build -> Docker container (of zip file voor mijn part) -> Via een secure manier alleen de relevante (compiled) code deployen.

[ Voor 34% gewijzigd door Hydra op 05-10-2020 14:22 ]

[Nick_S]

Voutloos schreef op maandag 5 oktober 2020 @ 14:14:
[...]
Schadelijk advies, want dit is een blacklist.

De goede manier om op dit issue te wijzen:
Wil je controleren dat enkel een expliciete publieke map geserveerd wordt? Zodoende lek je je .git niet, maar ook niet je configuratie, code en alles waar je nu niet aan denkt.

Ik heb helemaal geen advies gegeven hoe dat moet gebeuren, maar alleen dat het niet beschikbaar is en volgens mij klopt dat ook. Ik werd getriggerd door het naar productie pushen wat er in de openingspost stond.

[Voutloos]

Ik zei het een tikkie hard, maar dat komt vooral door het geforceerd hippe, overproduced kutfilmpje dan door jouw neutrale tekst.

Stevig reageren op specifieke blacklists is 1 van mijn levensmissies.

[ Voor 22% gewijzigd door Voutloos op 05-10-2020 15:21 ]

[Mas-ih]

Bedankt allemaal voor de feedback! .git is niet publiekelijk toegankelijk net als alle andere folders uitgezonderd de public_html folder.

Hydra schreef op maandag 5 oktober 2020 @ 14:18:
Je wil je .git dir uberhaupt niet op je productieserver hebben. 'Gewoon' een kwestie van een echte deployment inrichten. Build -> Docker container (of zip file voor mijn part) -> Via een secure manier alleen de relevante (compiled) code deployen.

Heb je hier iets meer info over of tips waar/wat ik zou kunnen zoeken? Webapplicatie is gemaakt met Laravel, mocht dat iets uitmaken.

[CurlyMo]

Mas-ih schreef op dinsdag 6 oktober 2020 @ 13:49:
Heb je hier iets meer info over of tips waar/wat ik zou kunnen zoeken? Webapplicatie is gemaakt met Laravel, mocht dat iets uitmaken.

Dat heeft @Johnny al gezegd. Ga je inlezen in CI en CD en hoe dat gangbaar met Laravel projecten wordt ingericht. Genoeg over te vinden.