[GIT] Meerdere repositories naar 1, best practice

[Sneezydevil]

Op dit moment gebruiken wij Git voor onze software ontwikkeling, we hebben het als volgt ingericht. Onze software bestaat uit allemaal modules, voor elk van deze modules hebben we een repository. De projecten voor klanten kunnen meerdere modules bevatten voor elk van deze projecten is er ook een repository.

Voorbeeld van de workflow

Developer pusht een update van een module naar de server, de server kijkt van welke projecten de module onderdeel is en zorgt dat die repositories geupdate worden, afhankelijk van de branch wordt dan de development of staging server voorzien van deze nieuwe versie.

Bijvoorbeeld:

Developer A pusht naar Module A [Develop]
Server update Project A B en D
Development server wordt voorzien van nieuwe code Project A B en D [Develop]

Developer B pusht naar Module C [Master]
Server update Project A C D en F
Staging server wordt voorzien van nieuwe code Project A C D en F [Master]

Nou werkt dit allemaal perfect en gebeurd dit allemaal automatisch, maar ik vroeg mij af of het makkelijker kan en of deze werkwijze misschien problemen met zich mee kan brengen.

We gebruiken trouwens gitflow, dus master en develop zijn niet de enige branches die aanwezig zijn.

Ik ben zelf niet zo'n git expert, en kon niet echt onderdelen van git vinden om dit process te vermakkelijken.

[EddoH]

Wellicht kun je eens kijken naar 'Repo'. Dit is een laag bovenop git, die het werken met meerdere repository's in 1 project gemakkelijker maakt. Het is ontwikkeld door Google en wordt bijvorbeeld bij Android (platform) development gebruikt.

https://code.google.com/p/git-repo/

Ik mis in je vraag nog een beetje een probleemstelling. Wat gaat er nu mis, of waar loop je tegen aan? Het is moeilijk kadvies te geven als er neit duidelijk isw at het echte probleem nu is.

[Sneezydevil]

Ik zal es kijken naar Repo, dat is misschien al een heel goed begin, klinkt in ieder geval goed.

Buiten wat meer onderhoud hebben we eigenlijk niet veel problemen, maar de scripts die we gebruiken om dit allemaal te doen, onderhouden we intern.

Voor dat we gitflow hier op het forum ontdekten, waren we dit allemaal zelf aan het doen, gitflow maakt dit allemaal veel makkelijker.

Daarom dat ik mij afvroeg of er net zoiets was voor het mergen van de repositories, nu maken we de scripts zelf.

[Rekcor]

Mijn vraag is hieraan gerelateerd: onze software bestaat uit een aantal modules (A, B, C, ...), die we in verschillende git-repositories beheren. De modules communiceren via APIs met elkaar.

Ons probleem is met name die APIs: soms passen we die aan, waardoor bijv. module A versie 2.0 alleen werkt met B versie 1.2 en hoger en C versie 4.5 en hoger. Deze versies geven we nu aan met 'tags' in de verschillende git-repo's.

Hoe kunnen we zorgen dat een update bij een klant goed gaat? D.w.z. hoe kunnen we borgen dat - als hij bijv. A versie 2.0 krijgt - hij ook automatisch B v1.2 en C v4.5 krijgt?

We hebben diverse tools/manieren (waaronder git's submodule systeem) geprobeerd, maar die hadden ook weer nadelen.

[Bloemkoolsaus]

Wij gebruiken hiervoor Composer: https://getcomposer.org/doc/00-intro.md
Hiermee kunnen we aangeven welke libraries/depencies we hebben/willen EN welke versie.

[FoOnEeN]

Wij hebben hiervoor verschillende packages die via nuget lopen. Elke repository heeft een of meerdere modules die via nuget packages ergens centraal beheerd worden. Die packages kunnen ook weer dependencies hebben op andere packages, en daar kan je gewoon aangeven welke versie van die packages minimaal benodigd zijn voor die module. Bij een push naar de master krijg je automatisch een nieuw package beschikbaar. Updaten van package versies binnen modules is nog wel handmatig.

Dit gaat overigens wel over C# ontwikkeling met Visual Studio, waar dit allemaal in geïntegreerd zit.