Come fare l'integrazione continua quando rami di sviluppo separati hanno date di implementazione della produzione diverse?

Naviga le tue risposte
5

Supponiamo di avere tre rami di sviluppo attivi contemporaneamente (dev 1, dev 2, dev 3), ciascun ramo che lavora su diverse funzionalità per un determinato prodotto software.

Se comprendo correttamente l'integrazione continua, queste linee di sviluppo dovrebbero ciascuna controllare costantemente il codice su una linea principale condivisa (una volta superato il test), con il codice di linea principale condiviso che viene unito a ogni ramo dev su una base regolare.

Cosa succede se uno dei rami dev (dev 1) è pronto per una distribuzione di produzione e gli altri rami dev (dev 2, dev 3) no? Se il codice filiale dev 1 viene passato attraverso UAT e in produzione, tutto il codice dai rami dev 2 e dev 3 che sono stati "integrati continuamente" in dev 1 verrà anche inserito in Prod, anche se le funzionalità in dev 2 e dev 3 potrebbe non essere pronto (o programmato) per il rilascio.

Come posso evitare questo problema mentre sto ancora aderendo all'integrazione continua?

    
posta Callum 27.10.2016 - 07:12
fonte

3 risposte

3

Oltre a Vlad, avresti impostato gli ambienti di test per ciascun ramo. CI sarà quindi configurato per inviare le modifiche apportate al ramo A al test A e al ramo B al test B.

Un ramo può contenere tra 1 e n funzioni. Meno ne hai in un ramo, meno impatto se scivola.

Le modifiche rimangono nelle loro filiali fino a quando non sono state rilasciate.

Una volta che la Release A è stata creata, unirai la nuova Main (contenente la release A) alla Branch B e continuerai a lavorare sulla Release B.

L'unico limite al numero di filiali che puoi eseguire contemporaneamente è il tuo team / infrastruttura. Un dev può teoricamente essere assegnato a più di una funzione isolata in rami separati contemporaneamente. Consiglio di farlo? Probabilmente no. Termina un lavoro alla volta. Se tuttavia c'è un cambiamento nelle priorità, un ramo può essere parcheggiato mentre un altro viene lavorato.

    
risposta data 27.10.2016 - 07:58
fonte
2

Questa affermazione è sbagliata: "le linee di sviluppo avrebbero bisogno di controllare costantemente il codice in una linea principale condivisa". La vera ragione per introdurre i branch è di non unire il codice unstable al main. Perché hai effettivamente bisogno di tre rami di sviluppo se ti unisci al main subito?

CI non ti spinge a sacrificare la qualità per la frequenza delle implementazioni. Ti spinge a distribuire il più velocemente possibile, ma non più velocemente .

    
risposta data 27.10.2016 - 07:45
fonte
0

Come @vlad ha indicato che il problema è con "le linee di sviluppo avrebbero bisogno di controllare costantemente il codice in una linea principale condivisa"

Ecco cosa dovresti prendere in considerazione:

  • crea un ramo di sviluppo in base alle esigenze
  • funziona sul ramo e spinge il commit in quel ramo
  • recupera le ultime modifiche dal master (per aggiornare il tuo master, NON il tuo ramo)
  • rebase o unisci il tuo ramo contro il master, ma rimani nel ramo
  • inserisci il ramo aggiornato su remoto
  • continua a lavorare, ribloggiandosi a master e premendo commit durante lo sviluppo
  • quando il lavoro è terminato, unisci in master e rilascia.
risposta data 27.10.2016 - 13:07
fonte

Leggi altre domande sui tag

Nome variabile che a volte si riferisce a un oggetto ea volte a una stringa Come evitare l'inizializzazione in due passi (C ++)?