Моя команда использует TeamCity для непрерывной интеграции. Он будет создавать, тестировать и развертывать веб-приложения через Веб-развертывание на веб-серверы dev и qa. Сложная часть - это развертывание на производственном веб-сервере - наша политика требует, чтобы разработчики не могли развертывать на рабочем сервере, это может сделать только системный администратор.
Наш текущий подход заключается в том, чтобы TeamCity создала пакет веб-развертывания, который администратор может загрузить и установить на рабочий веб-сервер. Однако мы хотели бы позволить им просто щелкнуть «Выполнить» в конфигурации сборки, но мы не знаем, как защитить эту кнопку.
Мы могли бы создать проект TeamCity, к которому имеют доступ только администраторы, но мы также должны решить проблему безопасности веб-развертывания. Служба веб-развертывания должна быть аутентифицирована с помощью локальной учетной записи администратора на рабочем сервере. Мы не хотим, чтобы разработчики имели доступ к имени пользователя и паролю в сценарии сборки, и мы не хотим, чтобы каждый агент сборки работал под этой учетной записью, поскольку разработчики могут создавать сборку, которая использует ее для развертывания в производственной среде.
Мне не очень повезло с поиском ресурсов по передовым методикам безопасности / развертывания TeamCity, но я не могу представить, что мы единственная компания в этой ситуации. Как другие управляют безопасностью автоматического развертывания?
Используя роли и разрешения в Teamcity у вас может быть проект, доступ к которому имеет только ваша команда развертывания. Это может иметь зависимость артефакта в основной сборке, и вы даже можете использовать «последнюю закрепленную сборку», чтобы разработчики могли контролировать, что даже доступно.
Я бы установил агент сборки, который можно развернуть в целевой системе (ах), а затем использовать "совместимые сборки" функция этого агента в пользовательском интерфейсе TeamCity, чтобы он был совместим только с вашей производственной сборкой развертывания. (Конечно, вы также захотите убедиться, что у ваших разработчиков нет разрешений на изменение конфигурации агента.)
Это один из недостатков Teamcity с использованием параметров конфигурации, совместимых с агентом: если вы оставите свой Другой Если агент (ы) сборки совместим со всеми сборками, то можно будет предпринять производственное развертывание с одной из них, если это бесплатно. Единственный обходной путь, о котором я знаю, - это настроить их всех на запуск только «указанных сборок» и добавить все другие сборки к другому агенту (агентам). Боль в том, что если вы добавите новую сборку, она не сможет нигде работать, пока вы специально не добавите ее как совместимую.
Есть еще пара способов ограничить сборку запуском только на определенных агентах, используя Требования к агенту в конфигурации сборки.
Один из них - добавить требование, чтобы teamcity.agent.name равно имени агента, на котором он должен работать. (или, наоборот, не равно тому, на котором вы не хотите, чтобы он работал).
Другой - добавить требование для переменной среды (существует или с определенным значением), а затем установить эту переменную среды только для агента (ов), который вы хотите запустить эту сборку.
Другое возможное решение - иметь две установки Teamcity, поскольку фактически у вас есть два разных набора пользователей. Очевидно, вы не можете использовать зависимость артефактов, но вы всегда можете получить доступ к последним артефактам данной сборки, используя URL-адрес, например: * http://teamcity.server/repository/download/bt41/latest.lastSuccessful/setupfile.exe
где:
bt41 - это идентификатор сборки в Teamcity (вы можете найти его в URL-адресе при переходе к любой сборке)latest.lastSuccessful так же может быть lastest.lastPinned, `latest.lastFinished, или точный номер сборкиsetupfile.exe - это файл, который вы хотите получить из вывода артефактов (это также может быть путь, если он не опубликован на верхнем уровне)Для обеспечения безопасности процесса веб-развертывания, если вы находитесь в домене, вы можете настроить веб-развертывание для принятия проверки подлинности Windows, а затем запустить агент сборки teamcity от имени пользователя домена, имеющего разрешение на развертывание в IIS. У меня все настроено таким образом, и вам не нужны никакие пароли в сценарии веб-развертывания.
Настройка аутентификации Windows для веб-развертывания: http://blogs.iis.net/carlosag/archive/2011/12/13/using-windows-authentication-with-web-deploy-and-wmsvc.aspx