[.NET] Modulair builden, ervaringen / tips?

[Wijnbo]

Stel de volgende situatie:

Software pakket, voor alle klanten gelijk, maar sommige delen zijn klant - specifiek.
Nu raken we het overzicht een beetje kwijt, en naar mijn idee zou het volgende ideaal zijn :

- Haal de laatste versie op uit version control systeem van het "main" deel.

code:

VersionControl://App/a.cs
VersionControl://App/b.cs

- Haal voor de klant waarvoor je aan het builden bent de custom code op

code:

VersionControl://KlantX/App/b.cs (met verwijzing naar c.cs, wat de normale b.cs niet heeft)
VersionControl://KlantX/App/c.cs

- Builden maar!

Tevens zou je hierdoor als je modulaire software wilt makkelijker gedwongen worden om delen gescheiden te houden.

Dit zal allemaal best kunnen, maar wie doet dit al? En welke tools gebruik je hiervoor?

[Bigs]

Hoeveel builds moet je maken als je dit zo gaat doen? Het lijkt mij niet echt praktisch. Is het niet mogelijk om de klantspecifieke code in losse modules te plaatsen en die runtime te laden aan de hand van informatie in de licentiesleutel?

[Wijnbo]

Bigs schreef op woensdag 07 september 2011 @ 08:50:
Hoeveel builds moet je maken als je dit zo gaat doen? Het lijkt mij niet echt praktisch. Is het niet mogelijk om de klantspecifieke code in losse modules te plaatsen en die runtime te laden aan de hand van informatie in de licentiesleutel?

Builds maken we gewoon per klant, en dat zijn er geen honderden, maar eerder 20 ofzo.

Losse modules is ook een idee, maar volgens mij krijg je dan weer een solution met een half ziljoen projecten, namelijk onderdeel a voor klant y, onderdeel a voor klant z, enz?

Of werk jij wel zo ?

[jbdeiman]

@Wijnbo
Waarom heb je dan een heleboel projecten?
Uiteindelijk is het, voor zover ik een invulling kan/ mag maken van Bigs zijn reactie, de bedoeling dat je 1 compleet pakket hebt, opgebouwd met modules. Welke klanten welke module hebben leg je vast in een (soort van) licentie.
Aan de hand van de licentie worden in de code alleen de modules ingeladen/ geactiveerd die je ook hebt afgenomen. Misschien dat zelfs bij het update/ installatieproces hier al rekening mee gehouden kan worden, zodat bepaalde modules niet eens worden geïnstalleerd.

[Grijze Vos]

Ik ben zelf hier op het werk een half jaar geleden begonnen met het bouwen van Nuget packages. Dat werkt echt ideaal voor dit soort dingen.

[Woy]

Ik zou zo veel mogelijk proberen om generieke gedeeltes op te delen in modules die je inderdaad eventueel als Nuget packages aan kunt bieden. Verder zou ik niet op de manier werken die jij voorstelt. Als je echt klant-specifieke aanpassingen moet doen, die je niet door een (build)configuratie af kan vangen, zou ik een branch maken. Dan is het later ook makkelijker om eventueel gedeelde features/bugfixes naar elkaar toe te mergen.

[Wijnbo]

Woy schreef op woensdag 07 september 2011 @ 09:35:
Ik zou zo veel mogelijk proberen om generieke gedeeltes op te delen in modules die je inderdaad eventueel als Nuget packages aan kunt bieden. Verder zou ik niet op de manier werken die jij voorstelt. Als je echt klant-specifieke aanpassingen moet doen, die je niet door een (build)configuratie af kan vangen, zou ik een branch maken. Dan is het later ook makkelijker om eventueel gedeelde features/bugfixes naar elkaar toe te mergen.

Euh, dat is juist wat ik wil, een soort build configuratie waarin je een klant instelt en klaar.

[GateKeaper]

Woy schreef op woensdag 07 september 2011 @ 09:35:
..., zou ik een branch maken....

Heb zelf ook wel eens zitten denken hoe ik een dergelijk probleem zou oplossen. Maar begrijp ik nu goed dat als je twintig klanten zou hebben, dat je dan 20 branches maakt in je versiebeheer pakket? (git / svn / whatever).

[Wijnbo]

GateKeaper schreef op woensdag 07 september 2011 @ 10:21:
[...]


Heb zelf ook wel eens zitten denken hoe ik een dergelijk probleem zou oplossen. Maar begrijp ik nu goed dat als je twintig klanten zou hebben, dat je dan 20 branches maakt in je versiebeheer pakket? (git / svn / whatever).

Dat begreep ik er ook van, en dat lijk me nou niet echt ideaal... Ik ga eens wat proberen met .NET ANT.

[Woy]

GateKeaper schreef op woensdag 07 september 2011 @ 10:21:
[...]


Heb zelf ook wel eens zitten denken hoe ik een dergelijk probleem zou oplossen. Maar begrijp ik nu goed dat als je twintig klanten zou hebben, dat je dan 20 branches maakt in je versiebeheer pakket? (git / svn / whatever).

Afhankelijk van wat je precies zou willen aanpassen. Ik zou in eerste instantie gewoon kijken of het binnen 1 branch kan en dan d.m.v. configuratie.

Wijnbo schreef op woensdag 07 september 2011 @ 10:00:
[...]
Euh, dat is juist wat ik wil, een soort build configuratie waarin je een klant instelt en klaar.

Maar waarom wil je dan meerdere versie van dezelfde source files hebben? Dat lijkt me totaal niet handig, maar zou ik eerder oplossen door bijvoorbeeld conditionele statements, of nog makkelijker door gewoon een andere runtime configuratie.

Maar kun je eens wat beter uitleggen wat de verschillen tussen verschillende klanten zijn?

[ Voor 4% gewijzigd door Woy op 07-09-2011 10:31 ]

[Wijnbo]

Woy schreef op woensdag 07 september 2011 @ 10:28:
[...]

Afhankelijk van wat je precies zou willen aanpassen. Ik zou in eerste instantie gewoon kijken of het binnen 1 branch kan en dan d.m.v. configuratie.
[...]

Maar waarom wil je dan meerdere versie van dezelfde source files hebben? Dat lijkt me totaal niet handig, maar zou ik eerder oplossen door bijvoorbeeld conditionele statements, of nog makkelijker door gewoon een andere runtime configuratie.

Maar kun je eens wat beter uitleggen wat de verschillen tussen verschillende klanten zijn?

Mwah, ik vind het vrij lelijk om klant-specifieke code in je "hoofdapplicatie" te proppen.

We doen onze SQL updates ongeveer op dezelfde manier : Eerst worden zo'n 1000 stored procedures in de database gepropt, daarna gaan er de klantspecifieke overheen. Dat werkt heerlijk, alleen met de sourcecode van de applicatie zou zoiets ook erg tof zijn. Gewoon 1000 classes 't zelfde, maar sommige classes zijn net ff anders (bijv. koppeling met andere systemen ofzo).

[GateKeaper]

Wat ik op dit moment doe is verschillende Visual Studio Solutions aanmaken en daar gewoon projecten linken.

Zo heb ik één App.Core project waarin de kern staat die iedereen deelt. Een App.Gui waarin de grafische schil staat (ook voor iedereen gelijk), en projecten die de modules hebben zijn. App.Core.Modules.

Door middel van MEF worden de modules / addon's / plugins die in de module map van de klant staan ingeladen, en met je build worden ze automatisch in de module map gezet.

Voor een klant maak ik dus enkel een Solution aan die verschillende Visual Studio Projects linkt. Fix je dan een bug voor klant A, dan is deze ook doorgevoerd naar klant B indien die één van de modules deelt. Wel moet je dan ook zijn Solution even rebuilden, maar dat kan d.m.v. een batch file.

Directory structuur:

code:

   .\App.Gui                 // grafische schil
   .\App.Core                // applicatie kern, laadt o.a. de diverse modules    
   .\App.Core\Modules        // hier staan de modules van alle klanten
   .\App.Core\Moduless\App.Core.Module.A     // module A
   .\App.Tests               // unit tests

   .\KlantConfig
   .\KlantConfig\Bedrijf_A   // Hierin staat dus enkel een solution file, 
                               die App.Gui, App.Core en de diverse modules linkt.

[ Voor 3% gewijzigd door GateKeaper op 07-09-2011 11:12 ]

[jbdeiman]

Wijnbo schreef op woensdag 07 september 2011 @ 10:48:
[...]


Mwah, ik vind het vrij lelijk om klant-specifieke code in je "hoofdapplicatie" te proppen.

We doen onze SQL updates ongeveer op dezelfde manier : Eerst worden zo'n 1000 stored procedures in de database gepropt, daarna gaan er de klantspecifieke overheen. Dat werkt heerlijk, alleen met de sourcecode van de applicatie zou zoiets ook erg tof zijn. Gewoon 1000 classes 't zelfde, maar sommige classes zijn net ff anders (bijv. koppeling met andere systemen ofzo).

In hoeverre stop je iets klant specifieks in je applicatie?
Een losse koppeling kan je zien als losse module, deze installeer je pas mee op het moment dat de licentie aangeeft dat een klant deze koppeling heeft. Een koppeling naar een bepaald pakket, of met een bepaalde bestandsopbouw is elke keer hetzelfde. => De settings zijn misschien anders, omdat het om een andere klant gaat, maar settings is klant afhankelijk.

Wat je nu dus feitelijk aangeeft met je 1000 dezelfde classes, maar soms net anders -> Het lijkt me beter/ handiger (en ook beter onderhoudbaar!) als je in de "soms net anders" gevallen dit via de settings mee kan geven, welke methode voor het opbouwen van een bestand wordt gebruikt.
Tenslotte (hier ga ik voor het gemak dan maar vanuit) is de basis van je systeem bij alle klanten gelijk?

Wat je bij welke klant installeert / activeert is afhankelijk van de afgenomen licentie van deze klant.

1000 dezelfde classes waarvan sommigen net anders, klinkt bij mij toch echt als een "niet optimale oplossing".

Waarom steeds een class kopiëren en lichtelijk aanpassen voor 1 klant en voor die klant een compleet andere build maken?

[GateKeaper]

jbdeiman schreef op woensdag 07 september 2011 @ 11:27:
[...]
1000 dezelfde classes waarvan sommigen net anders, klinkt bij mij toch echt als een "niet optimale oplossing".

Zolang de interface gelijk blijft, hoeft dat niet uit te maken.

[Woy]

GateKeaper schreef op woensdag 07 september 2011 @ 11:09:
Voor een klant maak ik dus enkel een Solution aan die verschillende Visual Studio Projects linkt. Fix je dan een bug voor klant A, dan is deze ook doorgevoerd naar klant B indien die één van de modules deelt. Wel moet je dan ook zijn Solution even rebuilden, maar dat kan d.m.v. een batch file.

Je zou als alternatief ook nog gewoon verschillende build-targets kunnen maken binnen 1 solution. Op die manier is het wat makkelijker met refactoren, aangezien dat alleen maar binnen 1 solution werkt.

@Wijnbo: Ik snap nog niet helemaal waarom je voor verschillende klanten verschillende versies van dezelfde source files hebt. Waarom heb je daar niet gewoon d.m.v. inheritance, of andere parameters/configuratie onderscheid gemaakt. Als je bijvoorbeeld SomeBusinessClass als base en default class hebt kun je natuurlijk makkelijk een SomeClientSpecificBusinessClass maken ( die erft van SomeBusiness class, of in ieder geval dezelfde interface implementeerd ), die je alleen bij de build configuratie voor die klant meeneemt. D.M.V van iets als inderdaad MEF kun je dan gewoon je klant specifieke applicatie aan elkaar hangen.

[jbdeiman]

GateKeaper schreef op woensdag 07 september 2011 @ 11:30:
[...]


Zolang de interface gelijk blijft, hoeft dat niet uit te maken.

Ik zeg ook niet dat dit uitmaakt, het kan volgens mij handiger. Niet optimaal suggereert niet dat het per definitie fout is, maar juist dat er handiger oplossingen zijn.
Zie ook de voorgaande post van Woy, het is vaak handiger met configuratie en/ of parameters net datgene te doen wat er moet gebeuren. Je houdt de applicatie meer gelijk over verschillende klanten, wat het beheren/ onderhouden veel eenvoudiger maakt.

[GateKeaper]

Ik denk dat om tot een goeie oplossing te komen, de TS eerst meer info moet geven over wat er precies tussen de klanten verschilt.

Mijn idee is meer het verschil tussen bijvoorbeeld configuratie instellingen. Zo zal de ene klant alles in een database willen opslaan, en de ander in xml bestanden.

Dit zijn dingen die je ideaal met MEF en interfaces kunt afvangen. Immers blijft de aanroep altijd hetzelfde, en hoeft de applicatie dus niet te weten welke class hij gebruikt. Als er maar één aanwezig is.

[Wijnbo]

Het gaat hier om een webapplicatie, waarvan de frontent per klant nog al eens verschilt op sommige onderdelen. Maar bedankt voor de tips, we moeten hier sowieso goed gaan nadenken wat we precies willen en hoe we het willen.