Quale parte di HUDSON_HOME dovrei mettere sotto il controllo del codice sorgente?

Question

Mi piacerebbe gestire i file di configurazione di Hudson con subversion per il backup. The Hudson Wiki elenca la struttura di directory di $ HUDSON_HOME in questo modo:

HUDSON_HOME 
+- config.xml  (hudson root configuration) 
+- *.xml   (other site-wide configuration files) 
+- fingerprints (stores fingerprint records) 
+- plugins  (stores plugins) 
+- jobs 
    +- [JOBNAME]  (sub directory for each job) 
     +- config.xml  (job configuration file) 
     +- workspace  (working directory for the version control system) 
     +- latest   (symbolic link to the last successful build) 
     +- builds 
      +- [BUILD_ID]  (for each build) 
       +- build.xml  (build result summary) 
       +- log   (log file) 
       +- changelog.xml (change log) 

Ovviamente i lavori/[NOME LAVORO]/costruisce non dovrebbe andare in controllo del codice sorgente, ma config.xml è un buon candidato. Plugin e impronte digitali sono meno evidenti.

Come gestite le configurazioni Hudson?

Answer 1

Io uso un SCM per la gestione della mia configurazione Hudson. Tengo il config.xml di primo livello e il config.xml per ogni lavoro. Ho una piccola sceneggiatura che uso per recuperare i config da Hudson e commetterli/aggiungerli/eliminarli se necessario (insieme ad altri campanelli e fischietti che semplificano la gestione della configurazione).

punti

Re Rob Hruska, per la mia configurazione particolare:

• configurazioni cambiano spesso (notifiche, in particolare)
• (vedi sopra ri uno script per effettuare gli aggiornamenti)
• I DIFF cose tutto il tempo. Abbiamo più di un amministratore che può aggiornare la configurazione e queste differenze sono utili

Tutto ciò detto, ogni situazione è diversa. La gestione che faccio per le configurazioni non è (e non viene) gratuita. Un lavoro cron che chiude tutto di notte è sicuramente più economico e potrebbe anche essere sufficiente.

Answer 2

Un SCM probabilmente non è lo strumento migliore per eseguire il backup dell'area di lavoro di Hudson: sarebbe come utilizzare un Subversion per memorizzare le preferenze per un gioco o il contenuto delle tabelle del database per un'applicazione web. Oltre a ciò, non sembra necessario per i seguenti motivi:

• I file di configurazione non cambiano (o non dovrebbero) frequentemente (come il codice), quindi i backup notturni sono sufficienti.
• Quando si apportano modifiche tramite la GUI, qualcosa deve andare al sistema e fare un svn commit. Poiché questo probabilmente sarebbe un passaggio manuale, lascia spazio all'errore umano.
• Probabilmente non avrai mai bisogno di diffare le tue modifiche di configurazione, e per la sfortuna che potresti, puoi semplicemente estrarre e guardare i backup appropriati (vedi sotto).

Tutto sommato, sembrerebbe un po 'ingombrante usare Subversion per questo compito. Per il backup, ti consiglio di configurare un processo cron che faccia un tar cvzf $HUDSON_HOME. Puoi opzionalmente omettere le directory di compilazione, ma ciò sembra un po 'inutile se hai abbastanza spazio sul disco.

Edit: Per quanto riguarda le differenze tra questo e oeuftete's answer, la mia risposta è semplicemente dalle mie esperienze con il modo che uso Hudson. La sua risposta fornisce sicuramente una prospettiva diversa, che è carina. Sono assolutamente d'accordo sul fatto che ogni situazione è diversa e potrebbe richiedere diversi mezzi per soddisfare un fine.

Answer 3

Ho trovato un buon libro di cucina per la creazione di backup SVN per Hudson: http://javaadventure.blogspot.com/2010/07/keeping-hudson-configuration-and-data.html

ho adattato per le mie esigenze, ma le cose che si dovrebbero backup dalla home directory Hudson sono:

• config.xml per ogni lavoro (posti di lavoro/*/config.xml)
• tutto nella directory utenti
• un elenco di ciò che è stato installato plugin

Il collegamento ha anche una certa bontà SVN in più, come la rimozione di configurazioni di posti di lavoro inesistenti, ecc