GIT-Setup voor groot project

[P_Tingen]

We zijn nu bezig met het introduceren van GIT en een nieuwe ontwikkelomgeving voor de ontwikkelaars. De applicatie waar we mee werken is een groot ERP systeem voor een internationaal productiebedrijf. We hebben een standaard applicatie waar veel op wordt aangepast. We proberen zoveel als mogelijk die aanpassingen gelijk te houden voor alle fabrieken maar dat lukt niet altijd. Bovendien zitten we nog met een erfenis uit het verleden waarbij er te snel werd gekozen voor een fabriek-specifieke oplossing.

De code voor een willekeurige fabriek bestaat dus altijd uit drie lagen:

1. De 'main' laag (de code van het ERP systeem zelf)
2. De 'core' laag (code die wij gemaakt hebben en voor iedereen gelijk is)
3. De 'local' laag (code specifiek voor een fabriek)

De vraag is nu een beetje of we dit ook handiger kunnen inrichten. Het antwoord is "ja" want elke fabriek heeft FYSIEK ook deze drie lagen. De main-laag staat dus 12 keer (want 12 fabrieken) ergens op een schijf van een server. De core-laag idem dito. Van de local laag zijn er dus 12 varianten, maar dat is dan ook de enige waar dat verdedigbaar is.

Onze vorige software architect was bezig met een verbeterplan, maar vond - voordat hij klaar was - een betere baan. Lekker dan, dus nu zitten wij er weer mee. We willen dit oplossen. We gaan GIT gebruiken maar we zijn er nog niet over uit hoe dat dan moet. GIT submodules hebben we mee geëxperimenteerd maar dat lijkt meer problemen te introduceren dan op te lossen.

Het nieuwe idee is om alles in 1 repository te gooien, maar dan met subfolders voor main, core en local en onder local subfolders per fabriek, dus zoiets:
 
- erp-project
   - main
   - core
   - local
      - fabriek-1
      - fabriek-2
      - fabriek-3
...

We hebben dan als voordeel dat zowel de main als core laag ook echt maar 1 keer voorkomt. Nu hebben we op verschillende servers soms wel eens verschillende versies staan van wat eigenlijk hetzelfde hoort te zijn.

Het probleem zit hem hier in de local lagen. Bij het ontwikkelen wil je niet alle local lagen in je zoekpad hebben omdat fabriek X niks met de code te maken heeft met fabriek Y.

Het kan namelijk zo zijn dat een programma bestaat in zowel de main, core als local laag. Het is dan een programma van onze ERP-boer dat we zelf overruled hebben met een eigen versie. Voor een individuele fabriek zou er evt een nóg specifiekere versie kunnen bestaan. We zijn overigens bezig met een opschoonactie om de local laag zo klein mogelijk te maken. Zaken die we kunnen regelen middels configuratie in de code verhuizen we naar de core-laag. Voordat alles is opgeschoond zijn we nog wel even verder want de complete codebase (dus main, core + 12 locals) is ruin 57000 source code bestanden.

Mijn vraag aan jullie is of er nog zaken zijn waar we naar kunnen kijken binnen GIT hoe we dit goed kunnen managen. Oftewel: hoe zouden jullie dit doen?

[afraca]

Ik had hier in eerste instantie iets over submodules staan, maar zag opeens dat je daar problemen mee krijg. Ergens lijkt het me misschien nog wellicht soort van een oplossing, wat was je probleem daarmee precies?

Wat je ook kunt doen is selectief branches aanmaken per locatie en die dan beperkt pushen/pullen zodat je geen vervuiling krijgt. Dat vereist dat je "op locatie" wel selectief moet gaan mergen en dergelijke.

[itons]

Klinkt alsof je elke fabriek een eigen repository wilt geven en de gedeelde code als dependency binnen moet halen?

[RobIII]

Ik roep even heel breed wat hoor, maar is een "core" taggen met versies niet te doen en dan de locals tegen een bepaalde tag aan compilen? Daarmee kun je toch met je locals de core evolueren zonder dat andere locals daar (meteen) "last" van hoeven te hebben. En dan dus gewoon een repo voor core en main en een local met branches per fabriek. Maar misschien zie ik 't te simpel.

[johnkeates]

Je zal met vrij veel repositories gaan werken als je dit klaar wil spelen. Ik weet niet wat voor dependency management je nu gebruikt, maar als er al SCM/VCS support bij zit kan je gewoon losse repositories gebruiken.

Je maakt zoals je al hebt staan main, core en per fabriek repositories. In een fabrieksrepo zou je dan kunnen kiezen om met branches te werken om verschillen tussen de lagen binnen die fabriek makkelijk te kunnen delen.

Wat voor Git oplossing wordt er gebruikt? Kale git en ssh? GitHub? GitLab?

[kwaakvaak_v2]

De vraag is meer hoe de fysieke directory indeling is van de projecten. Ik doe hier, op een ander niveau misschien, ongeveer hetzelfde met een multi-website omgeving.

Ik heb de core als eigen git repository, en alle websites staan in fysieke subdirectory van die core, en elke website is een eigen repository.

De core is netjes gebranched in de verschillende releases, op die manier kan ik met cherrypicking relatief gemakkelijk code van branch X naar branch Y overhalen. Of een nieuwe installatie doen op basis van Branch X.

code:

|-Core 
|--Sites
|---Site 1
|---Site 2
|---Site 3

Voordeel is dat de sites op die manier gescheiden containers zijn, en ik ook vrij vlot een development installatie kan opzetten voor één site, zonder dat ik de andere 20 er ook bij krijg in mijn IDE.

Met een .gitignore in de core heb ik aangegeven dat alles sites/* mappen genegeerd mogen worden.

Uitchecken van een nieuwe installatie is niet meer dan

git checkout core <directory>
git checkout site1 <directory/sites>

[Blubber]

Misschien snap ik het niet helemaal, de informatie is ook wat dun gezaaid, zonder meer informatie over de architectuur valt er niet veel zinnigs over te zeggen. Maar mijn vraag is eigenlijk, waarom is dit uberhaupt een probleem?

Want (met de beperkte achtergrond) zou ik zeggen, je gaat voor die laatste optie, dus de locals in eigen sub directories. Ik ga er dan vanuit dat elke local een vergelijkbare interface implementeert, dan gebruik je per fabriek een andere configuratie voor je DI container om de juiste local te krijgen.

Het klinkt een beetje alsof je een probleem met de architectuur probeert op te lossen met git, wat niet de bedoeling is lijkt mij. Mijn punt is, het daadwerkelijk kiezen van de correcte local lijkt mij een configuratie issue.

[Lethalis]

Blubber schreef op donderdag 23 april 2015 @ 16:29:
Het klinkt een beetje alsof je een probleem met de architectuur probeert op te lossen met git, wat niet de bedoeling is lijkt mij.

Dit idee heb ik ook.

Het enige dat ik de hele tijd denk is "waarom hebben ze niet gewoon 1 versie van het product, met specifieke plugins / programma's die daar op aansluiten?".

Ik werk zelf ook aan een ERP pakket op mijn werk dat staat bij meer dan 20 klanten in het land, elke met hun eigen wensen. Veel hebben we gewoon opgelost met configuratiewaarden. Ik zeg niet dat dit geweldig is, want het kan best een ellende zijn om alles goed in te stellen Maar we hebben iig maar 1 code base.

De meeste ellende hebben wij eigenlijk bij het updaten van een klant naar de nieuwste versie. Want dan moeten we ook het databaseschema bij de klant bijwerken naar de juiste versie. We houden om die reden dan ook in een bestandje alle databasewijzigingen bij.

Je moet ook bij elke nieuwe optie goed nadenken over de default waarde.

Anyways.. als ik de topicstart zo lees, dacht die architect gewoon "ik moet weg hier" toen hij naar de bestaande architectuur keek

[chime]

Aparte branch per local-fabriek.

Wil je aan de local van een bepaalde fabriek werken dan check je die uit en werk je daar aan.
Wil je switchen naar een ander fabriek - dan doe je da ook gewoon, stel voor dat er daar een P1 bug in het systeem van factory1 zit, gewoon even branch switchen via een simpel commando, fix implementeren, commiten en releasen. Daarna switch je terug naar de branch van factory2 waar je aan een nieuwe feature aan het werken was.

Changes die voor alle branches gemaakt zouden moeten worden in de local kan je dan ook relatief makelijk mergen - 1 branch uitchecken, nieuwe branch maken, wijzigingen uitvoeren - die laatste branch dan mergen met de rest.

De ERP en Local zijn best dependencies op die local projecten.
Op die manier kan je bijvoorbeeld een nieuwe versie van het ERP systeem of je local library in 1 fabriek uitrollen en de rest nog op het oude systeem laten staan.
Als dat in orde is pas je daarna de versie aan in de andere locals en rol je daar uit.

Maar ik zou ook zeggen - speel er eens mee, voel gewoon wat voor jullie het beste werkt.
Want het is vaak toch door wat te spelen/experimenteren dat je meer gaat leren over wat jij nu echt nodig hebt en wat voor jullie echt werkt.

[ Voor 11% gewijzigd door chime op 24-04-2015 12:50 ]

[P_Tingen]

Blubber schreef op donderdag 23 april 2015 @ 16:29:
Het klinkt een beetje alsof je een probleem met de architectuur probeert op te lossen met git, wat niet de bedoeling is lijkt mij. Mijn punt is, het daadwerkelijk kiezen van de correcte local lijkt mij een configuratie issue.

Ik denk dat je gelijk hebt. Het probleem is een beetje dat onze architect redelijk goed voor ogen had wat hij wilde, maar nu weg is. Verder geen kwaad woord over hem, want geschikte peer, maar het is voor ons een beetje jammer dat de overdrachtsperiode vrij kort was. Dat had allerlei redenen die niet zo interessant zijn, maar er is genoeg voor ons uit te zoeken. We zijn met een team van dik 20 ontwikkelaars dus verkeerde keuzes kunnen vervelende gevolgen hebben; ik wil niet graag uitleggen aan het management dat we maar wat aan hebben zitten kloten

Goed. Wij - als stelletje éénogen - hebben ook al bedacht dat een structuur met de lokale sites als subfolder de way to go is. We ontwikkelen in Eclipse en het selecteren van de goede tak voor het compileren is een configuratie-issue. Dat moeten we ook nog uitzoeken overigens.

We werken met GitLab. Een paar experimenten met submodules laten zien dat die wat lastig te updaten zijn vanuit Eclipse. Je moet al een commando ingeven in de git-bash om ervoor te zorgen dat alles up-to-date is. We hadden gehoopt dat Git ons hier iets meer zou helpen.

Lethalis schreef op vrijdag 24 april 2015 @ 12:47:
Het enige dat ik de hele tijd denk is "waarom hebben ze niet gewoon 1 versie van het product, met specifieke plugins / programma's die daar op aansluiten?".

Ik werk zelf ook aan een ERP pakket op mijn werk dat staat bij meer dan 20 klanten in het land, elke met hun eigen wensen. Veel hebben we gewoon opgelost met configuratiewaarden. Ik zeg niet dat dit geweldig is, want het kan best een ellende zijn om alles goed in te stellen Maar we hebben iig maar 1 code base.

We willen hier ook naar toe, dat is het punt. We hebben nu een situatie die in het verleden uit de hand is gelopen. Een van de redenen was een manager die teveel gericht was op snel uitrollen van features en developers die te weinig tegengas hebben gegeven, waaronder ook ikzelf overigens.

De "main" laag is de laag van het ERP dat we ingekocht hebben. Voor een deel is die code zelfs encrypted. Het is niet de bedoeling dat we zelf daar aanpassingen op doen. De laag daaronder is de "core" en dat is de laag van onszelf die voor alle fabrieken gelijk moet zijn. De lokale laag is voor echte verschillen, bv omdat ze in sommige landen koppelingen hebben met douanesystemen of applicaties van derden die alleen in die ene fabriek van toepassing zijn. Deze laatste laag willen we zo klein mogelijk houden en vooral maken door code die nu hier in zit te verhuizen naar de core-laag en dan geparameteriseerd aan te roepen.

chime schreef op vrijdag 24 april 2015 @ 12:47:
Aparte branch per local-fabriek.

Wil je aan de local van een bepaalde fabriek werken dan check je die uit en werk je daar aan.
Wil je switchen naar een ander fabriek - dan doe je da ook gewoon, stel voor dat er daar een P1 bug in het systeem van factory1 zit, gewoon even branch switchen via een simpel commando, fix implementeren, commiten en releasen. Daarna switch je terug naar de branch van factory2 waar je aan een nieuwe feature aan het werken was.

Hmm, kweet niet. We hebben 12 fabrieken en voor elke fabriek wil men een ontwikkel- test- en productieversie hebben. Dat zou dan al 12x3 branches zijn? Het management wil naar een handvol releases per jaar toe, dus we zaten meer te denken om daar onze branching op af te stemmen.

Een van onze kleinere projecten dient nu als een speeltuin omdat die dezelfde problematiek kent. Het probleem is alleen dat - in ieder geval ikzelf - niet veel ervaring heb met GIT en dus lastig kan inschatten wat handig is en wat voor constructie voor problemen gaat zorgen.

We spelen in ieder geval even verder.

[H!GHGuY]

P_Tingen schreef op vrijdag 24 april 2015 @ 18:26:
[...]

Hmm, kweet niet. We hebben 12 fabrieken en voor elke fabriek wil men een ontwikkel- test- en productieversie hebben. Dat zou dan al 12x3 branches zijn? Het management wil naar een handvol releases per jaar toe, dus we zaten meer te denken om daar onze branching op af te stemmen.

Een van onze kleinere projecten dient nu als een speeltuin omdat die dezelfde problematiek kent. Het probleem is alleen dat - in ieder geval ikzelf - niet veel ervaring heb met GIT en dus lastig kan inschatten wat handig is en wat voor constructie voor problemen gaat zorgen.

Je branching strategie moet je workflow volgen. Er zijn typisch 2 straegieën:
- feature releases. Iemand bepaalt welke features in de release moeten en iedereen begint als een malloot te coden tot het af en getest is, waarna je een release buiten duwt.
- time-based releases. Typisch heb je dan een release cadence, en een lijst van geprioritiseerde features. De features die af zijn komen in de release, de rest schuif je door tot de volgende.

Bij feature releases, maak je een branch per release, waar alle code voor die release op komt.
Bij time-based releases, maak je een branch per feature en merge je naar een release branch wanneer je feature af is.

Dit is helaas slechts de simpele versie Het kan bijvoorbeeld zijn dat je nightly builds hebt op time-based releases. Helaas zitten daar de niet-gemergede features niet in... Tenzij je een integration branch hebt, waar iedereen op tussenpunten in de development naartoe merged. Deze komt nooit in je release branch maar dient enkel om nightlies mee te maken.
Of je merged je feature branches eerst naar een QA branch voor testing + fixes. Van daar wordt doorgemerged naar bvb de master. Je kan dan nog kiezen voor een branch per release voor post-release bugfixes.

Deze beschrijving zou al moeten duidelijk maken dat branches modelleren hoe jullie development, testing en release model eruit ziet. Dat is iets wat jullie moeten beslissen voor jullie organisatie.

Er was een tijd waarin ik zou zeggen dat je branches ook moet gebruiken voor per-fabriek development, maar daar moet je ook mee opletten. Je vervalt al makkelijk in een hydra van branches die je later niet meer kunt temmen. Bovendien is het dan moeilijk om code die plots voor een 2de fabriek ook nuttig is individueel in te mergen in die andere branch - er zit immers veel andere troep ook op die branch.
Zoals hierboven aangehaald, kan het een goed idee zijn om alle fabriek-specifieke code op te nemen in de core-laag en om ze weg te steken achter configuratie. Zo zit alle code in 1 grote repo. Testing van combinaties van features die tot op heden niet samen gebruikt worden kan dan natuurlijk een troep worden. Dan moet je bijna voor elke configuratie change je volledige test-suite doorlopen.

To submodule or not to submodule... Wij steunen hevig op submodules aangezien we van CVS kwamen waar we gebruik maakten van subdir checkouts voor framework-alike code. We maken er ook gebruik van om verschillende sub-projecten (waar mensen afzonderlijk checkouts van doen) in een top-level project bij elkaar te houden en om dus versies via de submodule references uniek vast te leggen. We hebben er ook een hoop scripts voor geschreven om standaard (branch creation, pull --rebase, checkout, push, referential integrity, ...) taken over submodules heen te kunnen doen. Natuurlijk willen we ook zoveel mogelijk van die scripts terug af (want te weinig mensen leren er echt git mee), tenzij waar het echt gewoon tijd bespaart.
Ikzelf gebruik die scripts nauwelijks en werk liever command-line, ook met submodules. Er zijn wel enkele nadelen aan verbonden. Bvb een git status toont de status van de submodule, niet van de files erin.

Submodules in git zijn ooit bedoeld om bvb required (externe) libraries in je project te krijgen zodat je de header files beschikbaar hebt om te builden. Ze waren eigenlijk niet bedoeld om in de submodule te beginnen developen. Anderzijds is de support voor submodules in alle git commando's gestaag aan het verbeteren, maar echt snel gaat het nu ook weer niet.
Misschien nog een andere tip die je werk/tijd kan besparen: git heeft support voor soft-links.

itons idee:

code:

fabriek1 (project files zitten hier)
\_ main (submodule)
\_ core (submodule)
\_ local code

Voordeel: fabriek-specifieke code naar de core moven is niet zo moeilijk. Maar testen dat die nieuwe code ook voor de 11 andere fabrieken werkt wel. CI kan hier echter wel in helpen.
Verder zitten de build dependencies wsch ook exact zo in elkaar: fabriekX -> core -> main
Je kan ook de code van elke fabriek individueel uitchecken, builden, testen en deployen.
Je kan per fabriek een andere versie/branch van core en main hebben.

Op termijn kan je hier migreren naar een local code die eigenlijk nog enkel bestaat uit een configuratie bestand. Dan heb je nog opties om alle configuratie bestanden te bundelen in 1 repo, of ...

jullie idee:

code:

core
main
local
\_ fabriek1 (project files zitten hier)
|   \_ core (soft-link)
\   \_ main (soft-link)
\_ ...
\_ fabriekN

Voordeel: alles zit lekker samen. Voor refactoring ideaal - leer "git grep" gebruiken. Je zou voor build scripts kunnen soft-links in fabriek1 maken naar de core en main zodat je search paden per project beperkt blijven. Of je stopt 1 grote project file in de top-level met evt sub-projecten in de fabriek-dirs (en core/main?)
Nadeel: Afzonderlijk uitchecken kan niet (dus ook niet voor CI/CD).
Hier is het ook zo dat alle fabrieken altijd de laatste/zelfde core en main gebruiken. Zomaar even een minor update in de local code van fabriek1 doen zonder de core/main te updaten kan niet.


Alles komt dus echt neer op workflow. Hoe werken jullie nu en hoe willen jullie in de toekomst werken. Wat zijn de dagelijkse acties (die zonder overhead moeten kunnen)? Modelleer het gebruik van de tools daarop en niet omgekeerd.

[Sardaukar]

Interessante discussie.

Ik heb helaas geen tijd om helemaal in je vraag te duiken maar ik wil ook meegeven dat in je plaats van submodules ook eens kan kijken naar git subtree.

Daarnaast is er de mogelijkheid om je main en je core als een eigen produkt te beschouwen met een eigen release.cycle. Je levert dan vanuit een repository een release op.

Deze release kun je in je buildscript van je andere subprojecten gebruiken om die release als dependency te installeren (via nuget of via een volledige installer). Dit werkt natuurlijk het beste als je de main en core ook echt als los produkt kan beschouwen. Indien je voor een feature veel wijzigingen moet aanbrengen in zowel je subproducten als in main en core is dit minder handig.

Succes ermee!

[Ramon]

Het bedrijf waar ik werk heeft ook verschillende installaties, stuk of 30, van hetzelfde product. Veel klanten hebben extra plugins, andere naamgeving e.d. Dat regelen wij allemaal in klantspecifieke repo's die het hoofdproduct inlaadt plus eventuele plugins en vertalingen. Dit werkt overigens gewoon met het tijdens deploy installeren van een (of meerdere) python module(s), dus niet met git.

P_Tingen schreef op vrijdag 24 april 2015 @ 18:26:
[...]

Hmm, kweet niet. We hebben 12 fabrieken en voor elke fabriek wil men een ontwikkel- test- en productieversie hebben. Dat zou dan al 12x3 branches zijn? Het management wil naar een handvol releases per jaar toe, dus we zaten meer te denken om daar onze branching op af te stemmen.

In Git zijn branches goedkoop. Je kan heel veel branches hebben zonder dat Git langzaam wordt. 3 branches is geen enkel probleem. Kijk bijvoorbeeld eens hier voor een voorbeeld: http://nvie.com/posts/a-successful-git-branching-model/

Als je een goede git workflow hebt kan je iedere dag een nieuwe versie releasen, een handvol releases per jaar vind ik erg weinig.

Als je alles in één repo zet dan krijg je bij nieuwe of aangepaste configuratie van je software (stel er komt een nieuwe fabriek bij) een nieuwe versie, die je dan om "onduidelijke" reden overal moet gaan installeren. Dat wordt heel snel onoverzichtelijk lijkt me. Je wil gewoon vanuit je fabrieksspecifieke repo kunnen verwijzen naar een bepaalde commit in je hoofdrepo. Je maakt een install script die dat allemaal regelt, heb je geen git support voor nodig. Zo kan je ook waar nodig individuele installaties makkelijk terugrollen, door gewoon naar een oudere commit of tag te verwijzen in je fabrieksspecifieke repo.

Een van onze kleinere projecten dient nu als een speeltuin omdat die dezelfde problematiek kent. Het probleem is alleen dat - in ieder geval ikzelf - niet veel ervaring heb met GIT en dus lastig kan inschatten wat handig is en wat voor constructie voor problemen gaat zorgen.

We spelen in ieder geval even verder.

Ik denk dat je je oplossing niet in git moet zoeken.

[chime]

Door per fabriek een branch / fork te maken hou het je dat stuk wel een pak overzichtelijker.
Het lijkt me trouwens ook wel correct weer te geven hoe de echte situatie er nu uit ziet ... per fabriek een aparte laag.

Nu in git is het hebben van veel branches ook niet echt een probleem - daar is het spul voor gemaakt.
Als je als developer iets uitcheckt dan zit je ook op een eigen branch te werken die daarna terug gemigreerd wordt naar de main.
Dus switchen tussen branches kan vrij snel.

Maar je workflow is belangrijk.

Bvb: als de main code verandert van het ERP systeem => is dat dan gelijk in elke fabriek of gaat dat geleidelijk aan?
Hetzelfde voor jullie "core" component.

Anderzijds je gaat per fabriek niet noodzakelijk ten allen tijde 3 branches hebben openstaan - veel hangt er van af of je er nu nog aan bezig bent of niet.
Als er een release is geweest en je bent klaar dan kan ik me perfect voorstellen dat 1 en dezelfde branch in alle omgevingen staat. Op het moment dat er iets nieuws uitgevoerd moet worden (bugfix ofzo) wordt er een nieuwe branch gemaakt die het hele traject gaat aflopen.
Hell - je kan zelfs per developer eigen branches maken en die op Test laten samenkomen. Dev 1 doet een bugfix, Dev2 een feature.

Anderzijds mis ik eigenlijk nog wel 1 omgeving in je traject
Persoonlijk heb ik meer een voorkeur voor: DEV - TEST - UAT - PROD.
Als de developers lokaal ook de omgeving kunnen draaien, dan kan DEV(lokaal) - DEV(server) - TEST - PROD ook nog wel.

[P_Tingen]

chime schreef op maandag 27 april 2015 @ 09:58:
Anderzijds mis ik eigenlijk nog wel 1 omgeving in je traject
Persoonlijk heb ik meer een voorkeur voor: DEV - TEST - UAT - PROD.
Als de developers lokaal ook de omgeving kunnen draaien, dan kan DEV(lokaal) - DEV(server) - TEST - PROD ook nog wel.

Klopt, een volledige DTAP opzet zit in de planning maar ligt nu buiten mijn scope. De stekkertrekkers bij ons moeten eerst meer schijven naar binnen fietsen want de schijfruimte wordt knijp bij ons.

We zijn ons ervan bewust dat we eerst eens goed moeten kijken naar de werkwijze. Daarvoor allen al dank!

[H!GHGuY]

chime schreef op maandag 27 april 2015 @ 09:58:
Door per fabriek een branch / fork te maken hou het je dat stuk wel een pak overzichtelijker.
Het lijkt me trouwens ook wel correct weer te geven hoe de echte situatie er nu uit ziet ... per fabriek een aparte laag.

Zoals ik hierboven aanhaal: dit wil je echt niet doen.
Stel dat je de helft van de code van 1 fabriek wil gebruiken voor een andere. Dan kan je git zijn belangrijkste tool om zoiets te doen, nl. mergen, niet gebruiken.

Daarnaast moeten je git branches je development workflow weergeven en niet je deployment model.

[roy-t]

Waar ik werk hadden we een soort gelijk probleem. We keken eerst ook naar Git-Submodules maar dat zorgt inderdaad alleen maar voor meer hoofdpijn. Uiteindelijk hebben wij ook alles in een repository gezet*.We werken met aparte branches voor 'locals', niet mappen, want op die manier kun je toch nog een beetje code delen en is het makkelijker om 1 local alvast een nieuwe versie van core te laten gebruiken zonder de rest meteen stuk te maken.

Omdat we C# gebruiken, maken we ook veel gebruik van NuGet voor stukjes die niet snel veranderen (elke Nuget package heeft wel zijn eigen repository).


* In een Hg repository omdat Git problemen gaf met de grote van de repository waar alles in zat. Timeouts bij het pullen en pushen, en andere rare problemen. Uiteindelijk is de keuze op Hg gevallen omdat bedrijven zoals Facebook laten zien dat Hg goed hele grote repositories aan kan: https://code.facebook.com...ng-mercurial-at-facebook/

[ Voor 50% gewijzigd door roy-t op 04-05-2015 13:06 ]