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

TFS? Corri per le colline! Spegni il più velocemente possibile. Fa molte cose diverse ma nessuna è valida come i migliori strumenti disponibili per la razza.

Ma sul serio:

Una volta che hai un sistema di controllo della versione decente (SVN, GIT, ecc.) ti consigliamo di impostare le regole per la gestione delle filiali, ad es. quando creare rami, per cosa, quando unire, chi e molto altro.

Fino a poco tempo fa abbiamo utilizzato un singolo ramo per il nuovo sviluppo ('trunk'). Per un rilascio creeremmo un ramo fuori dal tronco. Il QA finale verrebbe fatto in quella filiale e una volta completato pubblicheremmo (siamo su versioni mensili).

Siamo passati al concetto di "no junk nel bagagliaio" per ridurre il rischio di pianificazione. Questo concetto contiene fondamentalmente una regola in base alla quale è necessario creare rami per il lavoro di sviluppo separato dal trunk. Ad esempio potresti avere un ramo separato per una funzionalità, per un piccolo team di sviluppo o simili. Utilizziamo "epopee" per descrivere una piccola funzione o parte rilasciabile di una funzione e creare un ramo per ogni epopea. Almeno una volta al giorno tutte le modifiche dal tronco vengono unite nel ramo epico. La chiave è un buon supporto per il controllo delle versioni o uno strumento separato (ad esempio unione a tre vie). Il QA per l'epico sarebbe stato fatto sul ramo epico. Una volta passato, il ramo epico verrebbe unito al tronco e verrà eseguito un test di integrazione. Abbiamo ancora filiali per le versioni.

Con i rami epici abbiamo ridotto sostanzialmente il rischio di pianificazione, poiché ora siamo in grado di rilasciare il bagagliaio e includere tutti i file epici che sono stati uniti con successo nel trunk. Le poesie che non sono complete perdono il bus e faranno la prossima uscita (il prossimo mese).

Questo naturalmente 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 che non sono sempre connesse al server di controllo versioni, è consigliabile utilizzare un sistema di controllo versione che supporti un modello distribuito. GIT e pochi altri rientrerebbero in questa categoria. TFS, per quanto ne so, richiede una connessione al server per rendere i file scrivibili (risolti nella versione 2010?).

Spero di essere stato in grado di dimostrare che non esiste "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.

Io sostengo un ramo per caratteristica in quanto consente una grande flessibilità nel decidere quali funzioni spedire & quale differire.

Quanto bene ciò funziona nella tua situazione dipende da quanto bene il VCS gestisce i rami e, ancora più importante, dalla fusione. DVCS come Git & Mercuriale rende questo esercizio relativamente banale. SVN meno così. Sono riuscito a evitare TFS anche se ho letto molto su di esso, per lo più non ho paura. Se sei bloccato con TFS fai una piccola release pilota basata su una funzione per branch & guarda come va bene la fusione per te.

In primo luogo, un disclaimer. È difficile stabilire quale sia il modo migliore per gestire la tua fonte, poiché non siamo a conoscenza di come il tuo team o team lavorino giorno per giorno.

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

L'unione di un nuovo codice riduce regolarmente il dolore derivante dall'unione di grandi 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 unirsi, perché saranno sempre sull'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 della versione. Questo mi ha fatto stare lontano da TFS da così lontano.

Attualmente sto usando SVN e Git, li trovo entrambi buoni per le piccole squadre o per il team di singoli uomini, ma non lo consiglierei personalmente a un grande team.

Ho avuto i miei occhi su PlasticSCM e proverò a farlo nel prossimo futuro.

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

Penso che git renda obsoleti tutti gli altri software di controllo del codice sorgente. La ramificazione e la fusione sono facili, e se ci sono problemi, viene contenuta, ma molti problemi vengono evitati da come incoraggia commit, branching e fusioni molto frequenti. Ogni utente ottiene una copia completa del repository (questo può essere potato, ma io lavoro con una base di codice piuttosto enorme e non è un problema), quindi c'è qualcosa di un backup automatico. Commits / push / pull sono veloci e una delle cose più importanti è che rompe l'accoppiamento tra il nome del file e il tracking. I dati del file, inclusi il nome e il percorso, sono un blob di dati a cui fa riferimento un nodo dell'albero, 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 configurazione hub tradizionale o peer to peer e tali usi possono essere mescolati liberamente nella stessa configurazione. È crittograficamente sicuro contro le inserzioni non documentate. Ed è molto veloce.

Trovo che io lo usi sempre a casa, solo per tenere traccia dei documenti e sincronizzarli tra computer, perché è più semplice eseguire il commit e inviare al file server piuttosto che eseguire il backup sul server o salvare è lì.

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

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

1) Assicurati di non avere una copia scrivibile del file nel tuo locale e di controllare sempre per modificare. (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 eventuali piccoli traguardi significativi.

3) Dai un buon checkout o un commento. Questo ti aiuterà quando ripassi, a volte non devi aprire e confrontare tra le versioni.

how do you manage checkins and prevent feature conflicts and manage dependencies with source control properly?

È, dal mio POV, un compito a due fattori: devi farlo dal punto di vista tecnico (buono & ampli-prova branching | merging | audit etc) e gestione (politica consolidata "che cosa" "quando" " come ") lati. Due o anche tre livelli di codice di separazione in ALM: qualcosa come "stabile" (superato il test delle unità), "instabile" (ogni funzione inclusa è terminata, ma l'app come prodotto ha domande post-integrazione / sì, può succedere /) e "work in progress". In questo modo, il project manager appropriato può ridurre l'interferenza del lavoro dello sviluppatore separato in comune.

TFS (che non ho usato, non uso e non userò) ha alcuni, AFAIK, problemi fondamentali nel suo aspetto di gestione del controllo del codice sorgente. Mi limito a collegare qui alcuni dei testi di James McKay:

• Team Foundation Server è il Lotus Note sugli strumenti di controllo della versione
• Baseless si fonde nel server Team Foundation - perché?

Un articolo molto bello e recente che confronta e contrappone in modo semplice e conciso alcuni diversi modi di lavorare con il controllo del codice sorgente è qui: Controllo origine eseguito a destra .

Non penso che ci sia una una strategia / best practice per l'utilizzo del controllo del codice sorgente. I team maturi che hanno lavorato insieme per molto tempo hanno molto meno "dolore" in questa area, anche se non stanno seguendo esattamente le "migliori pratiche" popolari.

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