Come posso gestire correttamente i commit, prevenire conflitti di funzionalità e gestire le dipendenze con un VCS?

È diventato un fattore fastidioso di lavorare con team di grandi dimensioni: come si gestiscono i check-in e si evitano conflitti di funzionalità e si gestiscono correttamente le dipendenze con il controllo del codice sorgente?

Attualmente sul mio posto di lavoro utilizziamo TFS 2008 e stiamo migrando a TFS 2010 all'inizio di dicembre. In primo luogo, qualsiasi controllo del codice sorgente è migliore di nessuno, ma quale approccio ha trovato utile qualcuno per impedire check-in multipli e rollback in tutta la cronologia del controllo del codice sorgente? Un trunk volatile è il modo migliore per andare o ramificarsi quando si implementa una nuova funzionalità e, una volta che si è felici, rientrare nel trunk?

Mi piacerebbe davvero sentire le esperienze di altre persone e forse alcune best practice per la gestione del controllo del codice sorgente.

TFS? Corri per le colline! Allontanati il ​​più velocemente possibile. Fa molte cose diverse, ma nessuna delle quali è valida come il migliore degli strumenti disponibili.

Ma sul serio:

Una volta che hai un discreto sistema di controllo della versione (SVN, GIT, ecc.) Ti consiglio di impostare regole per la gestione delle filiali, ad esempio quando creare filiali, per cosa, quando unire, chi e molto altro.

Fino a poco tempo fa abbiamo usato un singolo ramo per il nuovo sviluppo ("trunk"). Per una versione creeremmo un ramo fuori dal tronco. Il QA finale verrebbe fatto in quel ramo e una volta completato rilasceremo (siamo su rilasci mensili).

Siamo passati al concetto di "nessuna spazzatura nel bagagliaio" per ridurre il rischio di pianificazione. Questo concetto contiene fondamentalmente una regola in base alla quale creare rami per il lavoro di sviluppo separati dal tronco. Ad esempio, potresti avere un ramo separato per una funzionalità, per un piccolo team di sviluppo o simili. Usiamo 'epiche' per descrivere una piccola funzione o parte rilasciabile di una funzione e creare un ramo per ogni epica. Almeno una volta al giorno tutti i cambiamenti dal tronco vengono uniti nel ramo epico. La chiave è un buon supporto per l'unione tramite controllo della versione o uno strumento separato (ad es. Unione a tre vie). Il QA per l'epopea verrebbe fatto sul ramo epico. Una volta superato, il ramo epico verrebbe unito nel trunk e verrà eseguito un test di integrazione. Abbiamo ancora filiali per le versioni.

Con i rami epici abbiamo sostanzialmente ridotto il rischio del programma in quanto ora siamo in grado di liberarci dal tronco e includere tutti gli epici che sono stati fusi con successo nel tronco. Le epiche che non sono complete mancano del bus e faranno la prossima uscita (il prossimo mese).

Questo ovviamente può funzionare solo nel nostro ambiente. Molto probabilmente avrai fattori diversi dai nostri che influenzeranno le scelte migliori per la gestione delle filiali.

Ad esempio, se si dispone di un team con molte persone che lavorano in remoto e non sono sempre connesse al server di controllo versione, si desidera utilizzare un sistema di controllo versione che supporti un modello distribuito. GIT e alcuni altri rientrerebbero in questa categoria. Per quanto ne so, TFS richiede una connessione al server per rendere i file scrivibili (risolti nella versione 2010?).

Spero di essere riuscito a dimostrare che non esiste "una taglia unica". Inizia con i tuoi processi in particolare la gestione delle filiali, determina i requisiti e infine seleziona lo strumento più adatto alle tue esigenze. Forse è TFS, forse no.

Sostengo un ramo per funzione in quanto consente una grande flessibilità nel decidere quali caratteristiche spedire e quali differire.

Quanto bene funziona nella tua situazione dipende da quanto bene il tuo VCS gestisce le filiali e, soprattutto, l'unione. DVCS come Git & Mercurial rendono questo esercizio relativamente banale. SVN di meno. Sono riuscito a evitare la TFS anche se ne ho letto molto, per lo più sgradevole temo. Se sei bloccato con TFS, esegui una piccola versione pilota basata su una funzione per ramo e vedi quanto va bene la fusione.

Innanzitutto, un disclaimer. È difficile dire quale sia il modo migliore di gestire la tua fonte, dal momento che non siamo a conoscenza di come il tuo team o team lavorano quotidianamente.

In generale, è meglio lavorare sul bagagliaio. Per ogni rilascio principale, diramalo - in modo che le correzioni dei bug per la versione di rilascio si trovino sul ramo che può essere ricondotto nel trunk. Tutti gli sviluppatori lavorano sul trunk e eseguono regolarmente il commit del codice (minimo una volta al giorno).

L'unione di nuovo codice minimizza regolarmente il dolore della fusione in grossi blocchi di codice in una massiccia fase di integrazione. Diffondendo il dolore, lo sentirai meno. Più spesso i membri del tuo team commettono il codice, meno dovranno unire, perché saranno sempre all'ultima fonte.

Non ho mai usato TFS 2008/2010 ma da quello che ho letto in vari forum ci sono molte negatività sull'uso di TFS per il controllo delle versioni. Questo mi ha fatto stare lontano da TFS da ora.

Attualmente sto usando SVN e Git, li trovo entrambi buoni per i team di piccole dimensioni o single man team, ma non consiglierei personalmente SVN per una grande squadra.

Ho messo gli occhi su PlasticSCM e proverò a farlo nel prossimo futuro.

Mi scuso per non aver risposto alla tua domanda specifica, avrei pubblicato un commento se i miei privilegi me lo avessero permesso.

Penso che git renda obsoleti tutti gli altri software di controllo del codice sorgente. Le ramificazioni e le fusioni sono facili e, se ci sono problemi, sono contenute, ma molti problemi vengono evitati da come incoraggia impegni, ramificazioni e fusioni molto frequenti. Ogni utente ottiene una copia completa del repository (questo può essere eliminato, ma io lavoro con una base di codice piuttosto grande e non è un problema), quindi c'è qualcosa di un backup automatico. I commit / push / pull sono rapidi e una delle cose più importanti è che interrompe l'accoppiamento tra nome file e tracciamento. I dati del file, inclusi nome e percorso, sono un BLOB di dati a cui fa riferimento un nodo della struttura, indipendente dai percorsi. Questo non è solo più sicuro, ma alcuni tipi di problemi "non farlo mai" in qualcosa come SVN non sono un problema. Può essere utilizzato come una configurazione hub tradizionale o peer to peer e tali usi possono essere mescolati liberamente nella stessa configurazione. È crittograficamente sicuro contro inserimenti non documentati. Ed è molto veloce.

Trovo che lo uso a casa ora tutto il tempo, solo per tenere traccia dei documenti e sincronizzarli tra i computer, perché è più facile eseguire il commit e il push sul file server piuttosto che eseguirne il backup sul server o salvarlo lì.

Lo svantaggio è un po 'una ripida curva di apprendimento, poiché infrange tutte le regole a cui le persone sono abituate con il controllo del codice sorgente, in modi sottili, ma è una breve curva di apprendimento ripida.

Alcune delle buone pratiche che seguiamo davvero e che ci hanno aiutato molto:

1) Assicurati di non avere una copia scrivibile del file nel tuo locale e di controllare sempre per modificarlo. (Se a volte devi lavorare in locale, prova a unirlo nel controllo del codice sorgente prima di EOD.)

2) Etichetta i tuoi file periodicamente, dopo ogni piccola pietra miliare significativa.

3) Dai buoni commenti alla verifica o al check-in. Ciò sarà di aiuto durante la revisione, a volte non è necessario aprire e confrontare tra le versioni.

come gestite i check-in e prevenite i conflitti di funzionalità e gestite correttamente le dipendenze con il controllo del codice sorgente?

Dal mio punto di vista, è un compito a due fattori: devi farlo dal lato tecnico (buono e facile e ramificazione a prova di proiettile | fusione | controllo ecc.) E dalla gestione (politica ben definita "cosa" "quando" "come"). Due o anche tre livelli di codice di separazione in ALM: qualcosa come "stabile" (test unitario superato), "instabile" (tutte le funzionalità incluse sono finite, ma l'app come prodotto ha domande post-integrazione / sì, può succedere /) e " lavori in corso". In questo modo un Project Manager adeguato può ridurre in comune l'interferenza del lavoro di uno sviluppatore separato.

TFS (che non uso, non uso e non userò) presenta alcuni problemi fondamentali, AFAIK, nel suo aspetto della gestione del controllo del codice sorgente. Ho appena linkato qui ad alcuni dei testi di James McKay:

• Team Foundation Server è Lotus Notes degli strumenti di controllo della versione
• Si fondono senza fondamenti nel server Team Foundation - perché?

Un articolo davvero bello e recente che confronta e combina in modo chiaro e conciso alcuni modi diversi di lavorare con il controllo del codice sorgente è qui: Controllo del codice sorgente fatto a destra .

Non credo che esista una strategia / best practice per l'utilizzo del controllo del codice sorgente. I team maturi che lavorano insieme da molto tempo hanno molto meno "dolore" in quest'area, anche se non seguono esattamente le "migliori pratiche" popolari.

Per quanto riguarda quali strumenti ... Quasi non importa. Ciò che conta davvero è che tutti i membri del tuo team siano nella stessa pagina per quanto riguarda l'utilizzo. Ciò significa che tutti devono capire come viene gestita la linea di codice e cosa devono fare. E comunque, in pratica NON hai di solito una scelta su quale strumento usare. Ottieni il meglio da qualsiasi cosa tu stia usando.