Implementazione di Octopus da Teamcity che non utilizza i pacchetti più recenti

Question

Ho configurato un passaggio di build su TeamCity, come descritto in here, per eseguire distribuzioni di rilascio automatico sul nostro server di prova. Ma non sta usando gli ultimi pacchetti di nuget che sono stati creati in TeamCity.

caso d'uso:

TeamCity creerà NuGet pacchetto con la versione 1.0.0.9, tutte le DLL che è nel pacchetto è la versione corretta, e il rilascio di Octopus, che è stato distribuito ha avuto la stessa numero di versione, ma i pacchetti utilizzati da octopus appartengono a un pacchetto precedente, ad esempio 1.0.0.5.

Ho specificato il parametro --force nel passaggio di generazione in modo che utilizzi i pacchetti più recenti ma non lo è.

Se ho creare manualmente un rilascio di Octopus, e selezionare gli ultimi pacchetti si sta lavorando al 100%

favore qualcuno può dirmi se mi manca qualcosa.

grazie in anticipo

Answer 1

Penso che quello che devi fare è creare due configurazioni di build in TeamCity, una da compilare e una da distribuire con Octopus. Fare riferimento a this link che ha un piccolo trafiletto verso la fine:

Note that NuGet packages created from your build won't appear in TeamCity until after the build completes. This means you'll usually need to configure a secondary build configuration, and use a snapshot dependency and build trigger in TeamCity to run the deployment build configuration after the first build configuration completes.

Così nel mio caso ho creato 2 configurazioni di build, quindi impostare una dipendenza snapshot dal build per la configurazione implementare e anche un trigger per dare il via la distribuzione dopo una build di successo.

Answer 2

Esso si presenta come --force è solo per forzare pacchetti al essere reinstallato se sono già stati installati. Stai usando il parametro --packageversion?

Answer 3

La mia organizzazione utilizza Jenkins CI. Usiamo il numero di build univoco come la nostra versione del pacchetto e quindi implementiamo quella specifica versione del pacchetto usando il parametro --packageversion.

Nel caso in cui abbiamo più servizi che devono essere schierato. Abbiamo un lavoro upstream/lavoro principale che fornisce il numero di build univoco.

mi immagino che si può fare la stessa cosa con TeamCity

Maestro lavoro (numero di build univoco) chiama posti di lavoro A e B di posti di lavoro con il parametro (costruzione unica). Lavori versione build A e B (da Master Job). I lavori A e B completi quindi pubblicano le rispettive versioni.

Answer 4

Potrebbe essere alcune cose.

Check out.

http://octopusdeploy.com/documentation/integration/teamcity

Non hai menzionato come il vostro consumare i feed da Octopus in TeamCity. Vorrei iniziare da lì.

Avanti vorrei utilizzare l'azione TeamCity per fare la tua deploy. Hai chiesto "Dove deve essere aggiunto il flag --waitfordeployment"? C'è una casella di controllo per assicurarsi che la distribuzione abbia funzionato prima che l'azione possa continuare.

Answer 5

In TeamCity utilizzo un passo Pacchetti Octo Push e nel campo Parametri aggiuntivi specificano il parametro --defaultpackgeversion {VERSION}.

Questo obbligherà Octo a utilizzare una versione specifica di pacchetti invece di scegliere semplicemente "Ultima versione".

Answer 6

Ci sono altre possibili ragioni per il problema.

1. Per vedere i problemi con Octopus vanno a Configuration -> Diagnostics

2. Un altro problema comune è quello di utilizzare un nome pacchetto#{variable} in una fase di deploy

   Al momento non è possibile e Nome pacchetto deve essere impostato manualmente, ad esempio MyWebSite o MyWindowsService. Vedere UserVoice per questa funzione.