Rilascio software / Utilizzo dell'integrazione continua - Che cosa sembrano utilizzare la maggior parte delle aziende?

7

Ho installato il nostro sistema di integrazione continua, e funziona da circa un anno. Abbiamo finalmente raggiunto un punto in cui vogliamo fare release usando lo stesso. Prima del nostro sistema CI, i processi utilizzati erano:

(Develop) -> Ready for release -> Create a branch -> (Build -> Fix bugs as QA finds them) Loop -> Final build -> Tag

(Develop) -> Ready for release -> (build -> fix bugs) Loop -> Tag



Our CI setup:
1 server for development (DEV)
1 server for qa/release (QA)

Il secondo è perfettamente integrato in CI. Creo un ramo quando il software è pronto per il rilascio e il ramo non cambia mai in seguito, il che significa che la build è riproducibile senza dover modificare il lavoro CI. Qualsiasi sviluppo futuro avviene su HEAD, e anche le versioni di mantenimento ottengono una nuova filiale e un lavoro completamente nuovo, che rimane sul sistema CI per sempre, e poi alcuni.

Il primo metodo è più difficile da adattare. Se il ramo cambia, la build non è riproducibile a meno che non utilizzi il tag per creare [lavori sul server CI utilizza il ramo per QA / RELEASE e HEAD per i build di sviluppo].

Tuttavia, se utilizzo il tag per creare, devo creare un nuovo lavoro di configurazione per creare dal tag (perdere changelog sul server) o modificare il lavoro esistente (perdere la configurazione del lavoro originale).

So che sembra complicato e, se necessario, lo riscriverò / modificherò per spiegare meglio la situazione. Tuttavia, la mia domanda:

[Se presente] quale processo utilizza la tua azienda per rilasciare software utilizzando sistemi di integrazione continua. E 'addirittura fatto usando il sistema CI o manualmente?

    
posta Sagar 08.02.2011 - 00:06
fonte

3 risposte

2

Ci ramifichiamo sul rilascio. Penso che sia inevitabile se si rilasciano le patch, perché applicare le patch significa tornare indietro e aggiornare la versione. Tendiamo anche a mantenere la codifica durante il processo RTM, il che significa che la versione spedita non è aggiornata prima che lasci l'edificio. Alcuni dei nostri utenti saltano le versioni, quindi adesso abbiamo due versioni attive nel campo più la nuova versione su cui stiamo lavorando ora. Quindi abbiamo 1.0, 1.1, 2.0, 2.1, 2.2 e presto 3.0 in uso (e riceviamo chiamate di supporto per tutti loro). Testare la patch / versione della matrice mantiene il QA abbastanza occupato.

Il nostro processo è più simile a questo:

(develop) -> branch to QA -> RTM -> ship -> patch branch ...
          -> keep developing in trunk -> merge patches ...

Sarò interessato a vedere quali altre opzioni appaiono.

    
risposta data 08.02.2011 - 05:01
fonte
1

Usiamo il seguente: (Sviluppa sulla linea principale) - > test di fase 1 - > test di fase 2 - > (Branch from mainline) - > test di fase 3 - > RTM - > Patch sul ramo

Ogni build viene taggata dopo il fatto. La build d'oro ha un tag più tradizionale. Lo sviluppo inizia a lavorare sulla prossima versione sulla linea principale durante i test della fase 3.

    
risposta data 08.02.2011 - 08:43
fonte
1

Costruiamo dal tag. Il lavoro di costruzione è parametrizzato (il parametro è il nome del tag) quindi è necessario crearlo solo una volta.

    
risposta data 08.02.2011 - 14:34
fonte

Leggi altre domande sui tag