使用CI服务器进行自动部署

时间:2012-01-17 22:13:13

标签: c# wpf msbuild teamcity nant

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

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

我们希望执行以下操作:

  • 使用特定于环境的值更新配置文件。

  • 将Windows服务安装到服务器。

  • 将UI(WPF)捆绑包上传到集中位置(由另一个应用程序拉下来,类似于启动器)。

  • 更改数据库连接字符串。

针对各种环境(如int,uat和prod)执行以上所有操作

数据库部署因此是一个单独的野兽,因此不需要涉及。

任何最佳实践,工具或解决方案都将非常有用。

谢谢, -Mike

6 个答案:

答案 0 :(得分:9)

我已经将TeamCity用于一些相当大的项目,并且除了数据库之外,我还实现了部署的各个方面。我为每个项目使用的主要步骤是:

  1. 获取在生产服务器上安装的TeamCity代理
  2. 让构建从源代码控制中获取所有内容(源代码控制中的所有内容都正确吗?)。
  3. 制作构建步骤,构建发布您的解决方案。这可以通过将以下命令行参数添加到MSBuild调用来实现:

    / p:Configuration = [Your Config]; DeployOnBuild = True; PackageAsSingleFile = False

    您发布的文件(以及已转换的配置文件)将写入以下目录:

    [您的项目目录] \ obj \ [您的配置] \ Package \ PackageTmp

  4. 使用脚本语言(在我的案例中为Powershell)将已发布的工件复制到您的部署目录,并进行您提到的特定于环境的更改。例如。提取档案,复制文件,启动/停止网站等。

  5. 运行任何自动化测试(例如nUnit,Selenium等......)

  6. 我发现最好的策略是使用.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发布配置文件,以便其他开发人员可以使用它。此配置文件直接发布到本地部署目录。

答案 1 :(得分:3)

除了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>
    

如果您需要任何其他详细信息,请与我们联系。

答案 2 :(得分:1)

Teamcity + Octopus deploy

Octopus for windows service自动部署

答案 3 :(得分:0)

我们的发布团队使用Anthill Pro - 它还具有执行CI的能力,但他们只是使用它来部署包(在我们的例子中主要是网站代码)。 关于Anthill的一个很酷的事情是整个客户端(代理) - 服务器设置,所以它通过一些努力遍历防火墙,NAT等。它有批准和安排工作流程。

就配置来说,这是一个不同的野兽 - 不幸的是,开发团队和发布团队都必须改变这些,并以某种方式合并结果。考虑您要添加新的配置密钥,但发布团队必须添加数据库连接的生产设置。诀窍是开发人员不应该知道生产数据库连接字符串。 所以这不是自动化的(在我们的情况下无论如何)。

答案 4 :(得分:0)

我偏爱TeamCity,这是一款Jetbrains产品,该公司制造了必不可少的ReSharper(不,我不为他们工作,祝你好运)。 TeamCity,至少在我上次检查时,是一个免费产品,最多可容纳20个用户和20个构建配置。它有一些很好的自动构建和责备功能。非常好,真的。

答案 5 :(得分:0)

你提到商业工具......

TFS,或者特别是Team Build,完全支持构建代码并进行部署。每当我们构建Web应用程序时,它都会自动部署到我们的Dev和QA服务器。部署之后,我们会通过一系列Web测试来确保一切正常。然后真正的乐趣从我们的QA团队开始;)

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