Ho bisogno di aiuto con la filosofia e la progettazione di una configurazione di integrazione continua.
La nostra attuale configurazione di CI utilizza buildbot. Quando ho iniziato a progettarlo, ho ereditato (bene, non rigorosamente, dal momento che ero coinvolto nella sua progettazione un anno prima) un costruttore di elementi della configurazione su misura che era stato progettato per eseguire l'intera costruzione in una sola volta, durante la notte. Dopo un po ', abbiamo deciso che questo era insufficiente e abbiamo iniziato a esplorare diversi framework CI, alla fine scegliendo buildbot. Uno dei miei obiettivi nel passaggio a buildbot (oltre a godermi tutti gli extra di whiz bang) era quello di superare alcune delle inadeguatezze del nostro builder notturno su misura.
Umorizzami per un momento e lasciami spiegare cosa ho ereditato. La base di codice per la mia azienda è quasi 150 applicazioni Windows c ++ uniche, ognuna delle quali ha dipendenze da una o più di una dozzina di librerie interne (e molte anche da librerie di terze parti). Alcune di queste librerie sono interdipendenti e hanno applicazioni dipendenti che (mentre non hanno nulla a che fare l'una con l'altra) devono essere costruite con la stessa build di quella libreria. Metà di queste applicazioni e librerie sono considerate "legacy" e non portabili e devono essere costruite con diverse configurazioni distinte del compilatore IBM (per le quali ho scritto sottoclassi uniche Compile), e l'altra metà è costruita con Visual Studio.ShellCommands, poiché non esiste supporto per VSS).
Il nostro costruttore notturno originale ha semplicemente rimosso la fonte di tutto e ha creato cose in un certo ordine. Non c'era modo di creare una sola applicazione, scegliere una revisione o raggruppare le cose. Avrebbe lanciato macchine virtuali per creare un numero di applicazioni. Non era molto robusto, non era distribuibile. Non era terribilmente estensibile. Volevo essere in grado di superare tutte queste limitazioni in buildbot.
Il modo in cui l'ho fatto originariamente era creare voci per ciascuna delle applicazioni che volevamo creare (tutte 150), quindi creare programmatori attivati che potevano creare varie applicazioni come gruppi e quindi suddividere tali gruppi in uno scheduler di build notturno complessivo. Questi potrebbero essere eseguiti su slave dedicati (niente più chicanery di macchine virtuali) e, se volessi, potrei semplicemente aggiungere nuovi schiavi. Ora, se vogliamo fare una build completa fuori programma, è un clic, ma possiamo anche creare solo un'applicazione se lo desideriamo.
Ci sono quattro punti deboli di questo approccio, tuttavia. Uno è la complessa rete di dipendenze dell'albero dei nostri sorgenti. Per semplificare la manutenzione della configurazione, tutti i costruttori sono generati da un dizionario di grandi dimensioni. Le dipendenze vengono recuperate e costruite in modo non eccessivamente robusto (vale a dire, eliminando alcune cose dal mio dizionario di build-target). Il secondo è che ogni build ha tra 15 e 21 passaggi di build, che è difficile sfogliare e guardare nell'interfaccia web, e poiché ci sono circa 150 colonne, impiega un'eternità a caricarsi (pensa da 30 secondi a più minuti). In terzo luogo, non abbiamo più la scoperta automatica degli obiettivi di costruzione (anche se, per quanto uno dei miei colleghi mi si cacci davanti, non vedo cosa ci abbia portato in primo luogo). Finalmente,
Ora, passando a un nuovo sviluppo, stiamo iniziando a usare g ++ e sovversione (non porting del vecchio repository, intendiamoci, solo per le nuove cose). Inoltre, stiamo iniziando a fare più test unitari ("more" potrebbe dare l'immagine sbagliata ... è più simile a qualsiasi altro ) e test di integrazione (usando python). Sto facendo fatica a capire come inserirli nella mia configurazione esistente.
Quindi, dove ho sbagliato filosoficamente qui? Come posso procedere al meglio (con buildbot - è l'unico pezzo del puzzle su cui ho la licenza di lavorare) in modo che la mia configurazione sia effettivamente mantenibile? Come posso affrontare alcune delle debolezze del mio design? Cosa funziona davvero in termini di strategie di CI per basi di codice di grandi dimensioni (forse troppo) complesse?
MODIFICARE:
Pensavo di aver spiegato il mio problema, ma ovviamente non ero abbastanza chiaro. Sto Non alla ricerca di suggerimenti per la modifica piattaforme CI. E ' non sta per accadere, e non otterrà accettato le risposte che suggeriscono che. Quello che voglio sapere è come le altre persone gestiscono codebase complicate usando CI. Ho una dozzina di prodotti quadrati diversi e ho dipendenze sparse nel vento, e sono tutte diverse. QUESTO è ciò che voglio sapere come affrontare.