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

Автоматическое развертывание с использованием сервера CI

В нашем проекте развертывание всегда является болью, главным образом из-за ошибок, допущенных командой управления выпуском. Либо они испортили конфигурацию, либо каким-то образом установили неправильную версию. Мы используем teamcity как наш CI-сервер, и он создает артефакты как zip файлы (dll и exe), которые обычно передаются команде release. Мой вопрос в том, есть ли способ автоматизировать весь процесс развертывания?

Есть ли коммерческий инструмент, который поддерживает это?

Мы хотим сделать следующее:

  • Обновите конфигурационные файлы со значениями, специфичными для среды.

  • Установите службы Windows на сервер.

  • Загрузите пакет UI (WPF) в централизованное местоположение (которое вытаскивается другим приложением, вроде пусковой установки).

  • Измените строки подключения DB.

Сделайте все выше для различных сред (например, int, uat и prod)

Развертывание БД, поскольку это отдельный зверь как таковой, в этом не нуждается.

Любые передовые методы, инструменты или решения будут очень полезными.

Спасибо, -Mike

4b9b3361

Ответ 1

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

  • Получить агента TeamCity, установленного на рабочем сервере
  • У сборника все получится из-под контроля источника (у вас есть все в правильном управлении?).
  • Создайте шаг сборки и опубликуйте ваше решение. Этого можно добиться, добавив следующий аргумент командной строки к вызову MSBuild:

    /p: Конфигурация = [Ваша конфигурация]; DeployOnBuild = True; PackageAsSingleFile = False

    Ваши опубликованные файлы (и преобразованные файлы конфигурации) будут записаны в следующий каталог:

    [Каталог проектов]\obj\[Ваша конфигурация]\Пакет\PackageTmp

  • Использование языка сценариев (в моем случае Powershell) для копирования опубликованных артефактов в ваш каталог развертывания и внесения изменений в конкретную среду, о которых вы упомянули. Например. извлечение архивов, копирование файлов, запуск/остановка веб-сайтов и т.д.

  • Запустите любое автоматическое тестирование (например, nUnit, Selenium и т.д.)

Я считаю, что лучшая стратегия заключается в том, чтобы иметь событие .Net post-build, которое вызывает соответствующую powershell script, передавая соответствующие данные, такие как путь решения и имя конфигурации (в качестве альтернативы, я также имел TeamCity передал имя среды для Powershell script), чтобы он знал, что ему нужно делать (например, Staging, Production и т.д.). Вы должны обнаружить, что язык сценариев, такой как Powershell, может выполнять все, что может делать человек (и примерно 100 раз быстрее и 100% надежно).

В Powershell есть так много контента, что вы можете просто сделать что-то, что вам нужно сделать в Powershell, и вы получите пример. Например. "powershell развернуть WPF", "загрузить PowerShell FTP" и т.д.

В предыдущем задании мне нужно было удаленно развертывать службы Windows, и я обнаружил, что с достаточным количеством исследований я смог получить MSI для службы, чтобы удалить существующий сервис и установить новый полностью без звука (т.е. никаких диалогов). Это поможет вам в автоматизации. Я могу подробно остановиться на этом, если вы захотите.

Ниже приведен пример сборки Poster Powershell script Обычно я использую:

Обратите внимание, как я использую некоторые значения параметров по умолчанию, чтобы я мог выполнить script непосредственно из моего редактора Powershell для имитации и тестирования различных конфигураций на моей локальной машине.

param(
    [string]$configurationName="Debug",
    [string]$sourceDirectory="C:\SVN\<Your local solution location>")
Set-StrictMode -v latest
$ErrorActionPreference = "Stop"

# Load required functions
$private:scriptFolder = & { (Split-Path $MyInvocation.ScriptName -Parent) }
. (Join-Path $scriptFolder DebugBuild.ps1)
. (Join-Path $scriptFolder StagingBuild.ps1)
. (Join-Path $scriptFolder ProductionBuild.ps1)
. (Join-Path $scriptFolder CommonBuildFunctions.ps1)

#Execute appropriate build
switch ($configurationName) {
    "Debug" { RunDebugBuild $sourceDirectory }
    "Staging" { RunStagingBuild $sourceDirectory }
    "Production" { RunReleaseBuild $sourceDirectory }
}

Чтобы выполнить публикацию на машинах разработки, я настраиваю профиль публикации VS для решения, которое привязано к SVN, чтобы другие разработчики могли его использовать. Этот профиль публикуется непосредственно в локальном каталоге развертывания.

Ответ 2

Мы используем TeamCity для наших развертываний в дополнение к CI, и он работает очень хорошо. Вот несколько вещей, которые могут помочь:

  • Если вы используете VS2010, посмотрите плагин SlowCheetah. Он может преобразовывать конфигурационные файлы, чтобы делать то, что вам нужно, чтобы заменить строки подключения DB и другие чувствительные к окружающей среде переменные. Эти преобразования происходят автоматически при создании на основе выбранной конфигурации сборки.
  • Отметьте MSDeploy. Несмотря на то, что он уделяет больше внимания развертыванию веб-приложений, он может выполнять множество других функций, например, устанавливать службы Windows и синхронизировать файлы с целевым каталогом. Хотя большинство людей устанавливают его как надстройку IIS, его можно установить как отдельную службу, которая не имеет зависимостей от IIS.

Если вы не используете VS2010 (или не хотите использовать SlowCheetah), вот как мы можем справиться с настройками конфигурации:

  • Создайте конфигурацию приложения для каждой другой среды (я предполагаю, что вы иметь конфигурацию сборки, настроенную для каждой среды). Добавить имя конфигурации до конца файла конфигурации, поэтому в Prod мы имеем App.config.Prod и QA мы имеем App.config.QA.
  • Поместите полную конфигурацию для каждой среды в соответствующий файл конфигурации для это окружающая среда.
  • Как часть вашей сборки (мы используем цель "BeforeBuild" в файле проекта), используйте msbuild для копирования экологически чистого app.config над фактическим. Здесь используется пользовательская цель msbuild:

    <PropertyGroup>
        <EnvironmentAppConfig>App.config.$(Configuration)</EnvironmentAppConfig>
    </PropertyGroup>
    
    <Target Name="ReplaceAppConfig">
        <Message    Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" 
                    Text="Copying $(EnvironmentAppConfig) -> App.config" Importance="high" />
    
        <Message    Condition="!Exists('$(ProjectDir)$(EnvironmentAppConfig)')"
                    Text="No $(EnvironmentAppConfig) found. Leaving App.config as is." Importance="high" />
    
        <Copy   SourceFiles="$(ProjectDir)$(EnvironmentAppConfig)"
                DestinationFiles="$(ProjectDir)App.config"
                Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" />
    
    </Target>
    

Сообщите мне, если вам нужны другие детали.

Ответ 3

Развертывание Teamcity + Octopus

Octopus для автоматизированных развертываний служб Windows

Ответ 4

Наша команда разработчиков использует Anthill Pro - у нее также есть возможность делать CI, но они просто используют ее для развертывания пакетов (в нашем случае в основном код веб-сайта). Самое замечательное в Anthill - это настройка клиента (агента), поэтому он с некоторыми усилиями обходит брандмауэры, NAT и т.д. И он имеет одобрение и планирование рабочего процесса.

Что касается конфигураций, это другой зверь - к сожалению, обе разработчики и команда разработчиков должны изменить их и каким-то образом слить результат. Учтите, что вы хотите добавить новый ключ конфигурации, но команда разработчиков должна добавить производственные настройки для подключения к БД. Хитрость заключается в том, что разработчики не должны знать производственную строку подключения к БД. Так что это не автоматизировано (в нашем случае так или иначе).

Ответ 5

Я неравнодушен к TeamCity, который является продуктом Jetbrains, компанией, которая делает основной ReSharper (нет, я не работаю для них, хватило удачи). TeamCity, по крайней мере в прошлый раз, когда я проверил, является бесплатным продуктом для 20 пользователей и 20 конфигураций сборки. У этого есть некоторые хорошие функции авто-сборки и вины. Отлично, действительно.

Ответ 6

Вы упомянули коммерческий инструмент...

TFS, или, в частности, Team Build, полностью поддерживает создание кода и его развертывание. Всякий раз, когда мы создаем веб-приложение, оно автоматически развертывается на наших серверах Dev и QA. После развертывания мы прошли через набор веб-тестов, чтобы обеспечить работоспособность. Тогда настоящая забава начинается с нашей команды QA;)

Хотя мы не используем автоматическое развертывание для производства, мы, конечно же, могли бы это сделать.