git strategie voor website met meerdere varianten

[amphora]

Voor een klant heb ik een laravel website gemaakt en alles gaat via een GitHub repo en met Laravel Forge deploy ik na iedere push automatisch. Nu wil mijn klant van de bestaande website drie varianten (dus vier in totaal), qua functionaliteit bijna gelijk maar andere vormgeving en database. Nu twijfel ik hoe ik dit het beste kan opzetten. Clone ik de gitrepo drie keer en hou ik dus vier repo's over waarbij ik de master branch als productie hou, of ga ik per site binnen de huidige repo een branch maken, dus site A,B,C,D en een master en dan A,B,C,D deployen. Maar misschien is er nog een derde optie waar ik nog niet aan gedacht heb? Dacht eerst een fork maken maar een fork moet naar een ander account kwam ik achter.

Punt is als ik functionaliteit aan site A toevoeg ik dit ook meestal bij B, C en D wil maar wellicht niet altijd. Ook verwacht ik subtiele verschillen in de codebase dus 4x master deployen en alleen kunnen customizen via database of environment is eigenlijk niet echt een optie denk ik. Maar vier losse repo's maakt updates uitrollen ook weer onnodig ingewikkeld (en foutgevoelig).

Ben benieuwd naar suggesties voor de beste aanpak.

[ Voor 4% gewijzigd door amphora op 19-03-2025 11:16 ]

[Cartman!]

Maak een soort theme-functionaliteit in je app en bepaal tijdens deploy welke config (voor db) en welke theme deze moet krijgen. (Subtiele) verschillen kun je afhandelen met feature flags.

[ Voor 18% gewijzigd door Cartman! op 19-03-2025 11:52 ]

[frAmEd]

4 repo's onderhouden lijkt mij qua onderhoud en consistentie zeer omslachtig. Zoals hierboven genoemd zijn feature flags een goede oplossing om subtiele verschillen op te vangen, maar dit is wat mij betreft alleen een goede oplossing als je op termijn niet verwacht dat je een wildgroei aan subtiele verschillen krijgt.

[Webgnome]

Aangezien het minimale verschillen (lijken) te zijn zou ik inderdaad gaan voor de oplossing die @Cartman! voorsteld. Zorg dat je .env en dat soort zaken specifiek zijn voor de omgeving ( die staat toch niet in je repo...) en maak daar waar nodig aanpassingen op basis van de verschillen die nodig zijn.

Zorg dat je dan op basis van het app_enviromment of ander env variabel kunt detecteren waar je zit en zorg dat de juiste code paden af gaan. Een andere 'oplossing' zou zijn dat je dit soort zaken in een losse plugin stopt die je via composer dan in je omgeving installeert en dan op basis van een setting oid kunt bepalen welke branch / tag van die plugin je nodig hebt

[amphora]

Ik heb inderdaad (voor nu) gekozen voor één repo en met .env geef ik per site aan welke extra css file er geladen moeten worden. Ook heeft iedere site een eigen database waar ik een settings tabel in heb om site specifieke dingen aan te kunnen passen. En waar nodig in controllers nog een paar extra if {} condities.

Bedankt voor de reacties en suggesties!

[ Voor 6% gewijzigd door amphora op 21-03-2025 13:11 ]