Автоматического развертывания через сервер CI

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

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

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

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

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

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

  • изменить строки подключения к БД.

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

развертывание DB, так как это отдельный зверь как таковой, не должно быть покрыто этим.

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

спасибо, - Майк!--1-->

12
c# msbuild nant teamcity wpf

6 ответов

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

  1. установите агент TeamCity на рабочем сервере
  2. у сборки есть все из системы управления версиями (у вас есть все в системе управления версиями?).

  3. есть шаг сборки, который строит и опубликовывает ваше решение. Это может быть добавить следующий аргумент командной строке вызова MSBuild:

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

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

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

  4. использование языка сценариев (в моем случае Powershell) для копирования опубликованных артефактов в развертывание каталог и внести изменения в среду, о которых вы упомянули. Е. Г. самораспаковывающийся архив, копирование файлов, запуск/остановка сайты и т. д..

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

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

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

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

Ниже приведен пример сценария сборки Powershell post, который я обычно использую:

Примечание. как я использую некоторые значения параметров по умолчанию, чтобы выполнить сценарий непосредственно из редактора 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, чтобы другие разработчики могли его использовать. Этот профиль публикуется непосредственно в локальном каталоге развертывания.

9

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

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

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

  • создайте конфигурацию приложения для каждой другой среды (я предполагаю, что вы настройте конфигурацию сборки для каждой среды). Добавить имя конфигурации до конца файла конфигурации, поэтому в Prod мы имеем Приложение.конфиг.Prod и QA у нас есть приложение.config.QA.
  • поместите полную конфигурацию для каждой среды в соответствующий файл конфигурации для эта среда.

  • как часть вашей сборки (мы используем цель "BeforeBuild" в файл проекта), используйте msbuild для копирования экологически конкретного приложения.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 deploy

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

1

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

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

0

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

0

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

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

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

0