Mantenere rilasci / rami in un ritmo "agile"? [chiuso]

Question

Abbiamo un prodotto software che si evolve al ritmo delle esigenze dei clienti e di una tabella di marcia più generale.

Dato che ci troviamo in un ambiente di progetto SCRUM, accade molto regolarmente che una nuova funzionalità si faccia strada verso il prodotto, e quindi ci troviamo di fronte alla scelta di:

• implementare questa funzione in un ramo già rilasciato (non proprio il punto di avere un ramo, quindi)
• creare una nuova filiale - ma poi abbiamo una filiale ogni tre settimane e non è più possibile effettuare la manutenzione

Non rilasciare la nuova funzionalità non è un'opzione, i clienti non vogliono aspettare un piano cardine a lungo termine per ottenere le funzionalità che desiderano e non è sempre fattibile spostare la funzione in un modulo client - a volte noi è necessario modificare il nucleo del prodotto ...

Qualcuno ha qualche feedback su una buona pratica dato quel tipo di vincoli?

Answer 1

Suggerirei quanto segue, che utilizziamo nel mio ambiente attuale: tratta la funzionalità non pianificata come faresti con una correzione di sicurezza.

• Ogni versione pianificata (ad es. 3.0, 3.1) ottiene il proprio numero di versione e il proprio tag nel codice sorgente. Dopo che è stato rilasciato, non lo tocchi.
• Le nuove funzionalità dopo una versione pianificata passano alla versione successiva pianificata (ad es. 3.2)
• Se devi modificare una versione rilasciata del codice, si tratta di una "versione non pianificata" e ottiene un numero di versione della patch (ad es. 3.1.1, 3.1.2). Tutte le modifiche:
  • Implementarsi in un nuovo ramo basato sull'ultima patch di quella versione (ad es. 3.1.1 è stato creato da 3.1.0, 3.1.2 è stato creato da 3.1.1)
  • Vengono immediatamente uniti al trunk, quindi entrano anche nella prossima versione pianificata
• Dopo aver implementato la funzione non pianificata, si trasforma il ramo in un tag (ovvero non lo si tocca più) e si torna a lavorare nel trunk.

In questo modo, ogni funzione non pianificata ottiene un ramo, ma solo abbastanza a lungo per effettuare una nuova versione e fondersi nel trunk. Fai quasi tutto il tuo lavoro in un unico posto - trunk - e non hai molto lavoro di fusione da fare.

Answer 2

Una nuova filiale come ('new_feature_branch') è lì per materializzare un sforzo di sviluppo che non è compatibile con l'attuale branch (come 'release_branch')

Quindi, se il tuo attuale release_branch non è molto attivo, puoi usarlo per la nuova funzionalità (a condizione che tu abbia definito un'etichetta prima di sviluppare questa nuova funzionalità, nel caso in cui tu debba annullare quel processo e andare torna allo stato precedente questa nuova funzione)

La creazione di un nuovo ramo può essere una buona soluzione, a condizione che venga unita regolarmente (ogni 3 settimane) al ramo di rilascio e quindi lasciata fuori. È particolarmente consigliato se si hanno alcune attività su release_branch (come alcuni hot bug-fixing). quindi i due sforzi devono essere tenuti separati.

Fondamentalmente, tutto si riduce alla tua unisci flusso di lavoro definizione.

Lascia commenti se vuoi che dettaglia alcune opzioni che ritieni non mi siano sufficientemente approfondite.

Answer 3

Nel mio ufficio di solito lavoriamo su 3 filiali in un dato momento.

• Rilascio: è qui che il codice attualmente distribuito viene taggato e archiviato. Se è necessario eseguire correzioni di errori critici, è qui che viene svolto il lavoro. Quando distribuito, in genere incrementiamo la parte dell'aggiornamento rapido del tag (ovvero 1.19.0 - > 1.19.1).
• QA: qui è dove il codice che si sta preparando per i clienti viene taggato e archiviato. Questo ramo viene utilizzato quando stiamo iniziando un nuovo lavoro e abbiamo del codice che è attualmente testato dal QA in preparazione per la consegna successiva.
• Principale: è qui che viene svolto tutto il nuovo lavoro.

In rare occasioni in cui è necessario svilupparsi in una quarta riga (a causa di pianificazioni di rilascio molto rigide), occasionalmente apriremo la nostra linea di codice sandbox. Sebbene in genere avremo solo un singolo sviluppatore che lavora in isolamento e non effettuerà il check-in fino a quando la riga principale non sarà stata cancellata.

Con la strategia di branching sopra, siamo stati in grado di apportare importanti modifiche alle funzionalità con una consegna alla fine di ogni sprint.

Answer 4

Non sembra che tu stia davvero vivendo in un ambiente Scrum. Scrum richiede che il team sia FATTO alla fine di ogni Sprint, che dovrebbe durare non più di quattro settimane (più probabilmente da una a due settimane). Quindi, ogni paio di settimane, dovresti avere comunque un sistema completamente testato, funzionante, potenzialmente distribuibile.

L'unico modo che conosco per farlo è disporre di suite complete e completamente automatizzate di test per clienti e sviluppatori (come prescrive Extreme Programming).

Non sono sicuro del motivo per cui in questo caso avresti bisogno di succursali, ma non capisco anche perché non sarebbe mantenibile. Nella mia esperienza, più brevemente è vissuto un ramo, meglio è.