Каковы лучшие практики Team City для многоступенчатого развертывания? - PullRequest
29 голосов
/ 14 октября 2011

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

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

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

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

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

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

Обновление:

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

Обновление 2

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

Существуют ли способы использования Team City для какого-либо автоматизированного развертывания в промежуточных / производственных средах?

Ответы [ 3 ]

15 голосов
/ 09 ноября 2011

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


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

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

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

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

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

Это отвечает на ваш вопрос?Чего-то еще не хватает?

8 голосов
/ 31 октября 2011

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

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

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

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

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

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

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

3 голосов
/ 01 августа 2013

Думаю, вы захотите проверить что-то вроде 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 - это приятно .

...