在我们的项目中,部署总是很痛苦,主要是因为发布管理团队所犯的错误。他们搞砸了配置或以某种方式安装了错误的版本。我们使用teamcity作为我们的CI服务器,它生成工件作为zip文件(dll和exe),通常传递给发布团队。我的问题是,有没有办法自动化整个部署过程?
是否有支持此功能的商业工具?
我们希望执行以下操作:
使用特定于环境的值更新配置文件。
将Windows服务安装到服务器。
将UI(WPF)捆绑包上传到集中位置(由另一个应用程序拉下来,类似于启动器)。
更改数据库连接字符串。
针对各种环境(如int,uat和prod)执行以上所有操作
数据库部署因此是一个单独的野兽,因此不需要涉及。
任何最佳实践,工具或解决方案都将非常有用。
谢谢, -Mike
答案 0 :(得分:9)
我已经将TeamCity用于一些相当大的项目,并且除了数据库之外,我还实现了部署的各个方面。我为每个项目使用的主要步骤是:
制作构建步骤,构建发布您的解决方案。这可以通过将以下命令行参数添加到MSBuild调用来实现:
/ p:Configuration = [Your Config]; 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发布配置文件,以便其他开发人员可以使用它。此配置文件直接发布到本地部署目录。
答案 1 :(得分:3)
除了CI之外,我们还使用TeamCity进行部署,效果非常好。以下是一些可能会有所帮助的事情:
如果您没有使用VS2010(或者不想使用SlowCheetah),请按以下步骤处理配置设置:
作为构建的一部分(我们在项目文件中使用“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团队开始;)
虽然我们不会自动部署到生产环境,但我们当然也可以这样做。