Come devo ramificare e taggare prima e dopo un rilascio?

Question

Ho pensato al processo di distribuzione che sto attualmente utilizzando e mi chiedo se esiste un buon modo per gestire il branch / tagging del codice che sarà / è stato rilasciato alla produzione.

Ad un certo punto voglio creare un ramo come ramo di rilascio e apportare eventuali modifiche dell'ultimo minuto al ramo e rilasciarlo. Quindi dopo averlo rilasciato voglio salvarlo come tag.

Per chiarire, sto cercando convenzioni per nominare, gestire i rami e gestire il tagging. Mi chiedo anche se ci sono alternative a come sto parlando di come gestire la situazione.

• Dai un nome ai rami di rilascio o usi sempre lo stesso ramo di rilascio con il nuovo codice?
• Eliminare i rami di rilascio una volta che esistono come tag?
• Come si chiamano i rami / tag?

Answer 1

Suggerisco di leggere questa risposta

Gestione delle versioni in SVN

Fondamentalmente hai un ramo chiamato RELEASE che puoi taggare da lì se vuoi. E mantieni la versione del codice bleeding edge nel trunk

Per quanto riguarda la denominazione delle versioni: dipende da cosa ti si addice meglio e da chi sono le persone che vedono il numero di versione.

Pensa all'utilizzo di MajorRelease.MinorRelease, quindi forse da qualche parte per il tecnicamente interessato potresti persino specificare un numero di rilascio della patch (gli aggiornamenti automatici dell'app e.gg e major.minor rimangono gli stessi).

Importanti: grandi cambiamenti - > nuova funzionalità / compatibilità interruzioni Minore: interfaccia compatibile (ad es. Prestazioni) Patch: correzioni di errori

Answer 2

Puoi usare le informazioni qui come guida anche se non stai usando TFS.

Guida alle ramificazioni

Answer 3

Ci sono molti modi di lavorare. Quello che uso è il seguente:

project_repository
|
|- trunk //Where the current in support release is.
|
|- branches //Where new features/big fixes or refactors are made.
|
|- tags //Where all releases are tagged.
     |
     |- releases //where all release tags are located
     |- daily //where all daily tags are located.

La denominazione che utilizziamo è la seguente:

• Per i rami chiamiamo il ramo in base a quali sono le principali attività che verranno svolte in esso (ad esempio: admin_module_refactor).
• Per i tag, denominiamo i tag con il numero di versione (mayor.minor.micro, ad es. 1.0.2) quando corrispondono a un tag di rilascio. O con la data per i tag di lavoro quotidiani (ad es .: YY_MM_DD).

Per seguire questa struttura e convenzioni di denominazione, abbiamo una serie di strumenti e script che aiutano a lavorare in questo modo. Inoltre i tag giornalieri vengono generati da un server di build tutte le notti.

Answer 4

Ho automatizzato il processo di compilazione utilizzando CruiseControl.Net. Avevamo le build corrispondenti ai numeri di build, quindi la versione della dll sarebbe 6.5.4.1234. Il 6 e il 5 sarebbero sempre stati aggiornati manualmente quando avessimo versioni maggiori e minori. Il 4 è stato aggiornato manualmente dopo una build (e anche il 1234 è stato ripristinato su 0). Il processo di generazione ha sempre aggiornato il 1234 al 1235.

Quando siamo stati rilasciati da un trunk (la versione sarebbe sempre 6.0.0.x), diramavamo manualmente e lo chiamavamo Branch_6_0. Il ramo verrà quindi compilato come 6.0.1. Il trunk si sposterà su 6.1 o 7.0.

CruiseControl aveva due modalità (sviluppo e test). Il test veniva sempre creato su richiesta e creava un ramo corrispondente alla versione di build.

Answer 5

  

Ad un certo punto voglio fare un ramo   come ramo di rilascio e creane uno qualsiasi   last minute cambia nel ramo e   rilascialo

Questa è la parte che mi preoccupa. In genere, vorrai creare un ramo, fare tutto il tuo sviluppo su di esso, quindi reintegrare quel ramo con il tronco. Crea il tuo tag da questo punto sul trunk. Se si desidera apportare ulteriori modifiche, creare un nuovo ramo, modificare, reintegrare e rilasciare nuovamente.

Non tentare di apportare modifiche al ramo di rilascio in quanto potresti perderle o potresti avere problemi a fonderle di nuovo al trunk.

L'approccio alternativo al rilascio di ramificazioni è di apportare tutte le modifiche allo sviluppo su trunk e quando sei pronto, crea un ramo di rilascio / tag. Per un piccolo negozio di sviluppo, questo è di solito il modo più semplice per andare. (L'altro approccio funziona bene quando si apportano grandi modifiche a un prodotto a cui anche tutti gli altri stanno apportando modifiche).