Memorizzazione della configurazione di Jenkins per più ambienti

Question

La mia azienda utilizza Jenkins come un esecutore di test di integrazione.

Abbiamo più istanze per i nostri ambienti di produzione e di staging. Il diverso ambiente richiede configurazioni Jenkins molto simili, ma presenta lievi variazioni in termini di esecuzione periodica, notifica, abilitazione del lavoro e così via.

Attualmente, archiviamo l'XML di configurazione Jenkins in Git e apportiamo modifiche per l'ambiente come parte della nostra ricetta Chef durante il ridistribuzione delle istanze.

Tuttavia, ciò significa che è molto difficile aggiornare la configurazione di un'istanza senza ridistribuirla.

Qualcuno ha un meccanismo preferito per condividere la configurazione di Jenkins tra diverse istanze applicando piccole modifiche per istanza?

Answer 1

Recentemente mi sono imbattuto nello gradle-jenkins-plugin che sostanzialmente estende lo Job DSL Plugin consentendo di mantenere le configurazioni del lavoro nel controllo del codice sorgente e applicarle a un server Jenkins tramite Gradle. In questo modo è possibile distribuire facilmente le stesse configurazioni su server diversi, con piccole modifiche utilizzando il DSL a seconda, ad es. sull'URL del server Jenkins.

In alternativa, è possibile ottenere qualcosa di simile utilizzando il nuovo Workflow Plugin.

Answer 2

Una possibilità (non mi testato) sarebbe quella di utilizzare il Jenkins Remote Access API attraverso un involucro come arangamani/jenkins_api_client (rubino)

Ciò consentirebbe updating jobs di esempio Jenkins remota, modificando solo i parametri per i quali è necessario un piccolo variazione .

Answer 3

È possibile effettuare una configfile multi-ambiente con linee come

hostA:settings.xml:key_1:value_1A 
hostB:settings.xml:key_1:value_1B 
hostC:settings.xml:key_1:value_1C 
hostD:settings.xml:key_1:value_1D 

hostA:settings.xml:key_2:value_2A 
hostB:settings.xml:key_2:value_2B 
hostC:settings.xml:key_2:value_2C 
hostD:settings.xml:key_2:value_2D 

(sopra il layout funziona quando non è necessario il: per la chiave/valore)

nello script di distribuzione che si chiama un post_configure script, che selezionerà le linee host corrette e sostituirà le chiavi nell'xml (chiavi trovate come <key>...</key>).
Il codice di post_configure può essere scritto in diverse lingue.

Esempio
Quando tutti i bersagli sono Linux, e l'avviamento e la fine-tag per ogni valore è una linea 1, vorrei usare bash e il codice di qualcosa come

grep $(hostname) multi.cfg | while IFS=: read host file key value; do 
    sed -i 's/'${key}'/'${value}'/g' ${file} 
done 

Credo che questa sia una migliore approccio piuttosto che generare diverse distribuzioni per i diversi sistemi.