Gestire più filiali in integrazione continua

Question 1

Ho affrontato il problema del ridimensionamento della CI nella mia azienda e allo stesso tempo ho cercato di capire quale approccio adottare quando si tratta di CI e più filiali. C'è una domanda simile a stackoverflow, rami di funzionalità multiple e integrazione continua . Ne ho iniziato uno nuovo perché mi piacerebbe avere maggiori discussioni e fornire alcune analisi sulla domanda.

Finora ho scoperto che ci sono 2 approcci principali che posso adottare (o forse alcuni altri ???).

Più serie di lavori (parlando di Jenkins / Hudson qui) per filiale
- Scrivi strumenti per gestire i lavori extra
  - Crea / modifica / elimina lavori in blocco
  - Impostazioni personalizzate per ogni lavoro per ramo (URL SCM, duplicazioni di repository di gestione dep)
  - Alcuni esempi di persone che affrontano questo problema con strumenti di shell, script ant e Jenkins CLI. Vedere:
- Causerà più carico sul tuo cluster CI
- Il ciclo di feedback per gli sviluppatori rallenta (se l'infrastruttura non è in grado di gestire il nuovo carico)
Set multiplo di lavori per 2 rami (sviluppo e stabile)
- Gestisci i due set manualmente (se modifichi la configurazione di un lavoro assicurati di cambiare nell'altro ramo)
  - PITA ma almeno così pochi da gestire
- Altri rami extra non riceveranno una suite di test completa prima di essere inviati a dev
- Sviluppatori insoddisfatti. Perché uno sviluppatore dovrebbe preoccuparsi dei problemi di scalabilità degli elementi della configurazione Ha una semplice richiesta, quando mi dirigo vorrei testare il mio codice. Semplice.

Quindi sembra che se voglio fornire agli sviluppatori CI per i loro rami personalizzati ho bisogno di strumenti speciali per Jenkins (API o script di shell o qualcosa del genere?) E gestire il ridimensionamento. Oppure posso dire loro di unirsi più spesso a DEV e vivere senza CI su rami personalizzati. Quale sceglieresti o ci sono altre opzioni?

Question 2

Quando parli di scalare CI, stai davvero parlando di ridimensionare l'uso del tuo server CI per gestire tutti i tuoi rami di funzionalità insieme alla tua linea principale. Inizialmente questo sembra un buon approccio in quanto gli sviluppatori di una filiale ottengono tutti i vantaggi dei test automatici inclusi nei lavori CI. Tuttavia, si verificano problemi nella gestione dei lavori del server CI (come hai scoperto) e, cosa più importante, non stai davvero facendo CI. Sì, stai utilizzando un server CI, ma non stai integrando continuamente il codice di tutti i tuoi sviluppatori.

Eseguire un CI reale significa che tutti i tuoi sviluppatori si impegnano regolarmente per la linea principale. Facile a dirsi, ma la parte difficile è farlo senza interrompere l'applicazione. Consiglio vivamente di esaminare la consegna continua , in particolare la sezione Mantenere rilasciabile l'applicazione nel Capitolo 13: Gestione di componenti e dipendenze . I punti principali sono:

Nascondi la nuova funzionalità fino al termine (AKA Feature Toggles ).

Apporta tutte le modifiche in modo incrementale come una serie di piccole modifiche, ognuna delle quali è rilasciabile.

Usa il ramo per astrazione per apportare modifiche su larga scala alla base di codice.

Usa i componenti per disaccoppiare parti della tua applicazione che cambiano a velocità diverse.

Sono abbastanza autoesplicativi tranne ramo per astrazione. Questo è solo un termine di fantasia per:

Crea un'astrazione sulla parte del sistema che devi modificare.

Rifattorizza il resto del sistema per usare il livello di astrazione.

Creare una nuova implementazione, che non fa parte del percorso del codice di produzione fino al completamento.

Aggiorna il tuo livello di astrazione per delegare alla tua nuova implementazione.

Rimuovi la vecchia implementazione.

Rimuovere il livello di astrazione se non è più appropriato.

Il paragrafo seguente della sezione Branches, Streams e Continuous Integration nel Capitolo 14: Advanced Version Control riepiloga gli impatti.

L'approccio incrementale richiede sicuramente più disciplina e cura - e in effetti più creatività - che creare una filiale e immergersi nella ri-architettura e nello sviluppo di nuove funzionalità. Tuttavia, riduce in modo significativo il rischio che le modifiche apportate interrompano l'applicazione e consentirà a te e al tuo team di risparmiare molto tempo per l'unione, la correzione dei guasti e lo stato di implementazione dell'applicazione.

Ci vuole un bel cambiamento di mente per rinunciare ai rami delle funzionalità e otterrai sempre resistenza. Nella mia esperienza questa resistenza si basa sul fatto che gli sviluppatori non si sentano sicuri nell'impegnare il codice sulla linea principale e questa è una preoccupazione ragionevole. Questo a sua volta di solito deriva da una mancanza di conoscenza, fiducia o esperienza con le tecniche sopra elencate e forse con la mancanza di fiducia con i tuoi test automatizzati. Il primo può essere risolto con la formazione e il supporto degli sviluppatori. Quest'ultimo è un problema molto più difficile da affrontare, tuttavia la ramificazione non fornisce alcuna sicurezza extra reale, si limita a rimandare il problema fino a quando gli sviluppatori non si sentono abbastanza sicuri con il loro codice.

Question 3

Stabilirei lavori separati per ogni filiale. L'ho già fatto e non è difficile da gestire e configurare se hai impostato correttamente Hudson / Jenkins. Un modo rapido per creare più lavori consiste nel copiare da un lavoro esistente che ha requisiti simili e modificarli secondo necessità. Non sono sicuro se si desidera consentire a ogni sviluppatore di impostare i propri lavori per i propri rami, ma non è molto lavoro da gestire per una persona (cioè un gestore di build). Una volta che i rami personalizzati sono stati uniti in rami stabili, i lavori corrispondenti possono essere rimossi quando non sono più necessari.

Se sei preoccupato per il carico sul server CI, puoi impostare istanze separate dell'elemento della configurazione o anche slave separati per bilanciare il carico su più server. Assicurati che il server su cui stai eseguendo Hudson / Jenkins sia adeguato. Ho usato Apache Tomcat e dovevo solo assicurarmi che avesse memoria e potenza di elaborazione sufficienti per elaborare la coda di compilazione.

È importante essere chiari su ciò che si desidera ottenere utilizzando CI e quindi trovare un modo per implementarlo senza troppi sforzi manuali o duplicazioni. Non c'è niente di sbagliato nell'usare altri strumenti o script esterni che vengono eseguiti dal tuo server CI che aiutano a semplificare il tuo processo di gestione della build complessivo.

Question 4

Sceglierei dev + rami stabili. E se desideri ancora rami personalizzati e hai paura del carico, perché non spostare questi rami personalizzati nel cloud e lasciare che gli sviluppatori lo gestiscano da soli, ad esempio http://cloudbees.com/dev.cb Questa è l'azienda in cui si trova Kohsuke ora . C'è anche un Eclipse Tooling, quindi se sei su Eclipse, lo avrai strettamente integrato direttamente in dev env.

Question 5

In realtà ciò che è veramente problematico è costruire l'isolamento con i rami delle funzionalità. Nella nostra azienda abbiamo una serie di progetti Maven separati che fanno tutti parte di una distribuzione più ampia. Questi progetti sono gestiti da team diversi ma per ogni distribuzione tutti i progetti devono essere rilasciati. Una featurebranch può ora sovrapporsi da un progetto all'altro e questo è il momento in cui l'isolamento della build diventa doloroso. Ci sono diverse soluzioni che abbiamo provato:

creare repository di snapshot separati in nexus per ogni feature branch
condividere repository locali su slave dedicati
usa il plugin repository-server con i repository a monte
costruire tutto all'interno di un lavoro con un repository privato

In effetti, l'ultima soluzione è la più promettente. Tutte le altre soluzioni mancano in un modo o nell'altro. Insieme al plugin job-dsl è facile configurare un nuovo ramo di funzionalità. è sufficiente copiare e incollare lo script groovy, adattare i rami e lasciare che il lavoro seme crei i nuovi lavori. Assicurarsi che il lavoro di inizializzazione rimuova i lavori non gestiti. Quindi puoi facilmente ridimensionare con rami di funzionalità su diversi progetti esperti.

Ma come Tom ha detto molto sopra, sarebbe più bello superare la necessità di rami di funzionalità e insegnare agli sviluppatori a integrarsi in modo pulito, ma questo è un processo più lungo e il risultato non è chiaro con molte parti del sistema legacy che non toccherete più.

i miei 2 centesimi