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

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

Il fatto che le modifiche risiedano sulle macchine degli sviluppatori per un lungo periodo probabilmente causerà un incubo di integrazione.

Bene, ci sono più modi per affrontare problemi del genere, generalmente coperti da , ognuno con il proprio set di vantaggi e svantaggi.

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

code... will be kept on the developer's local machines until they are done...

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

Ciò che mi rende un problema criminale per me è che per TFS esiste una guida alla ramificazione del server Microsoft Team Foundation eccellente e di facile comprensione - un documento ampio e dettagliato con consigli sulle strategie di ramificazione accuratamente personalizzati e spiegati per tutti i tipi di progetti diversi ( versione HTML qui ).

1. I tuoi sviluppatori hanno un malinteso fondamentale su come utilizzare il controllo della versione.
2. Non entrare in una discussione sul software di controllo versione "giusto". Questo non è un problema.
3. Ogni modifica del codice rende il problema più difficile da risolvere.
4. QUANDO decidi di fare la cosa giusta, non puoi continuare a modificare il codice mentre aggiusti le cose. DEVI interrompere tutto lo sviluppo e ottenere il codice nel controllo della versione.
5. I dev del devono sentire il dolore abbastanza da sedersi almeno e parlarne.
6. Tutto il software di controllo delle versioni supporta i concetti di base:
   • TUTTO il codice va nel repository del controllo di versione.
   • Tutti i file di codice hanno numeri di versione. Questi numeri aumentano automaticamente quando il codice viene ricontrollato.
   • Un TAG contrassegna tutti i file di codice di una (e ad una) versione particolare. Così possiamo TAG per la versione 1 del software, per esempio.
   • una BRANCH è una "svolta" dal trunk principale .
     • Tutte le modifiche apportate a un ramo non influiscono sul trunk.
     • Puoi opzionalmente unire le ramificazioni nel tronco principale ad un certo punto.
     • Quindi possiamo sperimentare senza paura di rovinare "le cose buone".
7. Devi avere il controllo della versione "salto della fede" come lo chiamo io. FIDUCIA che seguire le regole di base non mancherà di tenere le cose a posto. L'inesperienza ci fa pensare diversamente, fidati di me.
8. Ecco un tutorial decente. È generale e abbastanza completo che non è necessario setacciare molte altre fonti
   • Controllo versione, spiegato meglio

modifica

• 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, consiglio vivamente questo
  • Se il tuo team utilizza Git o Mercurial, stai utilizzando un repository locale indipendente. Ecco come funziona il controllo della versione distribuita.
  • Puoi utilizzare diversi software VC dal tuo 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 un repository del team di fatto. È per la gestione del tuo lavoro, per gli sforzi di refactoring, ecc. E per fare da te mentre il team continua a FUBAR il codice base.

modifica fine

Quello che stai descrivendo è un modo terribile di usare il controllo della versione. Doveva esserci un ramo creato per la versione 2.0, o un tag o qualche identificatore. In questo modo, le modifiche a tale rilascio possono essere contenute e ulteriori sviluppi possono continuare a verificarsi.

Questo articolo può darti qualche idea. È scritto con git in mente , ma non c'è ragione per cui non possa funzionare anche con mercurial . Mi rendo conto che non stai utilizzando nessuno di questi, ma è anche un problema che dovresti prendere in considerazione.

Risposta rapida: il team di sviluppo dovrebbe avere un ramo di produzione separato per mantenere separato V2.0 code-base distribuito dal tronco Principale .

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

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

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

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

• Implementazione di Team Foundation Server con un piccolo team di sviluppo
• Benvenuti nella piattaforma di integrazione TFS!
• Sviluppo di 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 è il tracciamento delle differenze nel tempo, stai pianificando di registrare alcune differenze, ma al momento la maggior parte delle tue modifiche non sono registrate.

Come altri hanno già detto, dovresti usare i rami. Una volta eseguita questa impostazione, dovresti controllare tutte le modifiche funzionali (cioè non tutte le sequenze di tasti, ma ogni volta che correggi un bug, aggiungi una funzionalità, cancella una funzione o altrimenti completa una modifica in modo tale che essa continui a costruire 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 successiva.

Una volta che le nostre correzioni sono state fatte, si sono fuse con la produzione e sono state implementate, otteniamo un nuovo ramo per tornare ai 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 per ogni singola riga che ho modificato o aggiunto per il fixing. E basta confrontare e commettere. Allo stesso modo, se facessero 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+F comando e digita //Start Iteration 2, Fix No-1, Branch No-"ABC" cercare in tutta la soluzione aiuta molto a trovare le posizioni esatte, i file in cui il codice è cambiato e prendere il codice nuovo solo quella parte può essere utilizzata per il commit.