C'è qualcosa di sbagliato nel modo in cui stiamo eseguendo il controllo della versione?

Lavoro con un team di programmatori come analista aziendale. Abbiamo appena rilasciato la versione 2.0 del nostro prodotto e stiamo lavorando alla prossima versione che sarà rilasciata tra 3 mesi (è un prodotto software interno). Sfortunatamente la versione 2.0 presenta alcuni problemi che hanno dovuto risolvere e distribuiremo tali correzioni tra un paio di settimane. Il problema è che anche noi non vogliamo implementare le modifiche su cui si sta ancora lavorando e che non dovrebbero essere rilasciate per altri 3 mesi.

I programmatori hanno deciso che il modo per gestirlo era che sarebbe stato archiviato solo il codice per i difetti e che il codice per i nuovi miglioramenti sarebbe stato mantenuto sui computer locali dello sviluppatore fino a quando non fossero stati eseguiti. Dovrò far testare le build locali dalle loro macchine perché se controllano il codice e dobbiamo eliminare un'altra patch per correggere i difetti, non vogliamo ancora includere questi miglioramenti. C'è anche il problema in cui lo stesso file di codice contiene sia correzioni di errori che miglioramenti, quindi devono copiare il file di codice localmente, quindi apportare una modifica per correggere un bug e verificarne uno, quindi riprendere a lavorare sui miglioramenti prendendo il copia locale che hanno realizzato.

Sembra piuttosto contorto: esiste un modo migliore per gestire questo tipo di scenario? Stiamo utilizzando Team Foundation Server e Visual Studio 2010.

V2.0 avrebbe dovuto avere quello che usavamo chiamare un "ramo di stato stazionario" (abbiamo usato Perforce, non TFS) creato per esso una volta rilasciato. Eventuali correzioni per la v2 sarebbero state apportate a questo ramo e poi propagate nuovamente nel ramo di sviluppo della v3 mentre venivano anche elaborate le funzionalità della v3, ovvero un difetto sulla v2 comporterebbe un difetto anche sulla v3.

Avere modifiche che risiedono per molto tempo sulle macchine degli sviluppatori risulterà probabilmente in un incubo di integrazione.

Bene, ci sono molti modi per affrontare problemi del genere, generalmente coperti dal tag "branching" , ognuno con i propri vantaggi e svantaggi.

Ma approccio scelto dai tuoi sviluppatori ... Accidenti lo citerò verbalmente per assicurarmi di non aver letto male ...

il codice ... verrà mantenuto sui computer locali dello sviluppatore fino a quando non saranno terminati ...

... il modo come sopra è probabilmente l'unico che è totalmente, completamente sbagliato!

Ciò che mi rende criminale per me è che per TFS esiste un eccellente, facile da capire, Microsoft Branch Foundation Server Branch Guidance - documento enorme e dettagliato con consigli sulle strategie di branching accuratamente adattato e spiegato per tutti i tipi di progetti diversi ( versione HTML qui ).

1. I tuoi sviluppatori hanno un equivoco fondamentale su come utilizzare il controllo versione.
2. Non entrare in discussione sul software di controllo versione "giusto". Questo non è il problema.
3. Ogni modifica del codice sta rendendo il problema più difficile da risolvere.
4. QUANDO decidete di fare la cosa giusta, non potete continuare a modificare il codice mentre riparate le cose. DEVI interrompere tutto lo sviluppo e ottenere il codice nel controllo della versione.
5. Gli sviluppatori devono provare abbastanza dolore da almeno sedersi e parlarne.
6. Tutti i software di controllo versione supportano concetti di base:
   • TUTTO il codice va nel repository di controllo versione.
   • Tutti i file di codice hanno numeri di versione. Questi numeri si incrementano automaticamente man mano che il codice viene ricontrollato.
   • Un TAG contrassegna tutti i file di codice di una (e in una) versione particolare. In questo modo possiamo TAG, ad esempio, la versione del software versione 1.
   • una FILIALE è una "svolta" dal tronco principale .
     • Tutte le modifiche apportate a un ramo non influiscono sul trunk.
     • È possibile, facoltativamente, unire nuovamente le modifiche del ramo nel trunk principale in qualche punto.
     • Quindi possiamo sperimentare senza paura di rovinare "le cose buone".
7. Dovete ottenere il controllo della versione "salto di fiducia" come lo chiamo io. FIDUCIA che seguire le regole di base manterrà le cose in ordine. L'inesperienza ci fa pensare diversamente, fidati di me.
8. Ecco un tutorial decente. È abbastanza generale e completo che non è necessario perlustrare molte altre fonti
   • Controllo versione, meglio spiegato

modificare

• Metti il ​​controllo della versione sul tuo computer di lavoro.
  • Puoi farlo subito senza il coordinamento del team
  • Anche con il controllo della versione del team, lo consiglio vivamente
  • Se il tuo team utilizza Git o Mercurial, stai utilizzando un repository locale indipendente. Ecco come funziona il controllo della versione distribuita.
  • È possibile utilizzare software VC diversi dal proprio team. Il nostro team usa Subversion, io uso Mercurial localmente. I metafile del software VC (".svn", ".mg", cartelle nascoste) non sono in conflitto.

Non stai agendo come repository di squadra di fatto. È per la gestione del proprio lavoro, sforzi di refactoring, ecc. E CYAing te stesso mentre il team continua a FUBAR la base di codice.

fine modifica

Quello che stai descrivendo è un modo terribile di usare il controllo della versione. Ci sarebbe dovuto essere un ramo creato per la versione 2.0, o un tag o un identificatore. In questo modo, le modifiche a tale versione possono essere contenute e può continuare a verificarsi un ulteriore sviluppo.

Questo articolo può darti alcune idee. È stato scritto gitpensando, ma non c'è motivo per cui non possa funzionare mercurialanche. Mi rendo conto che non stai usando nessuno di questi, ma questo è anche un problema che dovresti considerare di risolvere.

Risposta rapida: il team di sviluppo dovrebbe avere un ramo di produzione separato per mantenere il codice di base distribuito V2.0 separato dal trunk principale .

Tutte le correzioni di bug devono prima essere eseguite in quel ramo e poi testate e distribuite ad altri rami, al fine di mantenere il codice sincronizzato .

Il tuo progetto dovrebbe anche avere diversi ambienti for health developmentcome Prod, Staging, QA e Dev (a volte UAT). Questi ambienti devono essere impostati prima di andare alla versione di produzione.

Tutto sommato, essere pronti per i bug e le modifiche è il modo per supportare un'applicazione rilasciata.

Poiché TFS è stato menzionato come controllo della versione, ho anche compilato un elenco di articoli che saranno utili per impostare gli ambienti di sviluppo sanitario:

• Implementazione di Team Foundation Server con un piccolo team di sviluppo
• Benvenuti nella piattaforma di integrazione TFS!
• Sviluppo del team con la guida TFS
• Impostazione di un ambiente di sviluppo

No, perché mentre stai usando un VCS, non stai facendo il controllo della versione.

Il concetto centrale per il controllo della versione è tenere traccia delle differenze nel tempo, stai pianificando di registrare alcune differenze, ma al momento la maggior parte delle modifiche non sono registrate.

Come altri hanno già detto, dovresti usare i rami. Una volta che hai quella configurazione, dovresti controllare tutte le modifiche funzionali (cioè non tutte le sequenze di tasti, ma ogni volta che correggi un bug, aggiungi una funzione, elimini una funzione o completi una modifica in modo che funzioni e funzioni).

Sono uno sviluppatore e ci vengono dati diversi codici di filiale e db per le correzioni della versione corrente e una diversa per i miglioramenti e per la versione successiva consecutiva.

Una volta che le nostre correzioni sono state unite alla produzione e sono state implementate, otteniamo un nuovo ramo nuovo per ripristinare i miglioramenti.

Inoltre seguiamo una pratica come se avessi 10 correzioni per la mia versione attuale

Scrivo come

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

Allo stesso modo per altre correzioni, lo faccio solo per ogni riga che cambio o aggiungo per la correzione. E basta confrontare e impegnare. Allo stesso modo, se facessero in parallelo sullo stesso ramo, possono usare

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+Fcomando e tipo //Start Iteration 2, Fix No-1, Branch No-"ABC" per cercare nell'intera soluzione aiuta molto a scoprire posizioni esatte, file in cui il codice viene modificato e prendere un nuovo codice che solo una parte può essere utilizzata per eseguire il commit.