Quali artefatti salvare per una costruzione notturna?

Question

Supponi di aver impostato un build notturno automatico . Quali artefatti della build dovrei salvare?

Ad esempio:

• Inserisci codice sorgente
• binari di output

Inoltre, per quanto tempo dovrei salvarli e dove?

Le tue risposte cambiano se faccio l'integrazione continua?

Answer 1

Ecco alcuni artefatti / informazioni che sono abituato a conservare ad ogni build:

• Il nome del tag dell'istantanea che stai creando (tag e fai un checkout pulito prima di creare)
• Gli script di compilazione stessi o il loro numero di versione (se li trattate come un progetto separato con il proprio controllo di versione)
• L'output dello script di build: registri e prodotto finale
• Un'istantanea del tuo ambiente:
  • versione del compilatore
  • versione dello strumento di compilazione
  • librerie e versioni dll / libs
  • versione del database (client e server)
  • versione ide
  • versione dell'interprete degli script
  • Versione SO
  • versione di controllo del codice sorgente (client e server)
  • versioni di altri strumenti utilizzati nel processo e qualsiasi altra cosa che potrebbe influenzare il contenuto dei prodotti della tua build. Di solito lo faccio con uno script che richiede tutte queste informazioni e le registra in un file di testo che dovrebbe essere archiviato con gli altri manufatti di build.

Ponetevi questa domanda: " se qualcosa distrugge interamente il mio ambiente di build / sviluppo di quali informazioni avrei bisogno per crearne uno nuovo in modo da poter rifare la mia build # 6547 e finire con lo stesso esatto risultato che ho ottenuto la prima volta ? "

La tua risposta è ciò che dovresti tenere ad ogni build e sarà un sottoinsieme o un superset delle cose che ho già menzionato.

Puoi archiviare tutto nel tuo SCM (ti consiglierei un repository separato), ma in questo caso la tua domanda su quanto tempo dovresti mantenere gli articoli perde senso. Oppure dovresti memorizzarlo in cartelle zippate o masterizzare un cd / dvd con il risultato di compilazione e gli artefatti. Qualunque cosa tu scelga, disponi di una copia di backup.

Dovresti conservarli fintanto che potresti averne bisogno. Quanto tempo dipenderà dal ritmo del tuo team di sviluppo e dal tuo ciclo di rilascio.

E no, non penso che cambi se fai un'integrazione continua.

Answer 2

Non dovresti salvare nulla per il gusto di salvarlo. dovresti salvarlo perché ne hai bisogno (ad esempio, il QA utilizza build notturne per testare). A quel punto, "quanto tempo per salvarlo" diventa per quanto tempo il QA li desidera.

Non vorrei " salvare " codice sorgente tanto quanto tag / etichetta. Non so quale controllo del codice sorgente stai usando, ma il tagging è banale (prestazioni e spazio su disco) per qualsiasi sistema di controllo del codice sorgente di qualità. Una volta che la tua build è taggata, a meno che tu non abbia bisogno di file binari, non c'è davvero alcun vantaggio ad averli in giro perché puoi semplicemente ricompilare quando necessario dal sorgente.

La maggior parte degli strumenti CI ti consente di taggare ogni build riuscita. Questo può diventare problematico per alcuni sistemi in quanto puoi avere facilmente più di 100 tag al giorno. In questi casi, ti consiglio di eseguire comunque una build notturna e di etichettarla solo.

Answer 3

Questa non è una risposta diretta alla tua domanda, ma non dimenticare di controllare la versione stessa della configurazione della build notturna. Quando la struttura del progetto cambia, potrebbe essere necessario modificare il processo di compilazione, che da quel momento in poi interromperà le build precedenti.

Answer 4

Oltre ai file binari, come tutti gli altri hanno menzionato, consiglierei di impostare un server dei simboli e un server di origine e assicurandoti di ottenere le informazioni corrette da e verso quelle. Aiuterà nel debug tremendamente.

Answer 5

Salviamo i binari, spogliati e non spogliati (quindi abbiamo esattamente lo stesso binario, una volta con e una volta senza simboli di debug). Inoltre costruiamo tutto due volte, una volta con l'output di debug abilitato e una volta senza (di nuovo, spogliato e non spogliato, quindi ogni build risulta in 4 binari). La build viene archiviata in una directory in base al numero di revisione SVN. In questo modo possiamo sempre conservare la fonte dal repository SVN semplicemente controllando questa revisione (in questo modo anche la fonte viene archiviata).

Answer 6

Un aspetto sorprendente di cui ho appreso di recente: se ti trovi in ??un ambiente che potrebbe essere controllato, vorrai salvare tutto l'output della tua build, l'output dello script, l'output del compilatore, ecc.

È l'unico modo per verificare le impostazioni del compilatore, i passaggi di creazione, ecc.

  

Inoltre, per quanto tempo conservarli e dove salvarli?

Salvali fino a quando non sai che la build non andrà in produzione, anche se hai i bit compilati in giro.

Un posto logico per salvarli è il tuo sistema SCM. Un'altra opzione è quella di utilizzare uno strumento che li salverà automaticamente per te, come AnthillPro e simili.

Answer 7

Stiamo facendo qualcosa di simile a " incorporato " sviluppo qui, e posso dirti cosa salviamo:

• il numero di revisione SVN e il timestamp, nonché la macchina su cui è stato costruito e da chi (anche bruciato nei binari di compilazione)
• un registro di compilazione completo, che mostra se si trattava di una compilazione completa / incrementale, di qualsiasi output interessante (STDERR) degli strumenti di cottura dei dati prodotti, di un elenco di file compilati e di eventuali avvisi del compilatore (compressi molto bene, essendo di testo)
• i file binari effettivi (per ovunque da 1-8 configurazioni build)
• file prodotti come effetto collaterale del collegamento: un file di comando del linker, una mappa degli indirizzi e una sorta di "manifest" file che indica ciò che è stato masterizzato nei file binari finali (CRC e dimensioni per ciascuno), nonché il database di debug (equivalente .pdb)

Spediamo anche il risultato dell'esecuzione di alcuni strumenti sull'effetto collaterale " file per gli utenti interessati. In realtà non li archiviamo poiché possiamo riprodurli in un secondo momento, ma questi rapporti includono:

• totale e delta della dimensione del filesystem, suddivisi per tipo di file e / o directory
• dimensioni totali e delta delle sezioni di codice (.text, .data, .rodata, .bss, .sinit, ecc)

Quando sono in esecuzione test unitari o test funzionali (ad es. test del fumo), tali risultati vengono visualizzati nel registro di build.

Non abbiamo ancora eliminato nulla, dato che i nostri build di destinazione di solito finiscono a ~ 16 o 32 MiB per configurazione e sono abbastanza comprimibili.

Conserviamo copie non compresse dei file binari per 1 settimana per un facile accesso; dopo di ciò manteniamo solo la versione leggermente compressa. Circa una volta al mese abbiamo uno script che estrae ogni .zip che produce il processo di compilazione e 7-zip un intero mese di output di compilazione insieme (che sfrutta solo piccole differenze per compilazione).

Un giorno medio potrebbe avere una dozzina o due build per progetto ... Il server di build si sveglia circa ogni 5 minuti per verificare le differenze e le build pertinenti. Un pieno .7z su un grande progetto molto attivo per un mese potrebbe essere 7-10GiB, ma è certamente conveniente.

Per la maggior parte, siamo stati in grado di diagnosticare tutto in questo modo. Occasionalmente c'è un singhiozzo sul sistema di compilazione e un file non è in realtà una revisione che dovrebbe essere quando si verifica una compilazione, ma di solito ci sono prove sufficienti di ciò nei registri. A volte dobbiamo scavare uno strumento che comprenda il formato del database di debug e fornisca alcuni indirizzi per diagnosticare un arresto (abbiamo stackdump automatici integrati nel prodotto). Ma di solito tutte le informazioni necessarie sono lì.

Non abbiamo ancora dovuto decifrare gli archivi .7z, per citare. Ma abbiamo le informazioni lì e ho alcune idee interessanti su come estrarre bit di dati utili da esso.

Answer 8

Salva ciò che non può essere riprodotto facilmente. Lavoro su FPGA dove solo il team FPGA ha gli strumenti e alcuni core (librerie) del progetto sono autorizzati a compilare su una sola macchina. Quindi salviamo i flussi di bit di output. Ma prova a controllarli l'uno sull'altro piuttosto che con un timbro data / ora / versione.

Answer 9

Salva come in check-in nel controllo del codice sorgente o solo sul disco? Non salvare nulla nel controllo del codice sorgente. Tutti i file derivati ??devono essere visibili nel file system e disponibili per gli sviluppatori. Non effettuare il check-in di file binari, codice generato da file XML, digest di messaggi, ecc. Una fase di confezionamento separata renderà disponibili questi prodotti finali. Dato che hai il numero di modifica, puoi sempre riprodurre la build, se necessario, supponendo ovviamente che tutto ciò di cui hai bisogno per fare una build sia completamente nella struttura ed è disponibile per tutte le build sincronizzando.

Answer 10

Vorrei salvare i file binari creati per tutto il tempo in cui hanno la possibilità di andare in produzione o essere utilizzati da altri team (come un gruppo di controllo qualità). Una volta che qualcosa ha lasciato la produzione, ciò che ne fai può variare molto. Per molte squadre, manterranno solo la loro build precedente più recente (per il rollback) e altrimenti scarteranno le loro build.

Altri hanno requisiti normativi per mantenere tutto ciò che è andato in produzione fino a sette anni (banche). Se sei un'azienda produttrice di prodotti, manterrei qualsiasi binario che un cliente potrebbe aver installato nel caso in cui un tecnico dell'assistenza tecnica volesse installare la stessa versione.