Het gebruik van Gitlab
- Waar werk ik als met Gitlab werkt? Zoals gezegd heb ik nu de server van mijn klant, dus alles wat ik maak is meteen te testen in de omgeving waar het uiteindelijk komt te draaien. Obv IP of een if statement kom je een heel eind, allemaal geen raketwetenschap. Moet ik lokaal een servertje gaan draaien, bijv in Docker?
- Hoe komt m’n project uiteindelijk in de live omgeving? Toen ik “vroeger” ontwikkelde in een testomgeving (fysiek een aparte server), kopieerden we alles van de test naar de live omgeving via ftp en de was de kous af. Maar hoe werkt dit in een Gitlab omgeving?
Zo maar enkele vragen. Het opzetten van een repository en committen enzo daar zal ik vast m’n weg wel in vinden. Zal hierop mijn werkwijze uiteraard wel aan moeten passen en wellicht toch onderscheid moeten maken tussen test en live. Ik hoef ook geen commentaar over “hoe heb je zo kunnen werken als die jaren”, het werkte (en nog steeds) naar mijn tevredenheid en belangrijker die van de klant. Ik wil zelf gewoon weer wat leren als het interessant is.
Edit:
Topictitel verduidelijkt
Gewijzigd op 20/02/2024 12:53:12 door - Ariën -
Uiteindelijk ontwikkel je alles lokaal, en ook daar voer je de commits ook uit na je wijzigen. Als je alles online in de repository wilt plaatsen (zodat anderen eraan kunnen werken), dan push je het naar de git-server toe.
Leuke beknopte tutorial:
https://www.phphulp.nl/php/tutorial/overig/praktische-git-handleiding/780/
Ideaal voor besloten projecten waarvan je zeker bent dat het niet in een wereldwijde cloud staat, zoals GitHub.
Gewijzigd op 19/02/2024 18:43:34 door - Ariën -
Zal nog wel enkele tutorials moeten kijken hoor, want ik zie alleen het stuk versie beheer en samenvoegen uitgelegd, maar deployen is me niet duidelijk. Maar al snel vond ik dit soort uitleg: https://youtu.be/JovaNZyFhLI
In de praktijk kan je hier een bash-file voor maken die je deploy_live.sh of deploy_dev.sh noemt. Of een deftige webinterface die dit uitvoert. :-)
Gewijzigd op 19/02/2024 19:04:11 door - Ariën -
Lokaal om tijdelijke aanpassingen in op te slaan.
Remote om dagelijks, aan het einde van de dag, aanpassingen op te slaan zodat je een backup hebt.
Na een code review door een senior of lead developer kan je de aanpassingen mergen met de Ontwikkelversie waarin je eventueel samenwerkt met anderen.
Nadat het volledig getest is (unit tests*, integration tests en wat dies meer zij) kan je de aanpassingen doorzetten naar de Acceptatie-omgeving. Daar test de klant of het product is dat hij wil, en daarna kan het naar Productie. (OTAP-straat)
Als de Acceptatie- en Productie-omgeving niet bij de klant staan ('on premise'), maar bij je bedrijf ('SaaS') kan je ook kiezen voor een 'DevOps'-benadering, wat effectief betekent dat je een aantal stadia samenbrengt omdat je het allemaal zelf kan doen.
Dan heb je nog 'CI/CD' wat betekent dat je alles heel snel kunt doen, omdat het meeste is geautomatiseerd. Dan moet je scripts hebben om je code te packagen en te publiceren, en dan moeten clients zichzelf automatisch kunnen bijwerken. Dit gaat makkelijker als je SaaS aanbiedt, dan werkt alles via de browser en hoef je niet te publiceren en hoeven clients niet zichzelf te updaten omdat bij elke page refresh in de browser de laatste versie van de browser wordt opgehaald.
SaaS is ook een optie als je gebruik maakt van GPL-code maar het niet wil delen met anderen. Pas dan wel op dat je niets gebruikt wat de Affero GPL of iets soortgelijks gebruikt, dan ben je juridisch in overtreding.
Ik hoor je Synology noemen, daarop kan je eenvoudig een Git server hosten zonder gedoe: https://kb.synology.com/nl-nl/DSM/help/Git/git?version=7
Dat is wel zo veilig. Wanneer het internet uiteen gaat vallen in een splinternet. Of wanneer een statelijke actor (Rusland?) de oceaankabels naar de VS saboteert en er bijna geen verkeer meer mogelijk is. Dan kan je makkelijker voldoen aan je contracten met de klant. Of je doet het allebei. Alleen moet je dan niet heel verbaasd zijn als je code ineens door ChatGPT wordt aangeboden aan een ieder die er om vraagt. Dat hangt er weer vanaf of je code echt FLOSS mag zijn.
* @Ward; ja ik maak inmiddels ook gebruik van unit tests, nu ik ze onderaan elk bestand kan toevoegen en apart kan uitvoeren vanuit Codium. Is nog sneller ook dan testen in de browser, en maakt TDD makkelijk.