9

我们的大多数内部应用程序都使用 Ant 构建在 Java EE 堆栈上，并使用 WAR 文件部署到 Tomcat。我们有一个构建框，用于创建面向生产的 WAR，然后将 WAR 交付到测试环境。运行脚本以将部署的 webapp 转换为指向测试数据环境。

经过几个循环的测试 -> 错误修复 -> 构建 -> 重新部署以进行测试，然后将 WAR 文件部署到生产环境，然后就可以使用了。

我最近继承了一些 ASP.NET 4.0 webapps，它们的 Build/Deploy 完全不同；代码在VS中构建，然后将整个项目目录复制到各个环境中。然后手动对其进行调整，并偶尔使用服务器上的 VS 实例进行重建。

这有点吓人，因为有很多机会在一个环境中进行调整被遗忘，因此要求我们在应用程序“上线”后在测试、版本控制、等等

所以，所有这一切都在说：在 .NET 世界中是否存在与 Ant/WAR 机制等效的机制？从 .NET webapp 创建可执行工件并在环境之间以最少的修改移动它的最安全方法是什么？我知道“最佳实践”是一个禁忌短语，但在我在 .NET 中重新制作 Ant 之前，我想先了解一些专业知识。:-)

4

1 回答 1

10

自动化 Web 部署需要了解的三种技术：

  1. MSBuild - 这是微软的 ANT 等价物。项目文件基本上只是一系列 MSBuild 任务。
  2. WebDeploy - 这本质上是您的 WAR/Tomcat 等价物，除了它创建部署包，并且适用于 IIS。
  3. XML 转换- 您永远不必手动编辑配置。如果您需要部署多个环境，则配置转换是必不可少的。

将所有这些与您最喜欢的构建服务器（我使用 Jenkins）放在一起，您可以将整个部署过程完全自动化到任何环境。这些单独的主题中的每一个都过于广泛，无法在此处深入介绍，但您应该能够以最少的知识开始。

为了给你一个例子来说明它是多么简单，这里有一个示例命令行构建，它将把一个网站部署到一个 2003/IIS6 机器上。

MSBUILD "MyWebSite.csproj" 
    /p:Configuration=Dev 
    /p:OutputPath=bin 
    /t:Rebuild 
    /p:DeployOnBuild=true 
    /p:DeployTarget=MSDeployPublish 
    /P:AllowUntrustedCertificate=True 
    /p:MSDeployPublishMethod=RemoteAgent 
    /p:MsDeployServiceUrl=http://MyDevServer    
    /p:DeployIisAppPath="Default Web Site/MyWebSite" 
    /p:username=deployUser 
    /p:password=deployPassword
于 2012-08-01T15:26:11.267 回答