2014-01-21 3 views
7

Мы создаем пакеты для нескольких сред развертывания с использованием сервера TeamCity и OctoPack. Проблема заключается в том, что агент щупальца выбирает последнюю версию номера пакета, поэтому это тот же самый (последний) пакет, который развертывается во всех средах. Вот краткое описание нашей установки:Как сделать развертывание Octopus выбрать версию пакета в нескольких средах?

  • Среды DEV и STAGE;
  • Развертывание до DEV запускается из ветки Git «dev»;
  • Развертывание до STAGE запускается из ветви Git «stage»;
  • OctoPack настроен для создания пакетов MyProduct.1.0.0.dev-% build_counter% для конфигурации сборки DEV;
  • OctoPack настроен на созданные пакеты MyProduct.1.0.0.% Build_counter% для конфигурации сборки STAGE;
  • TeamCity сконфигурирован для экспонирования артефактов OctoPack (пакеты NuGet) через свой канал NuGet;
  • Проект Octopus сконфигурирован для развертывания пакетов с NuGet Id MyProduct из фида TeamCity NuGet.

Так что же происходит, что с DEV строит выполняются чаще, они имеют больший% build_counter%, а ЭТАП не получает шанс получить развертывание своих собственных пакетов - Осьминог щупальца preferes пакеты с 1,0. 0.dev- * суффикс.

Это должен быть довольно распространенный сценарий, но я не нашел простой способ его решения.

+0

Я думаю, вы имеете в виду «TeamCity сконфигурирован для генерации Pacakges» и не Octopus?Некоторые другие советы: используйте разные номера версий для STAGE и DEV (и MASTER), что упростит работу в долгосрочной перспективе. Например, в нашем dev номер версии 0.0.0.x, а в master у нас 1.0.0.x. Самая правильная версия, я думаю, будет иметь dev, установленный в 2.0.0.x и master to 1.0.0.x, и когда разработчик будет готов к выпуску и объединен с мастером, увеличен до 2.0.0.x и dev до 3.0.0.x. Вы можете думать об этом, поскольку dev - это будущее, а хозяин - то, что сейчас находится в prod. –

ответ

9

Есть некоторые детали, которые не задокументированы здесь: https://github.com/OctopusDeploy/Octopus-Tools. Но если посмотреть на https://github.com/OctopusDeploy/Octopus-Tools/blob/master/source/OctopusTools/Commands/CreateReleaseCommand.cs, то можно выяснить, что вы можете сделать.

Я думаю, что инструменты имеют обратную совместимость, но не на 100% уверены в этом.

Когда вы используете инструменты octo, которые, как я ожидаю, вы используете, вы можете установить version (также называемый releasenumber), чтобы указать номер выпуска. Если вы не укажете ничего другого, это займет последний пакет, так что вы хотите установить packageversion (также называемый defaultpackageversion), который должен использоваться для выпуска.

Я думаю, что должен это сделать. Если это не так, что вы используете для создания выпуска?

Пример того, что мы используем с нашей TeamCity при использовании OCTO инструментов, которые мы добавили в путь среды на строительных агентов:

create-release --server=%conf.OctoServerApi% --project=%conf.OctoProject% --version=%env.OctopusPackageVersion% --deployto=%conf.OctoDeployEnv% --packageversion=%env.OctoPackPackageVersion% --apiKey=%conf.OctoApiKey% --waitfordeployment %conf.OctoExtraParams% 

UPDATE:

Документация 2.0 является гораздо лучше: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596

+0

Спасибо Томасу, я проверю ваши предложения и проверю, разрешает ли он нашу проблему. –

+0

Да, это сработало отлично, как вы и предполагали! –

+0

Ссылка ссылки больше не существует. – jessehouwing

3

Вдохновленный ответом Томаса Янсона, просто добавив следующее к Дополнительные аргументы командной строки в OctopusDeploy: Создать релиз сборки шага (Teamcity v9) работал для меня:

--packageversion=%build.number% 
Смежные вопросы