Come pianificate i rilasci con le nuove funzionalità in un modello di diramazione di sviluppo / rilascio?

Question

Come pianificate i rilasci con le nuove funzionalità in un modello di diramazione di sviluppo / rilascio?

#1 da (1 voti)

0

Stiamo provando a implementare un modello di filiale in Mercurial.

Abbiamo letto il "Successful GIT branching model" e ne ho proposto un altro, basato su numeri di versione ramificati.

Poi ho finito con l'accettare il modello con 2 rami, sviluppo e rilasci di lunga durata.

Una cosa che mi piace è la possibilità di fare "build notturne", ma sono preoccupato su come pianificare le principali funzionalità per le versioni.

In che modo questo ramo di "sviluppo" dovrebbe funzionare? Dovresti ottenere le correzioni qui il più velocemente possibile, ma unire le funzionalità solo quando voglio? Come si fa?

Voglio pianificare in questo modo:

Versione 1.3: CKEditor + commenti di voto

Versione 1.4: Elimina e ripristina commenti

E voglio che questo sia nella roadmap di Redmine, il che significa che appartenere a un numero di versione prima che la funzione sia completamente programmata. Principalmente perché voglio mostrarmi (clienti in futuro) che esiste davvero un piano.

branching mercurial release-management release

posta JorgeeFG 07.10.2014 - 15:14

fonte

1 risposta

Leggi altre domande sui tag branching mercurial release-management release

Misurazione di nuove funzionalità in un progetto software e confronto e miglioramento incrementale delle capacità Relazioni di gruppo: dettagliate o dirette?

score 1 · Answer 1

Le funzionalità dovrebbero essere unite nel ramo di sviluppo ogni volta che sono pronte. Ciò dovrebbe avvenire il prima possibile al fine di mantenere tutti i rami abbastanza coerenti, il che riduce i conflitti di fusione. Una volta uniti, i rami delle funzionalità possono essere eliminati. Le grandi funzionalità possono essere suddivise in una serie di funzionalità più piccole. È possibile mantenere sincronizzati i rami di funzionalità a lungo termine unendo periodicamente il ramo di sviluppo ai rami di funzionalità.

È possibile rilasciare una versione ogni volta che è stata aggiunta una nuova funzione visibile all'utente o quando tutte le funzionalità pianificate per la prossima versione sono state unite nel ramo di sviluppo, a seconda del modello di rilascio. Questo si presta molto bene agli approcci agili in cui si decide sulla prossima manciata di funzionalità per la prossima release a breve termine. Una volta spedito, rivaluti le priorità e determina il prossimo set di funzionalità.

Se si dispone di una roadmap che si estenderà ulteriormente nel futuro rispetto alla prossima release, ciò non avrà alcun impatto su un modello di branching simile a Git-Flow: si completano le funzionalità per il primo traguardo, quindi lo si rilascia. Completa le funzionalità per il secondo traguardo, quindi rilascialo. Se si completano le funzionalità pianificate per la seconda pietra miliare prima della spedizione del primo milestone, queste funzionalità saranno presenti nella prima versione. Per esempio. i produttori di browser lo fanno sempre con funzionalità sperimentali che non sono attivate di default.