Come gestire i commit indesiderati che interrompono i build di rilascio di lunga durata?

Question

Come gestire i commit indesiderati che interrompono i build di rilascio di lunga durata?

#1 da (15 voti)
#2 da (0 voti)

6

Recentemente ci siamo imbattuti in una sfortunata situazione lavorativa e mi sono chiesto cosa possiamo fare per evitare problemi simili in futuro.

Realizziamo sistemi embedded. Il codice FPGA si trova in un repository SVN mentre il firmware & il codice software è in un repository diverso. Costruire il firmware richiede le immagini FPGA costruite, quindi questi file binari vengono anche memorizzati nel repository firmware / software. La generazione di FPGA può richiedere 2-3 ore e può casualmente fallire. A mio avviso, questi ultimi fallimenti si verificano a causa dei complessi problemi di temporizzazione nella logica FPGA. Errori di sviluppo come una sintassi errata causeranno il fallimento della generazione in pochi minuti.

Poiché le build impiegano così tanto tempo, gli sviluppatori FPGA generalmente apportano le loro modifiche, costruiscono, danno la nuova immagine agli sviluppatori del firmware e quindi si impegnano a SVN. Qualche settimana fa, questo ha causato un sacco di problemi mentre ci stavamo preparando per un rilascio. Uno sviluppatore FPGA ha apportato una piccola modifica e ha avviato una build. Un altro sviluppatore FPGA ha fatto un commit (dopo che gli era stato detto che le sue modifiche non dovevano essere incluse in questa release e che avrebbe dovuto aspettare per impegnarsi). Dopo questo commit, la build iniziale ha avuto esito negativo. Il primo sviluppatore FPGA dovette quindi ripristinare le modifiche dell'altro, impegnare le sue modifiche e impiegare una notevole quantità di tempo a ispezionare il codice in SVN per assicurarsi che riflettesse il codice utilizzato per costruire l'immagine richiesta per la build del firmware prima di essere taggati per il rilascio.

Se usassimo git o un altro DVCS, questo non sarebbe un problema, dal momento che ogni sviluppatore FPGA poteva eseguire il commit localmente prima di costruire e inviare a un server dopo una build di successo. Il passaggio al controllo della versione non è al momento un'opzione. Stiamo per lanciare più hardware sul problema dei build FPGA lunghi e stiamo valutando se il tempo di costruzione può essere migliorato modificando le impostazioni negli strumenti di creazione.

C'è qualcos'altro che possiamo fare per migliorare i nostri processi in modo da non ripetere questa situazione o scoprire altri problemi con versioning e conflitti?

version-control branching builds

posta Velociraptors 19.03.2013 - 19:07

fonte

2 risposte

Leggi altre domande sui tag version-control branching builds

Quale lingua ha introdotto l'idea di variabili private (nascoste)? [duplicare] È una metodologia agile appropriata in questa situazione?

score 15 · Answer 1

One FPGA developer made a small change and started a build. Another FPGA developer made a commit (after he had been told that his changes did not need to be included in this release and that he should wait to commit). After this commit, the initial build failed. The first FPGA developer then had to revert the other's changes, commit his changes, and spend a significant amount of time inspecting the code in SVN to make sure it reflected the code used to build the image required for the firmware build before we tagged for the release.

Il problema è che stai utilizzando un singolo ramo per più scopi che sono in conflitto. Stai facendo pacchetti di rilascio, correzioni a basso rischio, correzioni ad alto rischio e nello stesso ramo.

Non c'è niente di fondamentalmente sbagliato nel controllare il codice, è solo che deve essere controllato nel posto giusto. Sì, DCVS semplifica alcuni aspetti di questo, sebbene non sia la risposta giusta per ogni soluzione.

Considera che avere il bagagliaio o la linea principale (dove controlli attualmente tutto) siano le correzioni a basso rischio e lo spot di sviluppo a basso rischio - non spezzare le cose per gli altri. Un altro ramo deve essere il ramo di rilascio. Una volta che la versione è pronta, unisci tutte le modifiche dalla linea principale al ramo di rilascio e costruisci da lì. Puoi ancora costruire dalla linea principale, ma quella è una versione di dev / nightly, non una che è pronta.

Se la generazione del rilascio fallisce, ricontrolla il codice nel bagagliaio e seleziona (questa è la chiave - in modo che il secondo codice dello sviluppatore non debba essere ripristinato) che cambia nel ramo di rilascio o controllalo nel ramo di rilascio e unirlo nuovamente alla linea principale. Persone diverse avranno opinioni diverse su quale di queste è la migliore pratica.

Strategie di ramificazione avanzata di SCM è una buona lettura su questo argomento.

Nell'ambiente su cui lavoro, c'è un ramo per il rilascio (rilascio), un ramo per la build di sviluppo (il tronco) e un ramo (o due o tre - se necessario) per vari cambiamenti ad alto rischio . Ciascuno di questi rami ha una build separata nel build server.

score 0 · Answer 2

Raccomando di utilizzare un sistema di revisione del codice oltre al sistema di controllo del codice sorgente. Ciò imporrebbe che ogni commit debba essere rivisto e approvato da altri membri del team prima di essere accettato in un repository. Altri vantaggi includono una migliore condivisione delle conoscenze e la trasparenza dei processi di sviluppo.

modifica: Rallentare le cose è una preoccupazione, ma se si sceglie il giusto strumento di revisione del software e lo si utilizza correttamente, può essere rapido e di grande beneficio. rallentando leggermente il processo di sviluppo a breve termine in questo modo si risparmiano lunghe sessioni di debug / fix quando qualcosa di stupido entra nel repository centrale, risparmiando tempo a lungo termine.