CI - Quanto è lungo?

La CPU dovrebbe essere vicina al 100% di utilizzo. Altrimenti stai solo sprecando CPU. Lo stesso con la memoria.

Mezzi continui con la frequenza che è possibile gestire. Se il tuo server è al massimo, quindi avviare le build velocemente come andrà. A volte potrebbe essere abbastanza impegnato da trascinare il tempo di risposta, ma se si abbassa l'intervallo di controllo, il tempo di risposta verrà sempre trascinato verso il basso. Non ha senso cercare di "conservare" il tempo di inattività sul server. Se il tuo attuale tempo di risposta scende spesso a livelli inaccettabili, quindi aggiungi altri server.

Non dovresti controllare le modifiche - lasciare che il sistema di controllo del codice sorgente "spinga" il controllo delle notifiche sul sistema di generazione (potrebbe essere necessario ottenere un nuovo SCM o un sistema di compilazione, consiglio vivamente Jenkins )

Quindi, ovviamente questo fermerebbe un sacco di problemi sul server.

Il prossimo problema è quanto continua il check-in? Se le persone si impegnano ogni 5 minuti, non sarà di grande aiuto. Quindi l'ultima domanda è: quanto durano queste build? Se trascorri 20 minuti a costruire un componente registrato e ad eseguire test e analisi e creare pacchetti di installazione, e dipende da altri, anche quelli sono automaticamente compilati, anche se non sono stati modificati?

Controlla il sistema di build per vedere cosa sta facendo. Ho scoperto che è facile configurare un server di build che faccia troppa formazione necessaria. Quello sarebbe il primo passo che farei.

Nel mio team, la nostra configurazione CI ci consente di avviare un lavoro ogni volta che vengono rilevati cambiamenti nell'SMM; questo è ciò che significa continuo per noi.

Se disponi delle risorse, prendi in considerazione l'implementazione di un sistema di CI distribuito per scaricare il carico di lavoro su più server e mantenere l'utilizzo delle risorse al minimo sul master.

Abbiamo diversi lavori per fare cose specifiche. Successivamente, non è necessario attivare tutti i lavori, di per sé. A seconda di dove sono state apportate le modifiche, possiamo attivare uno o più lavori secondo necessità.

Poiché i lavori sono focalizzati su un'attività specifica e specializzati, generalmente completano l'esecuzione in un tempo ragionevole.

Come già notato, la soluzione migliore è configurare svn con un hook post-commit in modo che notifichi hudson quando le modifiche sono state confermate. Questo riduce lo stress sul SCM e faciliterà comunque l'IC.

La prima cosa che sembra strana è che si sta eseguendo il polling delle modifiche anziché ricevere le notifiche di modifica. Non ho mai usato CruiseControl .NET, ma gli altri strumenti di integrazione continua che ho utilizzato supportano la ricezione di una notifica o un trigger quando il ramo di integrazione è stato aggiornato. Questo sembra più efficiente, dal momento che non si sprecheranno cicli di controllo degli aggiornamenti che non esistono (temo che ciò ridurrebbe il consumo energetico). Se, dopo questo, il ciclo di build / test nell'ambiente CI è troppo lento o si stanno creando code di lavoro, prenderei in considerazione la possibilità di passare a un ambiente con più server.

La prossima cosa che consiglierei è quella di garantire un certo livello di sicurezza sul fatto che ciò che i tuoi strumenti di configurazione CI costruiranno sempre. A seconda delle dimensioni e della complessità del sistema, potrebbe non avere senso costruire e quindi eseguire ogni test nell'ambiente di sviluppo. Tuttavia, prima della fusione, lo sviluppatore dovrebbe almeno creare il sistema per garantire che i test possano essere eseguiti. Potrebbe anche essere una buona idea avere test del fumo che colpiscono aree chiave del sistema, ma che possono essere eseguite rapidamente in un ambiente di sviluppo - se non passano, lo sviluppatore non unisce le modifiche. È inoltre possibile avere un livello più ampio di test delle unità rispetto ai soli componenti modificati. Lascia il test completo all'integrazione continua, pur mantenendo una sufficiente sicurezza che ti rimarrà una buona build dopo l'unione.

Per me, anche l'idea che una persona che non è in ufficio sia un problema fa parte del problema. Questo problema sarebbe parzialmente ridotto da ciò che ho descritto sopra: i cicli di sviluppo e test degli sviluppatori per ridurre i problemi rilevati durante l'integrazione continua. Tuttavia, è meglio anche che più di una persona possa risolvere i problemi rilevati in alcune parti del sistema. Prendi in considerazione le revisioni del codice, la programmazione delle coppie o il fatto che le persone lavorino in sottosistemi diversi per diffondere la conoscenza.

Penso che molto raramente sia "gettare più tecnologia sul problema" una soluzione appropriata. Guarda come stai usando la tecnologia per prima, insieme agli obiettivi che vuoi raggiungere. Probabilmente finirà per essere il più conveniente a lungo termine.