Подтвердить что ты не робот

Внедрение Octopus из Teamcity не использует последние пакеты

Я установил шаг сборки на TeamCity, как описано здесь, чтобы выполнить развертывание автоматического выпуска на нашем тестовом сервере. Но он не использует последние пакеты nuget, которые были созданы в TeamCity.

Случай использования:

Teamcity создаст пакет nuget с версией 1.0.0.9, все DLL файлы, которые находятся в пакете, являются правильной версией, а версия в Octopus, которая была развернута, имеет тот же номер версии, но пакеты, которые использует осьминог, более раннего пакета, например 1.0.0.5.

Я указал параметр -force на этапе сборки, чтобы он использовал последние пакеты, но это не так.

Если я вручную создаю выпуск в Octopus и выбираю последние пакеты, он работает на 100%

Пожалуйста, скажите мне, если я что-то упустил.

заблаговременно

4b9b3361

Ответ 1

Я думаю, что вам нужно создать две конфигурации сборки в TeamCity, одну для сборки и одну для развертывания с Octopus. Обратитесь к этой ссылке, которая имеет небольшой рекламный ролик в конце:

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.

Итак, в моем случае я создал 2 конфигурации сборки, затем настроил зависимость моментального снимка от сборки до конфигурации развертывания, а также триггер, чтобы начать развертывание после успешной сборки.

Ответ 2

Похоже, что -force - это просто заставить пакеты переустановить, если они уже установлены. Вы используете параметр -packageversion?

Ответ 3

Моя организация использует Jenkins CI. Мы используем уникальный номер сборки в качестве нашей версии пакета, а затем развертываем эту конкретную версию пакета с помощью параметра -packageversion paramater.

В случае, когда у нас есть несколько служб, которые необходимо развернуть. У нас есть работа/основная работа, которая предоставляет уникальный номер сборки.

Я бы предположил, что вы можете сделать то же самое с TeamCity

Мастер-задание (уникальный номер сборки) вызывает задания A и задания B с параметром (уникальная сборка). Задания версии A и B (от мастер-задания). Задания A и B завершают публикацию соответствующих версий.

Ответ 4

Это может быть несколько вещей.

Отъезд.

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

Вы не упомянули, как вы потребляете фиды от Octopus в Teamcity. Я бы начал там.

Далее я использую действие teamcity для развертывания. Вы спросили: "Где должен быть добавлен флаг -waitfordeployment", есть флажок, чтобы убедиться, что развертывание работает до того, как действие может продолжаться.

Ответ 5

В TeamCity я использую шаг Octo Push Packages, а в поле Additional Parameters - параметр -defaultpackgeversion {VERSION}.

Это заставит Octo использовать определенную версию пакетов вместо того, чтобы просто выбрать "Последняя версия".

Ответ 6

Есть более возможные причины проблемы.

  • Чтобы увидеть проблемы с Octopus, перейдите к Configuration -> Diagnostics введите описание изображения здесь

  • Другой распространенной проблемой является использование имени пакета #{variable} на этапе развертывания

    В настоящее время это невозможно, и имя пакета должно быть установлено вручную, например MyWebSite или MyWindowsService. Для этой функции см. UserVoice. введите описание изображения здесь