Miglior flusso di lavoro Git adatto alle nostre esigenze

Naviga le tue risposte
2

Ho bisogno di aiuto con il flusso di lavoro più adatto alle nostre esigenze. Siamo una squadra di 3-4 persone e stiamo lavorando su 4 diversi progetti.

Abbiamo tre rami principali:

  • master - ramo di produzione distribuibile
  • staging - funzioni sotto controllo qualità su dati live
  • dev - funzioni sotto controllo qualità sui dati di test

Quindi per ogni funzione, creiamo un ramo di funzionalità

Cosa ci serve:

  • A volte vorremmo creare una versione (per molte funzionalità che hanno qualcosa in comune) e verrebbe distribuita alla fine del mese.
  • A volte vorremmo implementare una funzione / modifica specifica (senza creare una versione). Questo è ciò che facciamo la maggior parte del tempo.

Ora per il flusso di lavoro:

  1. Inizio a lavorare su alcune funzionalità. Creo un ramo della funzione da dev.
  2. Finisco la mia funzione (con 30 commit).
  3. Sposto unisco la mia funzione in dev - quindi diventa solo un commit .
  4. La funzione viene distribuita automaticamente in un ambiente di test e QA verifica la mia funzione su dati di test .
  5. La funzione è stata testata OK, quindi seleziono il mio hash del commit della funzione su un ramo di gestione temporanea. La funzione viene distribuita automaticamente in un ambiente di staging e QA verifica la mia funzione su dati live .
  6. La funzione passa QA (test e staging) ed è selezionata per il master o per un ramo di rilascio, che verrà unito al master alla fine del mese.

Ecco una foto che spiega cosa ho in mente:

Tutto questo ha senso? C'è un modo migliore per raggiungere questo obiettivo? Grazie per il tuo tempo.

    
posta Gaui 20.09.2014 - 19:35
fonte

2 risposte

1

Sembra molto ragionevole. Usiamo qualcosa di molto simile. Il mio consiglio è solo quello di mantenere piccoli i rami delle funzionalità. Forse un giorno di lavoro. Branche più lunghe significano minore produttività a causa di un gran numero di conflitti di fusione. Per lo più un ramo di funzionalità equivale a una nota post-it sulla nostra tabella di mischia.

Una nota è che scrivi "Comincio a lavorare su alcune funzionalità. Creo una funzionalità separata da dev." Questo è un buon approccio 80% delle volte. Ricorda che hai la possibilità di diramare una richiesta pull in sospeso. Abbiamo una regola sul team che dovremmo ottenere qualcun altro dal team per esaminare e unire le richieste di pull. A volte le pubbliche relazioni rimangono in coda per alcune ore. Dal momento che stiamo usando richieste di pull piuttosto piccole. A volte la funzione B dipende dalla funzione A, ma la caratteristica A non verrà unita per alcune ore e quindi non in dev. Quando vuoi iniziare a lavorare sulla funzione B, basta unire A invece che a DEV. È meglio unire dev, se possibile, ma è un buon strumento nella cintura. In questo caso, probabilmente dovresti aspettare di creare il PR per la funzione B prima che la funzione A venga unita a dev perché diffs avrà l'aspetto di entrambi A + B che è fuorviante.

    
risposta data 20.09.2014 - 21:24
fonte
0

Poiché dobbiamo implementare funzionalità specifiche negli ambienti di test e di staging, stavo pensando a qualcosa di simile:

Due rami principali:

  • Master

  • dev

    1. I rami di funzionalità sono diramati da dev
    2. Quando una funzione è pronta per il test, aggiungiamo un tag testing / ISSUE-1234
    3. TeamCity nota il tag e lo distribuisce nell'ambiente di test
    4. Quando la funzione supera il test, aggiungiamo un tag staging / ISSUE-1234
    5. TeamCity nota il tag e lo distribuisce nell'ambiente di gestione temporanea
    6. Quando la funzione passa alla staging, facciamo una richiesta pull al ramo dev e qualcuno esamina il codice e la logica.
    7. Se la revisione del codice è andata bene, unisce il ramo in dev.
    8. Su base mensile uniamo il ramo dev in master

Come suona questo?

    
risposta data 27.09.2014 - 20:07
fonte

Leggi altre domande sui tag

MongoDB Embedded vs Reference Informazioni private Domande su UML in relazione al modello di comando