.net - Afbryder kontinuerlig integration behovet for store Visual Studio-løsninger?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har en løsning, som jeg arbejder på med en anden person, og løsningen har omkring 50-60 projekter, som efter min mening er for mange, da det sænker byggetiden under udvikling og generelt betyder mere arbejde skal udføres af IDE end nødvendigt under udvikling.


Den eneste grund til, at denne løsning ikke er brudt i mindre løsninger, er, at enhver form for refactoring eller andre ændringer i kode kan potentielt forårsage brud i andre løsninger, og disse hentes ikke, før koden er skubbet til depotet og derefter opdaget af den anden udvikler, når han forsøger at udføre sit arbejde.


Da jeg ikke har stor erfaring med kontinuerlig integration, undrer jeg mig over, om (bortset fra de andre fantastiske fordele, der følger med bygningsautomatisering) det er den standard måde, som andre udviklere undgår behovet for løsninger med en masse projekter? Kan nogen anbefale en god primer på kontinuerlig integration og bygningsautomatisering til .Net/Windows-udviklere?

Bedste reference


Ja, en løsning med 50-60 projekter er sandsynligvis for meget. Formentlig er alle disse projekter ikke relateret til det specifikke produkt, som løsningen bygger, og at mange af dem kunne betragtes som rammeelementer?


Jeg vil anbefale at flytte eventuelle rammer (produkt agnostiske) projekter i deres egen rammeopløsning, og tilføj derefter kun referencer til de sammensatte samlinger i produktløsningerne, i stedet for selve rammeprojekterne.


Hvis du bruger TeamCity 7 (for nylig udgivet) til din kontinuerlige integration, er et af de funktioner, det giver, NuGet-emballage. Dette betyder at du kan pakke din virksomheds ramme til en NuGet-pakke for at gøre implementering til hver produktløsning meget ligetil. [1]


Nogle gode ressourcer på kontinuerlig integration/levering er:



  • [2] Martin Fowler om kontinuerlig integration

  • [3] Kontinuerlig integration i .NET

  • [4] Kontinuerlig levering: Pålidelige softwareudgivelser via Build, Test og Deployment Automation