Piani di costruzione di bambù e piani di distribuzione per configurazioni di ambiente personalizzate

Question

Sto valutando Bamboo per sostituire la configurazione di Jenkins e fare un paio di domande. Ho una soluzione .NET che genera due artefatti: un sito Web confezionato e un MSI. Ho tre ambienti che utilizzo: test, stage, produzione. Il nostro server Jenkins a sua volta ha tre lavori, uno per ogni ambiente. Ogni lavoro crea la soluzione, copia nei file di configurazione per l'ambiente in cui verrà distribuito e quindi distribuisce le risorse. Leggendo la documentazione e altre cose (https://answers.atlassian.com/questions/19562/plans-stages-jobs-best-practices), ricevo segnali contrastanti su come la distribuzione dovrebbe funzionare con Bamboo. Mi sembra che i piani di distribuzione prevedano che esistano degli artefatti e quindi li implementiamo. Ma i piani di costruzione includono anche passaggi di distribuzione. In che modo tutto ciò dovrebbe interagire insieme?

Il motivo per cui sono confuso è perché ho file di configurazione specifici dell'ambiente che vengono impacchettati durante una compilazione. Qualche direzione su come dovrebbe funzionare?

Answer 1

ho postato la questione al consiglio Atlassian come bene e ha ottenuto an answer penso che mi piace di più:

Jason Monsorno · 762 karma · 30 agosto '13 alle 16:38

Deployment i progetti in Bamboo sembrano dipendere dall'esistenza di un artefatto, la cattura è che non è necessario utilizzare quell'artefatto in modo da poter usare un artefatto vuoto e fare completamente i passi indipendenti . I progetti di implementazione sono ancora abbastanza nuovi per Bamboo e la tua struttura potrebbe favorire il flusso di lavoro "normale", quindi ogni ambiente sarebbe una fase manuale separata.

Il progetto di distribuzione ha un flusso di lavoro e un controllo delle versioni separati. Per utilizzare i progetti di distribuzione nello scenario, suggerirei di rendere l'elemento l'intero checkout, quindi ciascun ambiente di distribuzione può creare una copia dell'oggetto. L'opzione salva-spazio/meno efficiente dovrebbe semplicemente salvare la revisione corrente in un file come artefatto e utilizzarla per controllarla e creare in ciascun ambiente di distribuzione .