Branch di sviluppo paralleli, repository di Build Artifact e release QA

Question

In che modo lo sviluppo/ramificazione parallela nel VCS influisce sull'installazione e sul rilascio del repository degli artefatti build nel QA?

Nella nostra azienda diramiamo i nostri VCS per gli sforzi di sviluppo parallelo e spesso non abbiamo molto di un avvertimento su quale ramo verrà spedito in quale ordine.

Per la numerazione delle versioni, desidero inserire un identificatore di diramazione per mostrare il QA da cui è derivata la generazione. Qualsiasi costruisce dal tronco avrebbe un numero 'normale' la versione senza identificatore filiale in esso:

trunk: 1.1.0 
branch: 1.1.0.MyBranch 
branch: 1.1.0.AnotherBranch 

Inizialmente ho pensato di avere un artefatto repository accumulo per filiale, e un repository principale per il tronco.

Ma se la mia numerazione di versione include il ramo, il numero di versione sarà errato per il prodotto (se sto costruendo e rilasciando dal ramo).

Il modo per aggirare questo è quello di rilasciare solo dal bagagliaio?

Inoltre, a che punto dovrei iniziare a spedire le build del team QA dal bagagliaio anziché dalle build del ramo?

La mia idea attuale è convincere il management ad assegnare un team di sviluppo a un ordine di rilascio (ad esempio una settimana dopo il rilascio) e unire il ramo al trunk. Quindi il QA inizia a ottenere le build del tronco invece delle build del ramo e il team di sviluppo il cui ramo è stato unito risolve eventuali bug direttamente nel trunk e non nel ramo.

* UPDATE *

Più in particolare, sto usando SVN per VCS e Artifactory per il mio repository. Sto usando Ivy per la gestione delle dipendenze.

Guardando l'aiuto Artifactory sul Repository Layout (Repository Layouts):

"a sequence of literals that identifies the base revision part of the artifact 
version, excluding any integration information" 
"'1.5.10', or in case of an integration revision '1.2-SNAPSHOT' the base revision 
    is '1.2'" 

Questo e il layout di default per Maven e Ivy suggeriscono a me che questo è più comune:

MyRepo 
MyLib 
    1.1.0 (this is the dll from trunk) 
    -MyLib.dll 
    1.1.0.MyBranch-SNAPSHOT (dev builds from the "MyBranch" branch) 
    -MyLib.dll 
    1.1.0.AnotherBranch-SNAPSHOT (dev builds from the "AnotherBranch" branch) 
    -MyLib.dll 

È questo il tipico layout dei pronti per l'uso di Ivy? Suppongo che ciò richiederebbe l'utilizzo della funzione di diramazione di Ivy per risolvere le dipendenze in fase di compilazione nella cartella di diramazione corretta nel repository?

* UPDATE 2 *

Qui è il mio attuale struttura Artifactory:

MySnapshotRepo 
CompanyName 
    CompanyName.MyLib 
    1.0-SNAPSHOT 
    MyLib.dll (snapshot builds from the dev branch) 
MyReleaseRepo 
CompanyName 
    CompanyName.MyLib 
    1.0.0 
    MyLib.dll (release builds from the trunk) 
    1.0.1 
    MyLib.dll (release builds from the trunk) 
    1.0.2 
    MyLib.dll (release builds from the trunk) 

1. Come posso puntare Ivy in un repo specifica al momento della compilazione? Per una versione, ho bisogno di estrarre solo i binari dal repository di rilascio. Per una compilazione di istantanee, posso estrarre i binari se compaiono nel repository dell'istantanea, se mancano li posso estrarre dal repository di rilascio. Capisco come concatenare i repository, semplicemente non capisco come cambiarli.

Nel mio IvySettings.file xml che ho:

<settings defaultResolver="defaultresolvechain"/> 

.. ma non voglio un valore predefinito. Mi piacerebbe specificare quale catena di risolutori risolvere in quando chiamo il comando di risoluzione Ivy. Qualcosa di simile:

<ivy:resolve transitive="false" resolveMode="snapshot-resolve" conf="compile,test"/> 

È questo il modo sbagliato per cambiare i reposli che ho bisogno di risolvere contro?

L'attività di pubblicazione ha un attributo "resolver" che funziona perfettamente per me in modo simile.

Inoltre, nel mio particolare esempio, potrei avere più rami SVN corrispondenti a più repository di istantanee Artifactory. Posso parametrizzare il modo in cui risolvo a quali reposli? O è il modo più corretto per posizionare istantanee da tutti i rami in un repository e utilizzare la funzione di diramazione Ivy?

Per favore fatemi sapere se avete bisogno di altre informazioni per aiutare.

Answer 1

Così hai versioni di rilascio e build di funzionalità o di sviluppo. Otterrete i build di rilascio dal trunk e le feature build dalla sezione 1.1.0 alle feature. Non usare il tronco per lo sviluppo. Esegui tutto lo sviluppo su tali feature branch, quando maturano e decidi di includerli come parte del rilascio, unendoli a trunk. A quel punto questo codice appare nelle build del QA che provengono dal trunk. Mentre ti stai preparando per il rilascio, ti allontani dal tronco, mentre continui a lavorare su altri rami di funzionalità e li unisci al tronco.

Quindi il QA ottiene i build dal tronco e dai rami di rilascio della stabilità. Puoi semplificare ulteriormente avendo una sola release alla volta e fai sempre QA solo da trunk, branch o tag al momento della pubblicazione effettiva. Questo sarebbe possibile se non ci fosse assolutamente nessuno sviluppo per il trunk, ma tutti i rami delle funzionalità.

A volte è necessario essere in grado di passare una generazione di sviluppo al controllo qualità. Di solito prima di unire il ramo della funzione al tronco, per essere sicuri di non aver infranto nulla. È possibile contrassegnare l'unione preliminare, unire il ramo di funzione al tronco e creare il build del QA dal trunk in questo caso e se ci sono problemi seri, è possibile tornare al tag. Impedirà la fusione da un altro ramo di funzionalità, mentre questo sta succedendo, ma se le fusioni verso il basso non sono frequenti, questo potrebbe funzionare.

In questo modo è possibile avere un'unica configurazione per il controllo qualità dal trunk e si dovrebbe gestire la maggior parte di ciò che è necessario fare.