SVN best practice?
 

Vårt scenario:
1. Vi har en webbapplikation byggd enligt MVC mönstret som används av tre olika kunder. Varje kund har sin egen server, visuell design och data i DBn. I kort är vissa filer unika för varje kund (DB-settings, css, bilder och textfiler) men den stora delen är universal.

2. Vi gör uppdateringar/buggfixar och vill rulla ut dessa en gång i veckan till alla kunder.

3. Utvecklarna checkar in sin kod dagligen till 'trunk' i vår SVN repository. Före en ny version ska rullas ut till kunderna så blir det att manuellt kopiera över alla filer förutom de som är kundspecifika till en 'tags'-version för varje kund individuellt(se nedan).
4. Där efter gör vi en export av varje kunds version till en testserver som är snarlik kundens server innan det exporteras till kundens produktionsserver.


Vårt workflow varje vecka ser därför ut något liknande nedan, där de tre sista stegen måste göras för varje kund.
Local > SVN(trunk) > SVN(tag) > testServer > produktionServer

Finns det något vi kan förenkla eller borde tänka på? Hur gör ni generellt när ni jobbar med webbapplikationer och versionshantering? Även enklare projekt är jag nyfiken på hur ni hanterar. Alla tankar är välkomna...

Ni kan börja med att kolla på de där nya från Amerika, Git.

Jag saknar Bransch, jobbar ni händelsevis i trunken?

Branch ska det väl vara :)

Git och SVN uppfyller olika behov, säkerhetsaspekten och användarkontrollen hos en central SVN-repository vinner hos oss. Medan i de open source jag deltar i så är git utan tvekan trevligast.

Vi jobbar i trunken, branch används sällan, finns det någon vinst för oss att börja jobba mer där?

Det normala är väl att man arbetar mest i trunk även om undantag säkerligen finns. Har man inga väldefinierade versioner så är tags inte särskilt användbart (då funkar det bra att köra enbart trunk och branches) men i ert fall fyller de ju sin funktion.

Annars håller jag med om att SVN är bättre lämpat än Git i en sådan verksamhet.

Branches skulle ju vara bra om ni jobbar med olika versioner parallellt, vid t.ex. vidareutveckling. Vad händer om ni sitter och jobbar mot trunken och ni märker en säkerhetslucka i t.ex. 1.1? Som det ser ut nu får den sitta i baksätet tills dess att trunken är klar eller sparar ni undan alla ändringar, revertar tillbaks och fixar säkerhetsluckan, comittar och återställer till sist ändringarna? Det är inte helt ovanligt.

Vet inte om det är en bra ide men jag har funderat på nåt sånt här:

• rc = release candidate. Det som läggs ut på testservern.
• final = det som faktiskt lanseras live.

Om det är en dålig idé vill jag gärna höra det tillsammans med motivering.

Det här med versionshantering är lite knöligt att få till rätt känns det som. När man väl är där - när man har nått hela vägen fram och fått fram en bra struktur - då är det nog så självklart och man undrar vad tusan man höll på med tidigare. :)

Javisst, jag får skylla på tillfällig sinnesförvirring. :)

Låter lite som du och jag har samma tankar även om vi valt att köra löpande utveckling i trunken. Skulle ett säkerhetshål visa sig i t.ex. v.1.1 så tar vi den versionen från tagen och kör igång en branch för att åtgärda problemet. När hålet är åtgärdat så gör vi en ny tag v.1.1.2 som körs ut tills dess att v.1.2 är färdig.

Bollar gärna vidare även med andra SVN-scenarion i tråden, är väldigt lärorikt.

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:

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.

Hänger inte riktigt med i ditt tänk Conny, var det riktat till mig?

Nej, inte riktat till någon specifik, jag redovisade bara hur jag brukar lägga upp strukturen när det gäller projekt som är "produktifierade".

Helt skräddarsydda projekt kan ha en annan struktur. Det är väl mer att enligt min erfarenhet så är det inte bra att lägga upp egen katalogstruktur för varje version om man har en kontinuerlig utveckling av "produkterna".

Jag har jobbat med detta under många år och har provat detta med versionsspecifika katalogstrukturer och det blir otroligt snabbbt helt ohanterligt spretig struktur och man tappar bort sig vilken version av koden som är "rätt".

Mitt tips är att undvika "branchning" om det är möjligt. Jag är medveten om att det finns tillfällen när man måste göra en egen branch, men man måste hålla koll på den så den inte t´drar iväg och man måste även vara noggrann när man sen "mergar" tillbaks i huvudtråden. Gränssnitt kan ändras löpande så man måste vara försiktig så man inte skapar mer jobb än nödvändigt. Själv försöker jag undvika Branch/Merge till varje pris.

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.

Mjo, det ligger lite i det du skriver. Att skapa brancher är lätt men att merga dem kan bli ganska snårigt om man säger så. Vi hade en liten incident (;)) på jobbet när jag var ny, sedan dess har jag varit försiktig med att brancha men jag ser det lite som en tröskel man behöver ta sig över. De har ju sina fördelar.

Att skapa en branch för varje puck i bugg-/ärendehanteringssystemet kanske är overkill men för en klump av dem eller nyutveckling (som omfattar ny design eller layout) är det nog lämpligt tycker jag.

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).