Come posso applicare CI / CD a un processo di sviluppo "flessibile"

1

Ho letto un bel po ', ma non riesco a trovare articoli adatti al nostro caso d'uso (forse sono cieco), sto cercando alcuni suggerimenti o articoli da leggere.

Abbiamo un paio di team esterni che attualmente usano SVN e ho bisogno di ottenerli usando il nostro controllo sorgente (Mercurial -Kiln) per abilitare l'uso di CI / CD-AppVeyor. Quindi ci sono più team, che lavorano su più funzionalità (e, naturalmente, cambiano le priorità).

Nel complesso, il trunk deve essere sempre pronto per la produzione ed è configurato per CI / CD. Attualmente i rami non fanno parte di CI / CD, solo trunk, ma potremmo introdurre un dev & qa ramo in modo che le build possano essere automaticamente testate e implementate e gli hotfix applicati più facilmente).

Abbiamo un processo di rilascio di Dev- > QA- > Prod, tuttavia, poiché le priorità cambiano o alcuni sviluppi sono più complessi di altri, finiamo in una situazione in cui la caratteristica A (complesso) e la caratteristica B (semplice) sono sviluppati allo stesso tempo, la caratteristica A passa al QA (e il suo complesso richiede tempo per essere testata), mentre il test A, la caratteristica B viene anche spostato al QA, testato e pronto per la produzione, tuttavia, la funzione A non è pronta ancora (o ha cambiato i requisiti) in modo che non possiamo spingere la caratteristica B nel bagagliaio poiché è già unita a A (mi dispiace, ho cercato di semplificare questa spiegazione, oh guarda, è necessaria una correzione rapida ad alta priorità e funzionalità minuscola in produzione immediatamente).

Ora nel mondo SVN il nostro team di outsourcing sembra essere in grado di scegliere i cambiamenti e unirli nel bagagliaio, quindi non hanno questo problema (ho notato hg graft, anche se non capisco perfettamente i suoi compromessi / ripercussioni).

Qualcun altro ha un processo di sviluppo "flessibile" come questo, e come superare il collo di bottiglia e applicare CI / CD?

Il mio attuale pensiero è di trattare i rami in modo indipendente (test, ecc.) fino a quando non sono pronti per essere integrati nella produzione, quindi l'IC / CD tramite dev / qa / prod prende il sopravvento.

    
posta Mr Shoubs 08.05.2017 - 10:42
fonte

1 risposta

1

Non esiste una vera soluzione a questo problema di 'Ive ho unito due funzionalità ma voglio solo una di esse'

Sembra che il tuo team esterno stia selezionando manualmente il bit che desidera e creando una nuova filiale. Il problema con questo è che il test che hanno fatto sulla versione unita non è buono per la nuova versione separata. Dovresti provare di nuovo da zero.

La tua alternativa di non unire una funzionalità fino al completamento del test ha i suoi problemi. A hai bisogno di una tonnellata di ambienti QA e B se il ramo B completa QA e viene unito, quindi devi ripetere il test A, C, D, E ... ecc con il nuovo master incorporato.

Le levette di funzionalità e simili non cambiano davvero la situazione. Si presuppone che una funzionalità disattivata non influirà sul codice, ma questa è una falsa ipotesi. Inoltre si finisce con una configurazione / configurazione estremamente complicata con combinazioni di funzioni attive e disattivate da testare.

Il miglior consiglio che penso è di mantenere le funzionalità piccole e completare ciò che si avvia prima di passare alla prossima cosa.

    
risposta data 08.05.2017 - 14:59
fonte