Git Flow con VSTS Build Pipelines

Naviga le tue risposte
4

Sto cercando di sposare l'approccio git flow (w / dev, test, uat, staging, prod env) & build e rilasci automatici in Visual Studio Team System (VSTS). Leggermente faticoso a causa del VSTS che ha bisogno di un ramo persistente su "anchor" - Sono curioso di sapere cosa fanno gli altri.

Il nostro approccio

  1. branch newFeature da develop branch.
  2. funziona, e amp; aumentare PR per newFeature . Una volta approvato e amp; Esecuzioni di build automatiche, newFeature è unito a develop ed eliminato.
  3. Questa build viene quindi distribuita nell'ambiente di sviluppo e viene verificata la verifica.
  4. La stessa build [invariata] può quindi essere distribuita nell'ambiente di test e QA'ed.
  5. Quando i tester sono felici, il rilascio è pronto per UAT. Creiamo un nuovo ramo release-x da develop , forse anche cherry picking ..
  6. release-x viene quindi creato quindi distribuito in UAT.
  7. i problemi / i difetti sono prioritari e risolti .. alcuni vanno nel backlog, alcuni sono fatti direttamente in release-x è fondamentale.
  8. una volta che tutto pronto release-x è unito a master branch, che attiva un nuovo, terzo build ..
  9. quella build viene distribuita nell'env di gestione temporanea per i controlli finali dei clienti
  10. quando tutto va bene, la stessa build viene anche distribuita alla produzione

Quindi, per raggiungere questo obiettivo, abbiamo un paio di pipeline di build / release:

  • dev / test - questo prende la build prodotta al completamento della funzione e fa lo stesso build build per test
  • staging / prod - questo prende la build prodotta una volta che una release si è fusa in master, e può anche spingerla in prod
  • non hanno nulla di automatizzato per UAT a causa del fatto che release-x non è permanente

La domanda generale che ho qui è davvero duplice:

  1. Dove / quando dovrebbe prendere un ramo di rilascio?

    • quando viene eseguita una build di sviluppo?
    • dopo una build di test ok?
    • qualcos'altro?

  2. Quanto è meglio evitare le 3 build che attualmente abbiamo? : |

Penso che mi piacerebbe fare il primo ... ma non sono sicuro di come possa essere sistemato VSTS CICD?

    
posta m1nkeh 04.09.2018 - 12:37
fonte

1 risposta

0

La tua vita sarà più facile se costruisci solo da rami persistenti. cioè sviluppare e padroneggiare.

Lo stai già facendo con i tuoi build di sviluppo, se segui gitflow dovresti costruire dal ramo master dopo aver unito il ramo di rilascio. Non il ramo di rilascio pre-unione.

Le modifiche successive alla versione vengono eseguite sui rami di aggiornamento rapido e nuovamente create sul master una volta che l'hotfix è stato unito.

Vorrei inoltre consigliare di non spingere la tua build di sviluppo oltre l'ambiente di sviluppo. Tutti i test appropriati dovrebbero essere eseguiti con gli stessi binari che verranno rilasciati. Non lo stesso codice sorgente.

Quindi vorrei andare

  • funzione finale, unisci per sviluppare
  • build sviluppa e implementa in DEV env.
  • esegui il test di sviluppo di nuove funzionalità nell'ambiente DEV finché non sei soddisfatto della loro completezza, tutti i test automatici passano
  • completa più funzionalità ....
  • crea un ramo di rilascio, se necessario
  • fai le ultime modifiche per il rilascio, imposta la versione, aggiungi i documenti ecc.
  • Unisci versione in master
  • costruisci master e premi su TEST
  • versione di prova
  • correzioni di bug nei rami di aggiornamento rapido, generazione dal master
  • invia la stessa build a UAT dopo aver superato il test
  • eseguire UAT, correzioni di errori nei rami dell'aggiornamento rapido
  • invia la stessa build per la vita

Ora ovviamente lo svantaggio di questo è se di solito trovi molti bug durante i test, il tuo ramo principale ha un sacco di commit "cattivi"

Il lato positivo è il test della versione esatta del software che distribuisci.

Se hai molti test automatici e passano tutti in DEV, non dovresti avere alcun bug nel master.

Se stai facendo test manuali, probabilmente stai meglio spingendo la build DEV su TEST e facendo le tue correzioni di bug come branch di funzionalità

    
risposta data 04.09.2018 - 17:11
fonte

Leggi altre domande sui tag

Conoscete uno schema di progettazione della pompa di dati? CMP Entity Beans come soluzione ORM "ingenua"