Modelli / politiche di ramificazione

Question

Attualmente sto rinnovando il modo in cui il nostro negozio esegue il controllo delle versioni. Utilizzeremo una soluzione di controllo della versione incentrata sul server.

Vorrei vedere come le altre persone si stanno ramificando e lo fanno con successo, senza tutti i mal di testa di cui leggo.

Quali sono alcuni modelli di ramificazione testati sul campo che hai visto in un ambiente di produzione che ha funzionato bene, cioè la ramificazione per rilascio. Quali politiche sono state messe in atto per garantire che le ramificazioni procedano senza intoppi.

Grazie

Answer 1

Dipende dal tipo di software che stai sviluppando.

Per noi, siamo un negozio online, quindi non abbiamo "versioni" numerate. Manteniamo il tronco come ciò che è "produzione" degno e commettiamo direttamente solo piccoli cambiamenti.

Quando abbiamo un grande progetto, creiamo un ramo e lo prepariamo pronto per la produzione, sincronizzando al contempo il tronco in esso.

Se il progetto prevede una grande ristrutturazione della base di codice, generalmente creeremo un tag sull'ultima revisione prima di unire le modifiche del ramo.

Ancora una volta, se stai creando software in pacchetti in cui devi mantenere versioni diverse, non funzionerà altrettanto bene.

Per la cronaca, utilizziamo Subversion .

Answer 2

Il libro di sovversione descrive alcuni di uso comune modelli di ramificazione (ad esempio rami di rilascio, rami di caratteristiche, ecc.).

Answer 3

3 cose quando si considera la ramificazione.

Primo: la ramificazione va bene, purché tu voglia unire le cose in seguito. Sicuramente puoi sempre avere una filiale con una patch specifica per uno dei tuoi clienti con un problema specifico. Ma alla fine vuoi unire la maggior parte delle patch al trunk principale

Secondo: asserisci le tue esigenze. Ho visto alberi di tutte le dimensioni a seconda delle dimensioni del reparto, del numero di clienti, ecc ...

Terzo: controlla quanto è buono il tuo controllo del codice sorgente per la ramificazione E l'unione. Ad esempio, CVS è notoriamente molto povero per questo tipo di operazione. SVN, "CVS fatto correttamente" come sostengono, è un po 'meglio. Ma Linus Torvalds che ha creato Git (che è particolarmente utile per questo tipo di operazione) ti direbbe che CVS non può essere fatto bene (lo ha detto in una presentazione molto interessante su Git). Quindi, se hai davvero bisogno di diramazioni e fusioni, almeno ottieni SVN non CVS.

Answer 4

Dai un'occhiata ai modelli di ramificazione:

http://www.cmcrossroads.com/bradapp/acme/branching/

Descrive una serie di motivi per lavorare con i motivi. In genere ho lavorato in due modi:

• Linea di ricezione stabile: tutto lo sviluppo viene eseguito nelle filiali e unito nel trunk solo quando richiesto. Ciò significa che hai sempre un unico punto di rilascio stabile.

• Linea di sviluppo principale: tutto il lavoro viene eseguito nel trunk. Quando si tratta di rilasciare, si prende un tag di rilascio e lo si utilizza. Se sono necessarie importanti rilavorazioni sperimentali, queste vengono eseguite in un ramo e riunite nel tronco quando sono stabili.

Answer 5

Questo è il modo in cui lo facciamo e funziona bene per noi ...

Project
   |
   +--01-Development
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--02-Integration
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--03-Staging
   |
   +--04-Production

bene hai capito ...

NOTA: questa è la struttura delle directory nei rami di Team Foundation Server esistenti solo tra 01-Sviluppo / Versione 1.0 e 02-Integrazione / Versione 1.0, 02-Integration / Release1.0 e 03-Staging / Release1.0, 03-Staging / Release1.0 e 04-Production / Release1.0

In altre parole, non saresti in grado di unire 03-Staging / Release1.0 a 04-Production / Release2.0, ecc ...

Quello che questo fa per noi è che abbiamo 4 ambienti separati Sviluppo, Integrazione (server alfa), Staging (server beta), Produzione.

Il codice inizia nello sviluppo inizia nello sviluppo e poi viene promosso mentre viene testato dal QA (integrazione / alfa) e dagli utenti (Staging / beta) e infine alla produzione.

Le funzionalità / modifiche vengono raccolte e raggruppate in versioni che si verificano ogni pochi mesi.

Ma supponiamo che tu sia in fase di sviluppo per Release2.0 e ricevi un problema di produzione su Release1.0 ... Posso facilmente ottenere l'ultima versione di Release1.0 e risolvere il problema e promuoverlo senza influenzare nulla che io ho lavorato per Release 2.0

Non dire che funzionerà per tutti in ogni situazione ma questo funziona molto bene per noi.