Controllo versione agile?

Question

Sto cercando di elaborare un buon metodo per gestire le modifiche al codice su un progetto di grandi dimensioni con più team. Al momento utilizziamo la sovversione, ma voglio una maggiore flessibilità nella creazione di una nuova versione di quanto sembri essere in grado di ottenere con la sovversione.

Ecco grosso modo che voglio:

• per ogni sviluppatore per creare patch facilmente identificabili per il progetto. Ogni patch offre una storia utente completa (una funzione o una correzione rilasciabile). Potrebbe comprendere molte modifiche a molti file.
• sviluppatori sono in grado di applicare facilmente e rimuovere propria e altre patch per facilitare il test
gestore
• rilascio seleziona le patch da utilizzare nella prossima versione in un nuovo ramo
• ramo è testato, correzioni fuse, e alla fine si fondono in live
• i team possono quindi riportare queste modifiche nelle loro sandbox.

sto guardando stacked git come un modo per raggiungere tale obiettivo, ma quali altri strumenti o tecniche in grado di fornire questo tipo di flusso di lavoro?

Answer 1

Sto provando a elaborare un buon metodo per gestire le modifiche al codice su un progetto di grandi dimensioni con più team.

Consiglio vivamente di leggere l'articolo di Henrik Kniberg Version Control for Multiple Agile Teams su InfoQ.

In breve:

• Il tronco contiene FATTO storie fatto, ha una politica rilasciabile (può essere rilasciato in qualsiasi momento).
• Lo sviluppo è fatto nei rami di lavoro (uno per squadra), hanno una politica più morbida (unità testata).
• quando una storia viene FATTO, viene trasferita dal ramo di lavoro al bagagliaio.
• Unisci dal tronco al lavoro i rami vengono eseguiti ogni giorno.

Ecco un esempio di un intero sprint:

Questa è una versione estremamente semplificato di carta di Henrik, ma questo è lo spirito. È totalmente conforme al nostro processo (Scrum) e funziona molto bene per noi.

PS: A proposito, non capisco perché gli sviluppatori lavorino durante un'iterazione su qualcosa che i responsabili del rilascio non avrebbero scelto per il rilascio.

Answer 2

Sembra a me come avete bisogno di un impianto di integrazione continua come Cruise Control, Hudson, Crociera, squadra della città, ecc

Answer 3

Se le storie sono veramente isolata e molto additivo (molto piccole modifiche alle linee di codice esistenti) , l'approccio potrebbe funzionare. Tuttavia, poiché il lavoro diventa sempre più intrecciato, le fusioni diventeranno sempre più difficili.

Gli ambienti CI, come suggerito da duffymo, potranno essere d'aiuto, ma quegli strumenti dalla mia esperienza non hanno molte (o nessuna) funzionalità per creare molte versioni del progetto né essere intelligenti nel mescolare/fondere i rami.

Potrebbe essere meglio prendere più di un approccio di gerarchia. Ogni gruppo dovrebbe avere il proprio CI e quindi promuoverlo in un sistema di sistema/CI della versione master quando è appropriato (fine dello sprint di ciascun gruppo?). Ciò minimizzerebbe le interazioni dolorose per il gruppo, ma permetterà al progetto nel suo complesso di andare avanti in modo continuo. Se hai molti gruppi, aggiungi ulteriori livelli di integrazione.

Nota: in questo approccio, i test di unità possono rimanere a livello di gruppo, ma è necessario trovare i modi per scrivere integrazioni e test di sistema che possano funzionare attraverso le build di alto livello.

Sul lato degli strumenti, qualsiasi set di strumenti CI deve funzionare. Per il controllo della versione, Git e Mercurial supportano questo tipo di approccio (altri potrebbero anche).

Non esattamente quello che stai chiedendo, ma non penso che ci siano molti strumenti che stanno affrontando il tipo di approccio che si desidera adottare. Inoltre, penso che un numero ragionevole di storie causi un livello di refactoring dell'esistente che renderà le modifiche di mixaggio e matching, difficile.

Answer 4

Questo è un pio desiderio a meno che, come già detto, ciascuna caratteristica non si sovrapponga affatto. Questa è un'eccezione e non la regola.

Un modo migliore per farlo è essere effettivamente coinvolti con il team (s) e avere un'idea di quando alcune funzionalità potrebbero essere quasi complete. Fai in modo che questi gruppi di filiali uniscano i loro rami mentre si sviluppano. Unirli nel ramo dello sviluppo e poi nel master al momento del rilascio sarà molto facile.

ci sono alcuni punti da aggiungere:

Rebase quando possibile, soprattutto se una caratteristica non è stato lavorato per un po '. La ridefinizione solidificherà le risoluzioni dei conflitti in una storia lineare. Successive fusioni o rebases non dovranno rivisitare queste decisioni - a quel punto il ricordo potrebbe non essere accurato.

Utilizzare l'opzione --no-ff (no avanti veloce) quando si unisce un ramo in un altro. Questo assicura che se il secondo ramo non ha commit con cui si fonde, viene aggiunto un commit vuoto che annota i due rami che si uniscono. Se ciò non avviene, puoi perdere un punto di diramazione. Questa può essere un'informazione importante.