Build automatici, strumenti di compilazione e sistemi integrati

Question

Build automatici, strumenti di compilazione e sistemi integrati

#1 da (1 voti)
#2 da (1 voti)

5

Vengo da un mondo embedded in cui usiamo C / C ++ per la programmazione e utilizzo un IDE per generare un file binario, che viene poi programmato in una Hardware Board, che può essere testata.

In questo contesto, quale è il flusso di lavoro migliore per le build automatizzate rispetto al flusso di lavoro corrente di -build (utilizzando IDE) - > Flash nel test dell'hardware & gt ;. In altre parole, c'è un modo in cui posso beneficiare dei vantaggi dell'elemento della configurazione nel dominio in cui lavoro?

builds embedded-systems build-system

posta Vaibhav Garg 21.06.2013 - 05:41

fonte

2 risposte

Leggi altre domande sui tag builds embedded-systems build-system

Esiste una terminologia agnostica per le attività di controllo del codice sorgente? Confronto dei formati di percorso

score 1 · Answer 1

Per il software incorporato, l'integrazione continua può essere utile

se si dispone di test (unità) che possono essere eseguiti in un ambiente di simulazione o
se disponi di un mezzo per eseguire aggiornamenti automatici del dispositivo di destinazione e puoi attivare automaticamente i test (compresi gli stimoli richiesti).

Nel primo caso, è possibile impostare un server CI che crea periodicamente una build per il target di simulazione ed esegue automaticamente i test su tale target simulato. Nel secondo caso, è necessario agganciare una destinazione effettiva al server CI e quindi creare periodicamente una build e testarla.

Il vantaggio in entrambi i casi è che si ottengono test automatici, incustoditi e di regressione che ti diranno se hai rotto qualcosa accidentalmente, anche se si tratta di una parte apparentemente non correlata del software (che non avresti quindi toccato con il tuo test manuali).

score 1 · Answer 2

Ci sono un buon motivo per utilizzare la CI in un team incorporato (se si lavora da soli nel proprio IDE, i vantaggi dell'IC sono meno ovvi, I in CI è l'integrazione e non si sta integrando con nessuno quando si lavora alone)

Ti costringe ad avere un processo di compilazione ripetibile, programmato e automatizzato. L'output del tuo sistema CI è l'output che viene testato e sarà coerente. Indipendentemente da ciò che gli sviluppatori installano sul loro computer, la generazione non verrà modificata.
Il grande vantaggio dell'IC è la possibilità di eseguire test unitari automatizzati. Questi test possono essere compilati in modo incrociato sulla piattaforma della macchina CI. Ciò ha l'effetto collaterale architettonico di disaccoppiare la logica dipendente dall'hardware dal resto, facilitando un'eventuale porta su un'altra piattaforma e facilitando il riutilizzo del codice indipendente dalla piattaforma su un altro progetto.
Si accerterà che ciò che tutti gli utenti si impegnano nel controllo del codice sorgente si costruisca e fornisca rapidamente feedback quando ciò non avviene. Accelera davvero le cose per sapere quale commit ha rotto la build.
Fornirà al team di test un luogo comune per ottenere l'ultima versione senza alcun onere per il team di sviluppo. O per bissare rapidamente un nuovo bug che è apparso da 2 settimane fa ...
Gli strumenti di ispezione, metrica e analisi automatica del codice possono attivare l'avviso sul codice che è stato archiviato.

Solitamente il flusso di lavoro è solitamente quello di avere i prodotti di costruzione disponibili sul server da far lampeggiare sulla lavagna. Nel tuo sviluppo quotidiano, usi il flusso di lavoro build / flash dell'IDE. Non so del tuo progetto, ma è anche possibile avere uno script automatico per far lampeggiare il nuovo firmware sulla scheda effettiva e quindi avviare / arrestare i test automaticamente sulla scheda tramite un'interfaccia seriale, per esempio.