[Conny Westh]

Om man har egenutvecklade produkter så brukar det vara bra att utgå från det. Det brukar inte vara så bra att dela upp utvecklingsversioner på på olika kataloger (då får man lätt olika verioner att underhålla vilket blir dyrt och osäkert i längden, försök att "hålla ihop" koden så mycket som möjligt), man kan däremot tagga varje version så man kan göra checkout på en specifik version vid ett senare tillfälle. Men man vill helst att alla utvecklare ska jobba med den senaste versionen och alltid förbättra produkten.

Ett förslag på struktur:

/products
	/productA
                     /doc
                     /source
                     /bin
                     /config
	/productB
                     /doc
                     /source
                     /bin
                     /config
	/productC
                     /doc
                     /source
                     /bin
                     /config
	/productD
                     /doc
                     /source
                     /bin
                     /config
	[...]
/customers
	/customer1
		/documentation (unikt)
		/configuration (unikt)
		/productA (delad)
		/productB (delad)
	/customer2
		/documentation (unikt)
		/configuration (unikt)
		/productA (delad)
		/productB (delad)
	/customer3
		/documentation (unikt)
		/configuration (unikt)
		/productA (delad)
		/productB (delad)

Däremot är det bra att "dela" så man alltid har samma version av respektive produkt för alla kunderna, men källkod och binärfiler finns bara på ett ställe rent fysiskt.

Att brancha är en riskabel åtgärd om man får olika förgreningar av produkten. Det finns fördelar om man under en kortare tid behöver utveckla en produkt mycket intensivt av två olika team men i längden blir det kolossalt komplext och svårt (dvs tidsödande och därmed dyrt med risk för buggar) att hantera.

Configuration är det som är specifikt för varje kund.

I och med att man "taggar" vrje version så slipper man ha en egen katalogstruktur för varje version.

Det här gäller då om man verkligen vill att varje kund automatiskt ska få senaste uppdateringarna. Om man gör en egen katalogstruktur för varje version så hmnar man snabbt i en hlet ohanterlig skog av olika versioner som utvecklas åt var sitt håll, tro mig där vill man inte hamna.

[dAEk]

Ursprungligen postat av ConnyWesth

Ett förslag på struktur:
[...]

Det ser logiskt ut att dela upp projekt och kunder. Är det tänkt så att produkten agerar som basbibliotek åt kunderna som extendar produkten när de ska lägga till kundspecifika prylar eller hämtar du bara in koden med typ svn-externals?

Nu fick jag massor av idéer(!) men jag skriver nog inget mer innan de lugnat ned sig lite, annars blir det bara osammanhängande.

[Conny Westh]

Ursprungligen postat av dAEk

Det ser logiskt ut att dela upp projekt och kunder. Är det tänkt så att produkten agerar som basbibliotek åt kunderna som extendar produkten när de ska lägga till kundspecifika prylar eller hämtar du bara in koden med typ svn-externals?

Nu fick jag massor av idéer(!) men jag skriver nog inget mer innan de lugnat ned sig lite, annars blir det bara osammanhängande.

Medan man utvecklar en utökning så lägger man den i en kunddspecifik katalog, men när man anser att den blir tillräckligt stabil för att vara generell och återanvändbar hos flera kunder så flyttar man upp den till en egen produkt/extension.

Man kan ju arbeta på lite olika sätt med produkterna. Ett sätt är att ha underliggande "moduler" som man kan lägga till elelr ta bort för specifika kunder. Det är bland annat ett av Ramverken Microsoft tillhandahåller som är uppbyggt så, finns fler som har det som grund.

Bygger man på det sättet så blir det enklare att bygga ut i små steg.... Och man kan enklare plocka bort funktionalitet för vissa kunder (man måste även anpassa configuration-modulen som alltid är specifik för varje kund).