Quali sono le best practice di Team City per la distribuzione multistadio?

Question

abbiamo 3 ambienti:

• Sviluppo: Squadra Città dispiega qui per Subversion commit sul tronco.
• Messa in scena: L'accettazione utente viene eseguita qui, su build che sono candidati al rilascio.
• Produzione: Quando passa UAT, il set di codici che passano viene distribuito qui.

Usiamo Team City e abbiamo solo l'installazione di Continuous Integration con il nostro ambiente di sviluppo. Non voglio salvare artefatti per ogni distribuzione di sviluppo che Team City fa. Voglio che una persona assegnata sia in grado di attivare una configurazione di build che distribuirà una certa implementazione di sviluppo di successo sul nostro server di staging.

Quindi, voglio che ogni implementazione della staging salvi gli artefatti. Quando una distribuzione di gestione temporanea passa a UAT, desidero distribuire il pacchetto in produzione.

Non sono sicuro di come configurarlo in Team City. Sto usando la versione 6.5.4 e sono consapevole che esiste un'azione/innesco "Promuovi ...", ma penso che dipenda da artefatti salvati. Non voglio salvare le distribuzioni di sviluppo ogni volta come artefatto, ma voglio che la persona che esegue la distribuzione di gestione temporanea sia in grado di specificare quale implementazione di sviluppo di successo distribuire in staging.

Sono consapevole che potrebbero esserci diversi modi per farlo, esiste una procedura ottimale? Qual è il tuo setup e perché lo raccomandi?

Aggiornamento:

ho una risposta fino ad ora, ed è un'idea che avevamo considerato internamente. Mi piacerebbe davvero sapere se qualcuno ha un modo un po 'automatizzato per la distribuzione in un ambiente di produzione/staging tramite Team City stesso, dove solo le persone con determinati ruoli/permessi possono eseguire uno script di distribuzione per la produzione piuttosto che dover gestire manualmente qualsiasi tipo di pacchetto artefatto. Chiunque?

Update 2

ho ancora 1 giorno a premio di taglie, e ho pensato che la risposta qui sotto non ha risposto alla mia domanda, ma dopo rileggendolo mi accorgo che la mia domanda non era quello che ho pensato che era.

Esistono modi per utilizzare Team City per qualche tipo di distribuzione automatica negli ambienti di Staging/Produzione?

Answer 1

Penso che in realtà stai facendo due domande diverse qui; uno riguarda il controllo dei diritti di accesso alle build di TeamCity e un altro riguarda la logistica della gestione degli artefatti.

---

permessi Per quanto riguarda, io presuppongono che cosa si intende per "solo le persone con certo ruolo/autorizzazione può eseguire uno script deploy di produzione" e la vostra risposta a Julien è che probabilmente non si vuole sviluppatori la distribuzione diretta alla produzione ma tu do vuoi che siano in grado di vedere altre build nel progetto. Questo è probabilmente anche simile allo scenario di Julien quando l'IT prende il processo "offline" da TeamCity (o è solo IT a fare quello che fa l'IT e insiste sul fatto che devono usare un processo separato, completamente inefficiente perché "è solo il modo in cui lo facciamo "- non mi ha iniziato su questo)

il problema è semplicemente che tutte le autorizzazioni in TeamCity vengono applicate nei confronti del progetto di e mai l'accumulo quindi se hai un progetto con tutta la tua costruisce! , non è possibile applicare la granularità delle autorizzazioni a versioni di sviluppo rispetto a quelle di produzione. Ho già affrontato questo in due modi:

1. Gestirlo socialmente. Tutti sanno quali sono le loro responsabilità e non si esegue ciò che non si intende eseguire. Se lo fai, è verificato e rintracciabile a TE. Funziona bene quando c'è la maturità, una chiara idea di responsabilità e non il requisito di conformità che lo proibisce.
2. Creare progetti separati. Non mi piace doverlo fare ma è risolvere il problema. È ancora possibile utilizzare le risorse di un altro progetto e significa che si finisce semplicemente con un progetto contenente build che si distribuiscono in ambienti che sono felici per tutti gli sviluppatori di accedere e un altro progetto in ambienti sensibili. Il rovescio della medaglia è che se la build di produzione fallisce, le persone che probabilmente vorrai ricevere non saranno in grado di accedervi!

---

Per quanto riguarda la gestione del manufatto, non c'è nessun problema con questi mantenendo nella build di sviluppo, basta definire una politica di clean-up che mantiene solo artefatti dall'ultimo X costruisce se siete preoccupati per la capacità. Un sacco di gente vuole certezza che stia distribuendo lo stesso output compilato in ogni ambiente, il che significa che una volta che lo si costruisce, si vuole tenerlo in giro per un uso successivo.

Una volta ottenuti questi artefatti dalla distribuzione di sviluppo, è possibile ridistribuirli negli altri ambienti tramite build separati.Avrai un problema con le trasformazioni di config (presumendo che tu le stia usando), ma hai una lettura di this 2 part series per alcune idee su come affrontarlo (devo ancora assorbirlo nei dettagli ma credo che sia sulla strada giusta).

Questo risponde alla tua domanda? C'è ancora qualcosa che manca?

Answer 2

Abbiamo anche utilizzato TeamCity come server di generazione, quindi lasciatemi spiegare la nostra configurazione. Abbiamo 4 ambienti

• sviluppo utilizzato da Dev per verificare impegna in un ambiente server
• QA a scopo di test
• Messa in scena per i controlli di distribuzione e alcuni SVS
• produzione

Noi utilizzare TeamCity solo per la distribuzione in Sviluppo (build notturne) e QA (su richiesta). La build di Dev utilizza il ramo di linea e la compilazione di QA utilizza un ramo diverso usato per RC.

La distribuzione in staging e produzione è gestita dal team IT e pertanto non è automatizzata.

Quello che facciamo invece è che usiamo TeamCity per produrre artefatti dal build del QA. Gli artefatti sono i kit di distribuzione inviati per le distribuzioni di Staging/Produzione.

Detto questo, non sono sicuro che TeamCity possa fornire un controllo completo su quale build può essere promossa in quale ambiente. Fondamentalmente lo controlliamo sul lato SVN con i rami e abbiamo diverse build per quei rami. Potresti (dovresti) essere in grado di gestirlo allo stesso modo. È quindi possibile garantire ciò che viene distribuito.

Capisco che le vostre esigenze potrebbero essere leggermente diverse dalle nostre, ma spero che questo vi aiuti a trovare la migliore configurazione.

Answer 3

Penso che potresti voler controllare qualcosa come Octopus Deploy o BuildMaster. Forniscono una buona struttura per le pratiche di implementazione che stai tentando di automatizzare. Entrambi gli strumenti si integrano perfettamente con TeamCity.

Fondamentalmente, continuerai a utilizzare TeamCity per l'elemento della configurazione e potresti anche continuare a distribuire nel tuo ambiente di sviluppo con TeamCity, ma utilizzerai uno degli strumenti di distribuzione per promuovere una build (esistente) alla gestione temporanea e produzione.

Modifica 2014/02/05 - Aggiornamento

I creatori di BuildMaster hanno una nuova funzionalità di distribuzione - ProGet Deploy - per il loro strumento di server NuGet, ProGet. È molto simile a Octopus Deploy, che non ho ancora giocato con me, quindi Octopus può avere una visualizzazione migliore di quali versioni sono state distribuite in quali ambienti; Uso ancora BuildMaster a causa di questa importante funzionalità.

Inoltre, attualmente sto utilizzando TeamCity, BuildMaster e ProGet e non voglio mai tornare a non avere build automatizzati. Attualmente, tutte le mie app sono costruite e distribuite tramite BuildMaster. Tutti i miei progetti di libreria sono costruiti in TeamCity e distribuiti su ProGet. Essere in grado di gestire le mie dipendenze interne tramite l'infrastruttura NuGet è nice.