使用 CI 服务器自动部署答案

【问题标题】：Automated Deployment using CI server使用 CI 服务器自动部署
【发布时间】：2012-01-17 22:13:12
【问题描述】：

在我们的项目中，部署总是很痛苦，主要是因为发布管理团队犯了错误。他们要么搞砸了配置，要么以某种方式安装了错误的版本。我们使用 teamcity 作为我们的 CI 服务器，它以 zip 文件（dll 和 exe）的形式生成工件，这些文件通常传递给发布团队。我的问题是，有没有办法自动化整个部署过程？

是否有支持此功能的商业工具？

我们将要做以下事情：

使用特定于环境的值更新配置文件。
安装windows服务到服务器。
将 UI(WPF) 包上传到集中位置（由另一个应用程序下拉，类似于启动器）。
更改数据库连接字符串。

针对各种环境（如 int、uat 和 prod）执行上述所有操作

由于数据库部署本身是一个单独的野兽，因此无需在本文中介绍。

任何最佳实践、工具或解决方案都会非常有帮助。

谢谢， -迈克

【问题讨论】：

请注意，我说的不是 Web 应用程序，而是使用 WPF 构建的桌面应用程序。
有人试过章鱼吗？
我没有使用过octopusdeploy.com，但是我关注了它的进展，它肯定解决了你上面列出的问题

标签： c# wpf msbuild teamcity nant

【解决方案1】：

我已经将 TeamCity 用于一些相当大的项目，并且除了数据库之外，我已经自动化了部署的各个方面。我对每个项目使用的主要步骤是：

在生产服务器上安装 TeamCity 代理
构建是否让所有内容脱离源代码管理（您的所有内容都在源代码管理中吗？）。
有一个构建步骤来构建和发布您的解决方案。这可以通过在您的 MSBuild 调用中添加以下命令行参数来实现：

/p:Configuration=[你的配置];DeployOnBuild=True;PackageAsSingleFile=False

您发布的文件（和转换后的配置文件）将被写入以下目录：

[你的项目目录]\obj\[你的配置]\Package\PackageTmp
使用脚本语言（在我的情况下为 Powershell）将已发布的工件复制到您的部署目录并进行您提到的特定于环境的更改。例如。提取档案、复制文件、启动/停止网站等。
运行任何自动化测试（例如 nUnit、Selenium 等...）

我发现最好的策略是让 .Net 构建后事件调用适当的 powershell 脚本，传递解决方案路径和配置名称等相关详细信息（或者，我也让 TeamCity 将环境名称传递给 Powershell脚本），以便它知道它需要做什么（例如登台、生产等......）。您应该会发现，像 Powershell 这样的脚本语言可以完成人类可以完成的所有事情（并且速度提高了大约 100 倍，可靠性提高了 100%）。

Powershell 上有很多内容，您可以在 Powershell 中搜索任何您需要做的事情，然后您就会得到一个示例。例如。 “powershell 部署 WPF”、“powershell 上传 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 }
}

为了在开发机器上执行发布，我为提交给 SVN 的解决方案设置了一个 VS 发布配置文件，以便其他开发人员可以使用它。此配置文件直接发布到本地部署目录。

【讨论】：

很好的答案！感谢您抽出时间来绘制它；-) 太棒了
什么是RunDebugBuild函数？
您说要在生产服务器上放置一个构建代理，但是您如何保证该代理将是运行构建的代理？
@lorddev 我已经有一段时间没有使用 TeamCity，但我想有一些方法可以配置 TeamCity 以使用特定代理进行特定构建。
是的，我使用构建配置的代理要求部分解决了这个问题。

【解决方案2】：

除了 CI 之外，我们还使用 TeamCity 进行部署，它运行良好。以下几点可能会有所帮助：

如果您使用的是 VS2010，请查看SlowCheetah plugin。它可以执行配置文件转换，以执行您需要替换数据库连接字符串和其他环境敏感变量的操作。当您根据选定的构建配置进行构建时，这些转换会自动发生。
查看MSDeploy。虽然它主要用于部署 Web 应用程序，但它可以做很多其他事情，比如安装 Windows 服务和将文件同步到目标目录。虽然大多数人将其作为 IIS 插件安装，但它可以作为不依赖于 IIS 的单独服务安装。

如果您不使用 VS2010（或不想使用 SlowCheetah），我们可以通过以下方式处理配置设置：

为每个不同的环境创建一个应用配置（我假设你为每个环境设置构建配置）。添加配置名称到配置文件的末尾，所以在 Prod 我们有 App.config.Prod 和 QA 我们有 App.config.QA。
将每个环境的完整配置放入相应的配置文件中那种环境。

作为构建的一部分（我们在项目文件中使用“BeforeBuild”目标），使用 msbuild 将环境特定的 app.config 复制到实际的 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>

如果您需要任何其他详细信息，请告诉我。

【讨论】：

我尽量避免每个环境的 App.config 的完整副本。有很多冗余。理想情况下（显然工作量更大），最好只存储差异并使用 XPath 之类的东西将它们应用于原始 app.config。就像 .Net 4 现在对其配置转换文件所做的那样。

【解决方案3】：

Teamcity + Octopus 部署

Octopus for windows 服务自动部署

【讨论】：

【解决方案4】：

我们的发布团队使用 Anthill Pro——它也有能力做 CI，但他们只是用它来部署包（在我们的例子中主要是网站代码）。 Anthill 最酷的地方在于整个客户端（代理）-服务器设置，因此它可以通过一些努力穿越防火墙、NAT 等。它具有审批和调度工作流程。

就配置而言，这是一个不同的野兽 - 不幸的是，开发人员和发布团队都必须更改这些配置，并以某种方式合并结果。考虑到您要添加新的配置键，但发布团队必须为数据库连接添加生产设置。诀窍是开发人员不应该知道生产数据库连接字符串。所以这不是自动化的（在我们的例子中）。

【讨论】：

【解决方案5】：

我偏爱 TeamCity，它是 Jetbrains 的产品，该公司生产必不可少的 ReSharper（不，我不为他们工作，靠运气）。至少在我上次检查时，TeamCity 是一个免费产品，最多可容纳 20 个用户和 20 个构建配置。它有一些不错的自动构建和责备功能。非常棒，真的。

【讨论】：

【解决方案6】：

你提到了一个商业工具......

TFS，或者特别是 Team Build，完全支持构建代码和部署它。每当我们构建一个 Web 应用程序时，它都会自动部署到我们的开发和 QA 服务器。部署后，我们让它通过一套 Web 测试运行，以确保一切正常。然后真正的乐趣从我们的 QA 团队开始；)

虽然我们不会自动部署到生产环境，但我们当然也可以这样做。

【讨论】：