Het gebruik van Gitlab

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Veur Heur

Veur Heur

19/02/2024 18:25:05
Quote Anchor link
Ik werk al jaren als programmeur, maar in m’n eentje. Nooit aan versiebeheer gedaan onder het mom van “ik heb toch een backup of undo” maar nu zie ik dat mijn hoster gratis Gitlab aanbiedt en wil ik hier toch eens een keer naar kijken. Tot op heden werk ik eigenlijk alleen maar rechtstreeks op de server van de klant (ftp, ssh) die dus ook meteen de testomgeving is. Het ziet er niet naar uit dat ik met meerderen aan projecten ga werken. Mijn vragen:

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

PHP hulp

08/10/2024 04:44:53
 
- Ariën  -
Beheerder

- Ariën -

19/02/2024 18:35:07
Quote Anchor link
Biedt je hosting GIT aan, of Gitlab? Dat laatste is een platform om je eigen GIT-server mee op te zetten, die overigens best kolossaal is. (zie ook mijn topic)

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/
 
Veur Heur

Veur Heur

19/02/2024 18:40:20
Quote Anchor link
Ja, ze bieden Gitlab aan. Ik vind lokaal werken wat onhandig, maar dat kan natuurlijk ook de leercurve zijn. Er zijn mensen die veel beter webservers kunnen beheren dan ik, ben een developer, slechts deels beheerder.
 
- Ariën  -
Beheerder

- Ariën -

19/02/2024 18:43:04
Quote Anchor link
Dat is dus bij hun gehost.
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 -
 
Veur Heur

Veur Heur

19/02/2024 18:50:30
Quote Anchor link
Precies de reden waarom het me interessant leek, niet heel je code voor de hele wereld om te pakken én niet het onderhoud van je eigen Gitlab server, ondanks dat je het met een klik ook op je Synology hebt draaien, maar goed, ook dat heeft dan weer onderhoud nodig.

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
 
- Ariën  -
Beheerder

- Ariën -

19/02/2024 19:03:02
Quote Anchor link
Het deployen is iets waar je zelf een flow voor moet ontwikkelen. Het komt uiteindelijk neer op een clone commando en eventueel een checkout. Maar misschien heb je nog wat andere taken, zoals verwijderen van caches uit je website, of het renamen/kopieeren van bestanden met inloggegevens.

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 -
 

20/02/2024 07:33:15
Quote Anchor link
Git gebruik je lokaal EN remote tegelijk.
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.
Gewijzigd op 20/02/2024 07:35:28 door
 
Veur Heur

Veur Heur

20/02/2024 07:58:10
Quote Anchor link
Dank voor deze uitgebreide toelichting.
 



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.