Каковы наилучшие методы Team City для многоэтапного развертывания?

У нас есть 3 среды:

Разработка: Команда Team развертывается здесь, чтобы Subversion фиксировалась на соединительной линии.
Стадия: Принятие пользователя выполняется здесь, в сборках, которые являются кандидатами на выпуск.
Производство: Когда UAT передан, здесь развертывается набор кода передачи.

Мы используем Team City и имеем только настройку непрерывной интеграции с нашей средой разработки. Я не хочу сохранять артефакты для каждого развертывания разработки, которое Team City делает. Я хочу, чтобы назначенное лицо смогло запустить конфигурацию сборки, которая будет развертывать определенное успешное развертывание разработки на нашем промежуточном сервере.

Затем я хочу, чтобы каждое промежуточное развертывание сохраняло артефакты. Когда промежуточное развертывание проходит UAT, я хочу развернуть этот пакет в Production.

Я не уверен, как установить это в Team City. Я использую версию 6.5.4, и я знаю, что есть действие "Продвигать..." /триггер, но я думаю, что это зависит от сохраненных артефактов. Я не хочу сохранять развертывания разработки каждый раз в качестве артефактов, но я хочу, чтобы человек, выполняющий промежуточное развертывание, мог указать, какое успешное развертывание развертывания развертывать для постановки.

Я знаю, что может быть несколько способов сделать это, есть ли лучшая практика? Какова ваша настройка и почему вы ее рекомендуете?

Update:

У меня есть один ответ до сих пор, и это идея, которую мы рассмотрели внутри. Мне бы очень хотелось узнать, есть ли у кого-то несколько автоматизированный способ для развертывания в промежуточной/производственной среде через Team City, где только люди с определенной ролью/разрешением могут запускать развертывание script для производства, а не иметь дело вручную с любым пакетом артефактов. Кто-нибудь?

Обновление 2

У меня все еще есть 1 день, чтобы наградить щедростью, и я подумал, что ответ ниже не ответил на мой вопрос, но, перечитав его, я вижу, что мой вопрос был не таким, каким я думал.

Можно ли использовать Team City для какого-то автоматического развертывания в средах Staging/Production?

Ответ 1

Думаю, вы на самом деле задаете здесь два разных вопроса: один - об управлении правами доступа к сборкам TeamCity, а другой касается логистики управления артефактами.

Что касается прав доступа, я предполагаю, что вы подразумеваете под "только люди с определенной ролью/разрешением могут запускать развертывание script для производства", и ваш ответ на Julien заключается в том, что вы, вероятно, не хотите, чтобы разработчики были непосредственно направлены на производство, но вы хотите, чтобы они могли видеть другие сборки в проекте. Возможно, это также похоже на сценарий Жюльена, когда ИТ-процесс переходит в автономный режим от TeamCity (либо это, либо только ИТ-специалисты, которые делают то, что делают ИТ, и настаивают на том, что они должны использовать отдельный, полностью неэффективный процесс, потому что "это так, как мы это делаем" - Не заставляй меня начинать с этого!)

Проблема заключается в том, что все разрешения в TeamCity применяются к проекту и никогда не создаются, поэтому, если у вас есть один проект со всеми вашими сборками, нет возможности применять гранулярность разрешений для создания по сравнению с производственными сборками. Ранее я рассматривал это двумя способами:

Обращайтесь с ней в социальном плане. Все знают, каковы их обязанности, и вы не запускаете то, что вы не собираетесь запускать. Если вы это сделаете, он будет проверен и прослежен до ВАС. Работайте хорошо, когда есть зрелость, четкое представление об ответственности, а не требование соблюдения, которое запрещает его.
Создайте отдельные проекты. Мне не нравится это делать, но это устраняет проблему. Вы по-прежнему можете использовать артефакты из другого проекта и означать, что вы просто получаете один проект, содержащий сборки, которые развертываются в средах, которые вам нравятся, для всех разработчиков для доступа, а другой проект - в чувствительных средах. Недостатком является то, что если сборка сборки завершится неудачей, те люди, которых вы, вероятно, хотите получить, не смогут получить к ней!

Что касается управления артефактами, нет никаких проблем с их сохранением в сборке разработки, просто определите политику очистки, которая сохраняет артефакты только из последних сборников X, если вы беспокоитесь о емкости. Многим людям требуется уверенность в том, что они разворачивают один и тот же скомпилированный вывод в каждую среду, что означает, когда вы его создаете, вы хотите сохранить его для дальнейшего использования.

После того, как у вас есть эти артефакты из вашего развертывания dev, вы можете повторно развернуть их в другие среды через отдельные сборки. У вас будет проблема с конфигурационными преобразованиями (если вы их используете), но прочитайте эту 2 часть серии для некоторых идей о как обращаться с этим (я еще не понял его подробно, но я считаю, что он на правильном пути).

Отвечает ли это на ваш вопрос? Что-то еще не хватает?

Ответ 2

Мы также использовали TeamCity в качестве нашего сервера сборки, поэтому позвольте мне объяснить нашу настройку. У нас есть 4 среды

Разработка, используемая Dev для проверки фиксации в серверной среде
QA для целей тестирования
Постановка для проверок развертывания и некоторых UAT
Продукция

Мы используем TeamCity только для развертывания в разработке (Nightly builds) и QA (по запросу). В сборке Dev используется ветвь соединительной линии, а построение QA использует другую ветвь, используемую для RC.

Развертывание на стадии постановки и производства управляется командой ИТ и поэтому не автоматизировано.

Вместо этого мы используем TeamCity для создания артефактов из сборки QA. Артефактами являются комплекты развертывания, отправленные для развертывания Staging/Production.

Тем не менее, я не уверен, что TeamCity предоставит вам полный контроль над тем, какую сборку можно продвигать в какую среду. Мы в основном контролируем это на стороне SVN ветвями и имеем разные сборки для этих ветвей. Вы могли бы (должны) уметь управлять этим так же. Поэтому вы можете обеспечить развертывание.

Я понимаю, что ваши потребности могут немного отличаться от наших, но я надеюсь, что это поможет вам найти наилучшую настройку.

Ответ 3

Я думаю, вы можете проверить что-то вроде Octopus Deploy или BuildMaster. Они обеспечивают хорошую структуру для методов развертывания, которые вы пытаетесь автоматизировать. Оба инструмента хорошо сочетаются с TeamCity.

В принципе, вы продолжаете использовать TeamCity для CI, и вы также можете продолжить развертывание в своей среде разработки с помощью TeamCity, но вы бы использовали один из инструментов развертывания для продвижения (существующей) сборки для создания и производство.

Изменить 2014-02-05 - Обновить

Создатели BuildMaster имеют новую функцию развертывания - ProGet Deploy - для своего серверного инструмента NuGet ProGet. Он очень похож на Octopus Deploy, но я еще не играл с ним, поэтому Octopus может лучше визуализировать, какие версии были развернуты в каких средах; Из-за этой важной функции я все еще использую BuildMaster.

Кроме того, я использую как TeamCity, BuildMaster, так и ProGet, и я никогда не хочу возвращаться к автоматическим сборкам. В настоящее время все мои приложения создаются и развертываются через BuildMaster. Все мои проекты библиотеки построены в TeamCity и развернуты в ProGet. Возможность управлять моими внутренними зависимостями через инфраструктуру NuGet хороша.