Я использовал TeamCity для некоторых довольно крупных проектов и автоматизировал каждый аспект развертывания, кроме базы данных. Основные шаги, которые я использую для каждого проекта:
- Установите агент TeamCity на производственном сервере
- У сборки получено все из системы контроля версий (у вас все есть в системе контроля версий?).
Создайте шаг сборки и опубликует ваше решение. Это может быть достигнуто путем добавления следующего аргумента командной строки к вашему вызову MSBuild:
/ p: конфигурация = [ваша конфигурация]; DeployOnBuild = True; PackageAsSingleFile = False
Ваши опубликованные файлы (и преобразованные файлы конфигурации) будут записаны в следующий каталог:
[Каталог вашего проекта] \ obj \ [Ваша конфигурация] \ Package \ PackageTmp
Использование языка сценариев (в моем случае Powershell) для копирования опубликованных артефактов в каталог развертывания и внесения упомянутых вами изменений в конкретной среде. Например. извлечение архивов, копирование файлов, запуск / остановка веб-сайтов и т. д.
Запускать любое автоматическое тестирование (например, nUnit, Selenium и т. Д.) *
Я считаю, что лучшая стратегия состоит в том, чтобы иметь событие .Net после сборки, которое вызывает соответствующий сценарий powershell, передающий соответствующие детали, такие как путь к решению и имя конфигурации (в качестве альтернативы, я также использовал TeamCity для передачи имени среды в Powershell сценарий), чтобы он знал, что ему нужно сделать (например, постановка, производство и т. д.). Вы должны обнаружить, что язык сценариев, такой как Powershell, может делать все , что может делать человек (и примерно в 100 раз быстрее и на 100% надежнее).
На Powershell так много контента, что вы можете просто погуглить все, что вам нужно сделать в Powershell, и вы получите пример. Например. "powershell deploy WPF", "powershell upload FTP" и т. д ...
В предыдущей работе мне нужно было удаленно развертывать службы Windows, и я обнаружил, что, проведя достаточное количество исследований, я смог получить MSI для службы, чтобы удалить существующую службу и установить новую совершенно бесшумно (т.е. нет диалогов). Это очень поможет в ваших поисках автоматизации. Я могу уточнить это, если хотите.
Ниже приведен пример сценария пост-сборки Powershell, который я обычно использую:
Обратите внимание, как я использую некоторые значения параметров по умолчанию, чтобы я мог выполнить скрипт непосредственно из моего редактора 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, чтобы другие разработчики могли его использовать. Этот профиль публикуется непосредственно в локальном каталоге развертывания.