Best practice SVN: lavorare in team

Sto iniziando con SVN. Conosco i comandi di base e comprendo i principi di base. Mi chiedevo se qualcuno avesse suggerimenti o buone pratiche per lavorare con Subversion in un ambiente di squadra.

Posso vedere il vantaggio di aggiungere messaggi ragionevolmente dettagliati durante il commit del codice, ma ci sono altre cose che dovrei tenere a mente?

Grazie per tutte le ottime risposte - hanno aiutato molto.

Incoraggia i commit frequenti. I compagni di squadra che non conoscono il controllo delle versioni potrebbero ritenere di dover tenere il codice fuori dal repository fino a quando "funziona correttamente". Insegna a tutti a impegnarsi presto e spesso per trovare i problemi il prima possibile. Invece di trattenere il codice finché non funziona, proponi ai tuoi compagni di squadra di creare rami per funzionalità che potrebbero rompere il tronco. Questo porta a ...

Stabilire una pratica di ramificazione e etichettatura. Oltre ai rami per le funzionalità, incoraggia i tuoi compagni di squadra a utilizzare i rami per la correzione di bug di grandi dimensioni. Contrassegna le correzioni di bug principali all'inizio e alla fine del lavoro. Mantieni i tag (e possibilmente i rami) per i rilasci di produzione / qa.

Stabilisci una politica per il bagagliaio e rispettala. Un esempio potrebbe essere "il tronco deve essere sempre compilato senza errori". o "trunk deve sempre superare tutti i test unitari". Qualsiasi lavoro che non può ancora soddisfare gli standard di trunk deve essere svolto in una filiale.

Non eseguire il commit delle modifiche alla formattazione con modifiche al codice

Se vuoi ristrutturare lo spazio bianco ( Control+ K+ D) di un file gigante , va bene. Eseguire il commit della modifica della formattazione separatamente dalla modifica logica effettiva. Lo stesso vale se vuoi spostare le funzioni nei file. Eseguire lo spostamento separatamente dall'editing effettivo.

Uno dei concetti chiave a cui mi attengo sempre è eseguire il commit delle modifiche al codice correlate insieme . Il corollario è non eseguire il commit di modifiche al codice non correlate nello stesso commit . Ciò significa non correggere 2 bug in un commit (a meno che non sia la stessa correzione) e non eseguire il commit di metà correzione di bug in ciascuno dei 2 commit. Inoltre, se devo aggiungere qualche nuovo miglioramento o qualcosa a una parte non correlata del sistema di cui ho bisogno per qualche altro lavoro, impegno il miglioramento separatamente (e prima). L'idea è che qualsiasi cambiamento che chiunque potrebbe desiderare di avere da solo (o tornare indietro da solo) dovrebbe essere un commit separato. Ti farà risparmiare un sacco di mal di testa quando arriverà il momento di fare unioni o ripristinare le funzionalità rotte.

È già stato detto molto, e qui ce ne sono altri:

1. Se hai file che non vuoi nel controllo del codice sorgente (es. Configurazione, file compilati, ecc.), Aggiungili all'elenco ignora . In questo modo noti tutti i file che dimentichi di aggiungere aspettandoti sempre un elenco vuoto di file che vengono visualizzati come sconosciuti a SVN.

2. Aggiungi un evento post commit che invierà un'e-mail alla mailing list dello sviluppatore (o uno specifico per questo target) relativo alla modifica impegnata e idealmente la patch per essa.

3. Integralo con il tuo bug tracker in modo che i riferimenti ai commit vengano visualizzati sui bug / richieste di funzionalità con collegamenti alle differenze. Bug tracker come MantisBT supportano questo.

4. Considerare l'integrazione con l'integrazione continua (ad esempio CruiseControl.NET ), NAnt per Build e NUnit / VS per unit test. In questo modo, una volta che un utente esegue il check-in del codice o in un intervallo pianificato, il codice viene compilato, vengono eseguiti gli unit test e lo sviluppatore riceve un feedback del processo. Ciò avviserebbe anche il resto del team se il repository è danneggiato (cioè non viene compilato).

Bene, le basi:

• Crea tag prima di avviare il QA su una versione
• Crea tag prima di modifiche rischiose (ad es. Grandi refactors)
• Crea rami per le versioni rilasciate al fine di congelare il codice.
• Assicurati che le persone sappiano eseguire l'aggiornamento prima di iniziare a lavorare su una parte di codice e aggiornare ancora una volta prima di eseguirne il commit.
• SVN consente più check out dello stesso file da parte di utenti diversi. Assicurati che tutti risolvano qualsiasi conflitto che potrebbe verificarsi.
• Non utilizzare mai lo stesso account SVN per più di un utente. Possono derivarne cose terribili.

Le risposte che le persone stanno dando sono ottime. Molto di questo è riassunto nel documento utente svn per le migliori pratiche per SVN .
Ripetere:

1. Imposta la struttura del tuo repository (dovresti avere la radice del progetto con trunk, rami e tag sotto)
2. Scegli la tua politica di ramificazione (rami privati, rami per pietra miliare / rilascio / bug, ecc.) E rispettala: consiglierei più ramificazioni piuttosto che meno, ma non c'è bisogno di rami privati
3. Scegli la tua policy per la codifica: più tag, meglio è, ma soprattutto decidi le convenzioni di denominazione dei tag
4. Scegli la tua politica di reimpegno su trunk: mantieni il trunk il più "pulito" possibile, dovrebbe essere rilasciabile in qualsiasi momento

Vorrei riassumere le migliori pratiche a cui mi attengo:

1. Non eseguire il commit dei binari . Dovrebbe esserci un repository separato per i binari, come Nexus , Ivy o Artifactory .

2. Dovrebbe esserci una struttura del repository . Personalmente utilizzo la seguente struttura del repository:

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. Usa un elenco specifico di tipi di rami . La mia lista è la seguente: sperimentale , manutenzione , versioni , piattaforme , rilasci .
4. Utilizza tipi di tag specifici : PA(pre-alpha), A(alpha), B(beta), AR(alpha-release), BR(beta-release), RC(release candidate), ST(stabile).
5. Ridurre al minimo la necessità di fusione . Dovrebbero esserci regole quando l'unione è possibile / incoraggiata e quando non lo è.
6. Numerazione delle versioni . Dovrebbe essere stabilito un approccio di numerazione delle versioni a cui attenersi. Di solito è descritto in un documento come Software Configuration Management Plan, è una parte della documentazione di progetto di alto livello. Personalmente utilizzo un approccio di numerazione delle versioni complesso. Secondo questo approccio, le versioni hanno i seguenti schemi: Nxx (rami di manutenzione / supporto), NMx (ramo di rilascio), NxK (build), NMK (rilascio).
7. Impegnati il ​​più frequentemente possibile . Se tende ad essere difficile (ad esempio, quando ci dovrebbero essere troppe modifiche da fare per implementare funzionalità e persino compilare codice), dovrebbero essere usati rami sperimentali.
8. Il tronco dovrebbe contenere l'ultimo sviluppo . Ad esempio, quando è possibile scegliere dove sviluppare una nuova versione principale ( Nxx ) dell'applicazione, in trunk o in branch, la decisione dovrebbe essere sempre presa a favore del trunk . La vecchia versione dovrebbe essere ramificata nel ramo di manutenzione / supporto . Si presume che esista una chiara distinzione tra le versioni principali e le loro specifiche (architettura, compatibilità) emergono il prima possibile .
9. Rigida politica "non interrompere la compilazione" sui rami di rilascio . Nel frattempo, non dovrebbe essere necessariamente rigoroso per il trunk fintanto che potrebbe avere uno sviluppo sperimentale o una base di codice che necessita di problemi di unione per essere risolti.
10. Usa svn: externals . Ti permetterà di modulare il tuo progetto, stabilire procedure trasparenti di gestione dei rilasci, dividere e conquistare diverse funzionalità.
11. Usa il monitoraggio dei problemi . Sarai in grado di indicare il riferimento al problema all'interno del messaggio di commit.
12. Disabilita i messaggi di commit vuoti . Potrebbe essere fatto usando gli hook pre-commit.
13. Definisci quali rami vuoi integrare continuamente . Ad esempio, preferisco utilizzare l'integrazione continua per trunk , rami di manutenzione e rilascio .
14. Stabilire criteri di integrazione continua per diversi tipi di filiali. Come ho sottolineato in precedenza, le regole più rigide "non rompere la build" si applicano ai rami di rilascio , mentre a volte i rami tronco e di manutenzione potrebbero essere interrotti. Inoltre esiste una differenza tra l'elenco delle ispezioni eseguite sul trunk / manutenzione e sui rami di rilascio .

Puoi trovare uno schema delle mie migliori pratiche di sovversione sotto forma di diagramma che illustra i principi fondamentali dell'approccio di gestione della configurazione del software che utilizzo.

Una cosa che ho trovato molto utile è la proprietà svn: external , che significa che puoi fare riferimento a directory da altri repository nel tuo. Offre modi davvero carini per organizzare il codice e i dati. Alcuni esempi sono:

1. Se disponi di repository separati per il codice di moduli / librerie diversi e riferimenti in quelli che stai utilizzando. Ciò significa che puoi avere un meta repository per ogni eseguibile. Se si tratta di un piccolo eseguibile che utilizza solo pochi moduli, non sarà necessario eseguire il checkout dell'intero albero. Un effetto di ciò è che ottieni i numeri di revisione SVN per modulo.
2. L'aggiunta di dati binari di grandi dimensioni come versioni compilate di librerie al repository di codice è generalmente considerata una cattiva abitudine, ma può essere davvero conveniente. Se aggiungi tutte le versioni di tutte le librerie che utilizzi a un repository diverso, puoi ottenere il meglio da due mondi. Fai riferimento nelle versioni delle librerie che usi nel tuo repository di codice. Quando controlli il tuo repository di codice otterrai sia il codice che i binari. Tuttavia, i file binari sono archiviati in un grande repository di cui non è necessario eseguire il backup rigorosamente in quanto il codice sorgente e il repository del codice sorgente rimangono piccoli e contengono solo testo.

Usa l'integrazione con il tuo software di tracciamento dei bug. Se usi Bugzilla , puoi impostarlo in modo che se il tuo commento inizia con "Bug XXXX" il tuo commento SVN viene automaticamente aggiunto come commento al bug specificato, incluso un collegamento alla tua interfaccia web SVN a quella revisione.

Informazioni sugli strumenti e le convenzioni di ramificazione e unione di SVN.

Il modo migliore per lavorare con altri membri del team è suddividere il lavoro in funzionalità / correzioni di sviluppo complete, quindi lavorare su singole modifiche, ciascuna in un ramo. Quindi unisci le modifiche al ramo / trunk della linea principale una volta completato / pronto / approvato per essere unito.

In questo modo le persone possono lavorare verso un obiettivo comune (sullo stesso ramo o su rami separati) senza entrare in collisione con altri cambiamenti.

Il tuo chilometraggio può variare e questo potrebbe essere eccessivo solo per due persone circa.

È molto più semplice se stai usando buoni strumenti che si integrano bene con SVN. Questi rendono facile vedere cosa è stato cambiato e quindi salvare tutte o parte delle modifiche e aggiornare frequentemente la tua copia di lavoro all'ultima versione in SVN.

Consiglio Tortoise SVN (se stai usando Windows) e Visual SVN (se stai usando VS).

Verifica anche se puoi configurarlo in modo da ricevere e-mail o notifiche simili ogni volta che viene eseguito il commit di una modifica (di solito includendo anche il messaggio di commit e un elenco di file modificati). Servizi come CVSDude lo offrono. Trovo utile sapere che è stato effettuato un aggiornamento e quindi avere un'idea di cosa è contenuto in tale aggiornamento prima di aggiornare la mia copia di lavoro.

Oltre alle politiche di ramificazione et al. (dove una taglia sicuramente non va bene per tutti), dovresti avere buoni commit:

• Il commit dovrebbe riguardare un singolo pezzo di lavoro, se possibile; una correzione di bug, una nuova funzionalità: dovrebbe esserci un po 'di "logica" per le modifiche che hai commesso
• Il commit dovrebbe avere un commento descrittivo che ti aiuterà a individuarlo esplorando la cronologia del repository. La maggior parte delle persone suggerisce di scrivere una singola frase all'inizio che descriva l'intero commit e un account più dettagliato di seguito
• Se possibile, dovresti collegare il commit al tuo sistema di tracciamento dei bug, se possibile. Trac, Redmine et al. ti consente di creare collegamenti da bug a commit e viceversa, il che è molto utile.

La regola d'oro per il controllo del codice sorgente: Check In Early, Check In Spesso

Per suggerimenti su come organizzare il tuo repository:

• Come organizzi il tuo repository di controllo della versione?
• SVN Book Capitolo 5. Amministrazione del repository
• Layout del repository

Consulta il tuo team in merito alle modifiche, o almeno guarda il diff con molta attenzione, prima di correggere eventuali conflitti di unione. Chiedete loro di rivedere da soli il codice unito per assicurarsi che le loro aggiunte non siano andate perse nell'unione.

Una cosa che ho visto che riduce i commit interrotti è avere buoni script pre-commit. Ad esempio, è possibile eseguire qualsiasi unit test prima del commit della modifica. Ciò renderà i commit un po 'lenti, ma risparmi tempo evitando di pestare le dita dei piedi di qualcuno e di dover chiedere scusa. Ovviamente questo diventa molto più difficile da gestire quando hai un grande team di sviluppo e commit molto frequenti.

Uno degli esempi di integrazione con il bug-tracker e l'applicazione della politica di commit potrebbe essere lo script hook pre / post-commit svn di Trac , che può rifiutare il commit se il messaggio di commit non fa riferimento a nessun ticket nel bug-tracker e aggiunge commenti a quelli esistenti ticket in base al contenuto del messaggio (ad esempio, il messaggio di commit può contenere qualcosa come "Correzioni # 1, # 2 e # 8", dove # 1, # 2, # 8 sono i numeri dei ticket).

Best practice per utilizzare SVN :

1. Quando sei arrivato per la prima volta in ufficio e hai aperto il tuo progetto Eclipse , il primo passo da fare è aggiornare il tuo progetto.

2. Dopo aver ricevuto l'aggiornamento, inizia a lavorare. Quando hai terminato la codifica, controlla correttamente se la tua applicazione funziona correttamente senza alcuna eccezione. Una volta che sei sicuro che il tuo codice funzioni correttamente, è il momento di eseguire il commit del codice.

Nota: durante il commit del codice, non eseguire il commit direttamente. Effettua una sincronizzazione con il server e controlla cosa è necessario eseguire. Nota: non eseguire il commit dell'intera cartella una volta. Perché potresti aver apportato alcune modifiche al file per le tue esigenze o potresti aver eliminato alcuni file nel tuo sistema locale. Ma le impostazioni sono diverse sul server. Quindi controlla i file individualmente e salva il codice.

3. Non eseguire il commit / aggiornamento diretto dei file di conflitto.

4. Quando eseguire l'override e l'aggiornamento?

   Quando sei praticamente sicuro di non aver bisogno di nessuna delle tue modifiche locali e desideri aggiornare completamente la copia del server. Annota che una volta se esegui l'override e l'aggiornamento, non otterrai nessuna delle modifiche locali.

   Nota: non conservare il progetto senza aggiornarlo per più di un giorno. Inoltre, non conservare il codice senza impegno per molti giorni.

5. Comunicare chi lavora tutti nello stesso componente e discutere i cambiamenti che hanno apportato ogni giorno.

6. Non eseguire il commit delle proprietà e del file di configurazione a meno che non ci sia un motivo. Perché le impostazioni saranno diverse su un server e nel cloud.

7. Non eseguire il commit delle cartelle di destinazione in SVN, solo il codice sorgente e le cartelle delle risorse devono essere mantenute in un repository SVN.

8. Quando hai perso il codice, niente panico! Puoi recuperare la copia precedente dalla cronologia SVN.

9. Non eseguire il checkout del progetto in più posizioni del disco. Esegui il checkout in un unico luogo e lavoraci.

SVN di per sé è un buon inizio e alcuni degli altri poster hanno offerto ottimi suggerimenti sulle migliori pratiche.

L'unica cosa che aggiungerei è che dovresti collegare SVN con CruiseControl o TeamCity per guidare un processo di integrazione continua. Questo invierà email di build e farà sapere a tutti quando qualcuno ha rotto la build.

Ti dirà molto presto chi sta seguendo il tuo processo e chi no. Potrebbe portare a qualche attrito, ma la tua squadra starà meglio nel lungo periodo.

• Commento preciso per ogni commit

• Non rompere la build (linea principale)!

• Eseguire il commit non appena cambia un'unità logica

• Evita di usare Subversion come strumento di backup

• Un po 'di ramificazione / fusione possibile

.

Maggiori dettagli possono essere trovati nelle migliori pratiche SVN .

Fai lavorare DEV su Branches

1. Impegni frequenti nella tua filiale
2. Impegni discreti / modulari nel tuo ramo ( vedi qui )
3. Aggiorna / Unisci spesso dal tronco. Non sederti sul tuo ramo senza riposarti

Tronco della comunità

1. Dovrebbe sempre costruire / funzionare
2. Un problema per commit ( vedi di nuovo qui ) Principalmente in modo che tu o gli altri possiate tornare indietro uno alla volta
3. Non confondere modifiche di refactoring / spazi bianchi con modifiche logiche. I tuoi compagni di squadra avranno difficoltà a estrarre ciò che hai effettivamente fatto da un impegno

Ricorda che più incrementale, modulare, discreto e succinto fai i tuoi commit, più facile sarà per te (o probabilmente per altri):

• Ritirare le modifiche in modo incrementale
• Realizza visivamente ciò che hai effettivamente fatto senza setacciare tonnellate di spazi bianchi e modifiche ai nomi delle variabili.
• I messaggi di commit significano di più quando il rapporto tra il lavoro svolto e la lunghezza del messaggio è inferiore.

Usa questo per il modello dei commenti:

[attività / storia xxx] [minore / maggiore] [commento] [commento successivo] [URL del bug]