Strumenti di integrazione continua con & # 8220; pipeline & # 8221; supporto?

Question

I nostri build e test automatizzati stanno richiedendo una quantità crescente di risorse, soprattutto dal momento che supportiamo molte piattaforme e testiamo sia in debug che ottimizzato. Quindi, sto cercando un supporto per gli strumenti che consentirebbe una "pipeline" più incrementale approccio in modo da poter ottenere feedback e risultati più velocemente. Alcune caratteristiche ideali includono:

1. Supporto per feedback incrementale in modo da poter vedere i risultati della build, unit test, test veloci, test più lunghi, analisi statiche, ecc. non appena disponibili.

2. Dipendenza da attività: se la compilazione fallisce, allora i test non dovrebbero essere eseguiti ma altre attività potrebbero essere (come lanugine o qualcosa del genere).

3. Supporto per più strumenti di compilazione e test (inclusa la personalizzazione).

4. Supporto per più piattaforme (Linux, Mac, possibilmente Windows).

5. Alcune abilità di archiviazione sarebbero ottime, cose come file di registro, output di build / test, ecc. Natrualmente, questo può diventare ingestibilmente grande, quindi alcuni dati verrebbero eliminati idealmente dopo X molti giorni o Y molte build.

Qualsiasi suggerimento o consiglio personale è molto apprezzato.

Answer 1

Potresti dare un'occhiata a Jenkins (precedentemente Hudson) .

Answer 2

Sto usando Anthill ma devi pagare per questo.

Answer 3

Automated Build Studio sembra vicino, anche se probabilmente non lo è ' t un'opzione per te a causa della sua natura solo per Windows.

1. Sì. Il front-end Web fornisce un feedback incrementale mentre i build sono in esecuzione, sia in dettaglio, sia in percentuale.
2. Sì. Il processo di compilazione è una gerarchia di attività. È possibile determinare se un'attività è fallita-continua o fallita-interruzione.
3. Sì. Le attività possono essere praticamente qualsiasi cosa. La cassetta degli attrezzi che la accompagna è piuttosto completa.
4. Nessun. Il server di compilazione deve essere un computer Windows. Puoi comunque avviare build dal front-end web.
5. Sì. Ogni build è registrata in modo dettagliato, gerarchicamente, quindi è facile individuare ciò che è accaduto in ogni fase.

Answer 4

Penso che buildbot farà tutto ciò che vuoi:

1. Il front-end Web visualizza l'output dei comandi.
2. Dipendenze di attività complete
3. Strumenti completamente personalizzati: script in Python, ma principalmente script di shell
4. Attualmente lo stiamo usando su Linux, Mac, Solaris, HP-UX
5. Registra tutto, non so come / se cancella le cose.

Answer 5

Dovrebbe essere d'accordo sull'opzione thinkworks - Vai " Agile Release Management " http://www.thoughtworks-studios.com/go-agile-release-management

Esiste un'edizione della comunità (gratuita) e alcune buone funzioni nell'edizione aziendale come le configurazioni dell'ambiente e la distribuzione di artefatti specifici (versioni) in ambienti specifici.

Answer 6

La configurazione di My JetBrains TeamCity approssima ciò di cui hai bisogno.

In un singolo progetto, ho impostato più configurazioni di build diverse.

La differenza tra ogni configurazione di build è nella scelta dei target di build (utilizzo NAnt) e nel trigger.

Ho un " Integrazione XYZ " configurazione che esegue un build di debug ed esegue alcuni test NUnit. Ciò si innesca 60 secondi dopo il completamento di un check-in, fornendo un rapido feedback al team di sviluppo.

Ho anche un " XYZ Daily " configurazione che esegue un build di debug, esegue test NUnit, quindi crea alcuni MSI e compila della documentazione. Come probabilmente puoi immaginare, questo viene eseguito una volta al giorno.

Potresti fare lo stesso, ma con una gamma più ampia di configurazioni.

Answer 7

Utilizziamo Hericus Software's Zed Builds and Bugs Management e può gestire ciò che stai descrivendo. Le nostre build principali consistono in oltre 61 passaggi discreti che coprono compilazioni per Java, C ++, C # e build di installazione per 5 diverse piattaforme del sistema operativo. Alcuni passaggi vengono eseguiti in parallelo, alcuni possono fallire senza causare il fallimento dell'intera build e molti passaggi vengono eseguiti in remoto su macchine diverse.

1) Sì. Man mano che i passaggi vengono eseguiti per una build, puoi immediatamente vedere i risultati del passaggio senza dover attendere il completamento dell'intera build.

2) Sì. È possibile definire se un errore di passaggio provoca o meno un errore di compilazione completo. La possibilità di creare " child " o " sub " build chiamate da un " parent " o " master " build consente un'estrema flessibilità.

3) Sì. Stiamo usando makefile, formica, soluzioni C # e diversi script personalizzati e tutti si integrano bene.

4) Sì. Il server di build è java e richiede solo un JDK 1.6, quindi qualsiasi piattaforma funziona sia per il server di build principale sia per i server di build satellite.

5) Sì. Tutto copiato nella build "status" la directory viene salvata. Ciò include l'output / errore standard del comando che può essere rivisto dal sito Web. Scegli quanto " dev " cronologia delle build da mantenere in termini di numero di build. Una build può anche essere promossa a "QA" nel qual caso non verrà eliminato fino a quando non sarà stato rimosso da "QA". Dal QA puoi promuovere una build a & Production; " che manterrà tutti i manufatti di build fino a quando non deciderai di eliminarli.

Answer 8

Vi preghiamo di provare Cruise from Thoughtworks