Jazz SCM integrazione continua - costruzione flusso vs. spazio di lavoro?

Question

Io sono nel processo di creazione di una build di integrazione continua per un'applicazione primavera Roo utilizzando il Rational Team Concert (RTC) IDE e Jazz motore di generazione. Quando si imposta la definizione di compilazione, Build campo di lavoro della scheda controllo del codice sorgente Jazz permette la selezione di uno spazio di lavoro repository di un utente o di un ruscello.

Il RTC integrazione continua Best Practices e altre risorse Jazz costruire riferiscono costantemente di utilizzare un repository dedicato spazio di lavoro associato a un utente di build, mi porta a credere che questo è l'approccio preferito. Non sono stato in grado di trovare tutte le informazioni sulla costruzione dal flusso direttamente. flusso di nostro progetto contiene tutti i manufatti necessari per costruire, e ho testato e confermato che la costruzione continua integrazione funziona dal flusso. Non riesco a pensare ad alcuna ragione per cui avrei bisogno di creare e gestire uno spazio di lavoro specifico per questo scopo.

La mia domanda è, sto giocando con il fuoco con la costruzione direttamente fuori del torrente? Ci sono complicazioni potenziali a valle con questo approccio che io non sono a conoscenza?

Answer 1

Rispondendo alla mia domanda proprio nel caso in cui un altro utente ha così la stessa domanda in futuro.

Dopo alcuni esperimenti, ho scoperto che un inconveniente di costruire direttamente dal flusso era che ignora il "costruire solo se ci sono modifiche accettate" proprietà della scheda controllo del codice sorgente Jazz. Come risultato, si basa da un flusso può essere fatto solo a intervalli predefiniti - non è possibile configurare il build avvenire solo quando i nuovi cambiamenti sono stati impegnati per il flusso.

è necessaria una spazio di lavoro dedicato per la costruzione di accettare le modifiche apportate dal flusso e li usa per attivare una richiesta di compilazione.

Answer 2

C'è un'altra grande differenza qui. Ha a che fare con quanto la build viene fatto. Vorrei evidenziare la differenza qui.

Se si crea uno spazio di lavoro da repository di costruzione dedicata, quindi l'area di lavoro di costruzione ha già una copia di tutto il codice. Quando vengono consegnate le modifiche e la creazione è dato il via, quindi solo i file modificati (la modifica set) devono essere aggiornati e fisicamente copiati dal repository allo spazio di lavoro repository build. Dal momento che la maggior parte delle modifiche sono di piccole dimensioni, questo comporta la copia di qualsiasi parte dallo 0,1% al 2% della vostra base di codice dal repository.

Se si crea da "torrente", quindi le vostre esigenze di costruzione dello spazio di lavoro per essere creati (dovete compilare qualche parte!). Così, quando questo è stato creato, le vostre esigenze codebase intero ad essere aggiornati e fisicamente copiati dal repository allo spazio di lavoro repository build. Questo significa il recupero del 100% della vostra base di codice dal repository.

Ogni operazione di file comporta una chiamata per scoprire la risorsa necessaria, andare a prendere questa risorsa dal database che ospita il repository, e poi avere l'applicazione Jazz fornire questo file di origine attraverso la rete. Essa si traduce in un carico sul server di database, il server web, e l'application server. Quanto più si scarica in questo modo, più di un carico che si mette su questi componenti.

Ci sono alcune cose che è possibile utilizzare per ridurre al minimo questo carico sull'infrastruttura Jazz. Utilizzando proxy caching dei contenuti (utilizzando un semplice server proxy Squid) può aiutare.

Per maggiori dettagli sulle opzioni di qui, e la meriti relativi di queste opzioni, andare a leggere il mio post sul blog e whitepaper su Jazz problemi di prestazioni ( http://dtoczala.wordpress.com/2013/02/11/jazz-performance-a-guide-to- migliori prestazioni / ). Tale articolo è quasi un anno ormai, ma resta ancora valido. Si può anche guardare al Jazz Deployment Wiki ( https://jazz.net/wiki/bin / view / distribuzione / WebHome ), e controllare le sezioni sulla risoluzione dei problemi delle prestazioni e prestazioni preoccupazioni.