Qual è la migliore tecnica per la gestione di bug e nuove funzionalità Con il controllo della versione in CVS / SVN per un team di 6-9 persone?

Secondo la mia esperienza, l'approccio più produttivo per gestire problemi del genere era quello di tracciare il processo di sviluppo in sintonia con OODA loop. I trucchi chiave sono di isolare quando necessario, avere chiari checkpoint per dev e QA per comunicare ("rilasci interni" se lo si desidera) e, beh, non preoccuparsi di ciò che non è veramente importante.

• oh e meglio sbarazzarsi di CVS. Due sistemi di controllo delle versioni sembrano essere troppo numerosi per il caso come il tuo.

Ora, diamo un'occhiata ad alcuni dei problemi che hai citato ...

When the code goes through testing, the testers find and report bugs, but when the development team fix the bugs and deploy the software, the software sometimes then has more bugs in it because developers working on new features are still committing code to the repository.

L'unico modo produttivo che conosca per stabilizzare la qualità del software da distribuire (release candidate) è isolarlo dal repository principale (leggi: branch dedicato, con il proprio Feature Freeze e Code Freeze mini-milestones).

• Nota che la mia esperienza con il fare il contrario, cioè con il "congelamento" del repository principale mentre il test per il codice release-candidate è stato un disastro totale.

Sometimes the sales team or customers find bugs as well on production systems. Our thought is that we could check out a copy of the code that is stable and make changes there.

Non necessariamente così. Scusa per essere stato vago ma dubito che sia possibile trovare una ricetta tecnicamente precisa qui. Questo genere di cose è meglio comunicare con le parti interessate del prodotto. Una cosa che i team di sviluppo e controllo qualità possono (dovrebbero) portare al tavolo di discussione è una stima comparativa degli sforzi coinvolti nel patching della versione precedente rispetto alla distribuzione di quella più recente.

Piuttosto che "controlla una copia del codice che sia stabile e apporti le modifiche". usa la ramificazione per ogni funzione.

Configurare un server di integrazione continua. Quando controlli il codice nel ramo "dev" principale, esegue l'autobuild sul tuo server di sviluppo.

Quando si ha una nuova attività / funzione / ecc. si dirama il codice dev in un ramo di funzione. Sviluppa, quindi unisci di nuovo in dev.

Mantieni anche un ramo QA / Test, di nuovo, ha l'installazione di autobuilds da distribuire al tuo server QA / Test.

Ciascuna funzione può essere implementata in modo indipendente per lo sviluppo del QA.

L'accesso per il check-in al ramo QA deve essere controllato. In questo modo, se il QA inizia a testare, non è più possibile spostarsi lì fino a quando non sono stati firmati e unire il ramo QA in Production (o un passaggio di gestione intermedio intermedio)

In questo modo gli sviluppatori non superano ciò che il QA sta tentando di testare. E va solo a Prod una volta che il QA ha firmato. Quindi, una volta che si disconnettono e viene distribuito per produrre, rilascia un altro batch di funzionalità che sono pronte per il QA nel ramo QA.

Mescolare, sciacquare, ripetere.

Tutto quello che posso suggerire è un ciclo di feedback più stretto, tramite

• test di integrazione o unità - inizialmente mirati a difetti e comuni punti di integrazione dolore.
• una build continua che si innescherà ad ogni controllo in quell'unità e test di integrazione
• a "aggiusta la cultura del tipo di build" nel team - "sempre cercando di ottenere il verde chiaro "
• nessun silos di codice - il più possibile, tutti gli sviluppatori dovrebbero essere in grado di farlo lavorare su qualsiasi problema o creare un errore.
• distribuire spesso su una versione demo delle applicazioni gli sviluppatori / BA possono usare per scuotere nuove funzionalità prima che colpiscano il team di test.
• un nuovo difetto, oltre ad essere riparato, ottiene anche un test focalizzato su questo problema.

Penso che scoprirai che fare queste cose ti permetterà di ridurre il numero di bug che colpiscono i tester.

Dovresti leggere del materiale su come lavorare con i rami. Manterrei rami separati per le vecchie versioni, la versione attuale e futura, e imporrò tutto lo sviluppo nei rami delle funzionalità; nessuno dei tuoi rami "stabili" dovrebbe mai essere rotto.

Suppongo che gli strumenti siano una parte importante di ciò che manca per voi ragazzi. Branching and merging è una cagna con SVN e CVS. Spingerei per una mossa a Git.