Deployment 部署：MSI包与脚本

我的任务是调查我们的部署情况，看看哪里可以简化部署。现在我们有4个不同的配置（调试/开发、测试、暂存、发布）和4个*.config文件。我们有一个任务，该任务将根据活动配置使用适当的*.config预构建时间覆盖app/web.config。创建了一个MSI，我们在发布之夜对组件进行了全面部署

这并不完全理想，因为如果我们更改配置文件中的某些内容，或者修复特定视图中的拼写，我们必须重新部署整个内容。不知道MSI偶尔需要重新启动。提出的另一个选项是，我们可以创建自定义部署/回滚脚本，并能够执行增量发布，而不是创建MSI

这里有人试过两种方法吗？你发现了哪些优点/缺点？还有第三条路我们没想到吗

编辑：仅澄清几件事……我们不向客户部署。所有软件都部署到我们的服务器上。（一些网站和许多windows服务）。我们从不改变生产中的事情。实际上，我们使用VS中的内置系统来创建MSI，所以这部分并不是最糟糕的部分。对我来说，如果你不得不改变一个视图，重新部署整个网站是没有意义的。我们还必须部署到多个服务器。现在，这是通过在每台计算机上运行MSI来完成的。

MSI pros:

• 应用程序/服务/站点与大多数其他Windows应用程序一样安装和注册，并显示在添加/删除程序中
• 一些内置的对重新安装、升级的支持
• 对安装Windows服务/IIS站点/较低级别的Windows功能具有一些内置支持

MSI缺点：

• 一旦你被“蒙在鼓里”就显得很神秘
• 似乎比使用自定义脚本更难自定义

脚本优点：

• 更易于自定义，尽管某些步骤可能需要大量/神秘的脚本（使用IIS，较低级别的计算机管理）
• 不必处理MSI的低级古怪

脚本缺点：

• .bat脚本不是最可读写的语言。（Powershell更好，但您必须担心目标计算机上是否安装了Powershell）
• 低级操作需要大量的提交/回滚行为管理脚本
• 没有安装或回滚的内置支持（MSI有一些内置支持）

我遇到的一件有助于MSIs的事情是WiX（），但即使是WiX在很多方面看起来也相当神秘。我们使用MSBuild和WiX的组合来进行自动构建和部署/安装，它对我们来说运行正常

---

总的来说，我可能更倾向于通过脚本进行MSI/WiX（或其他安装工具工具包）部署。MSI是在Windows上进行安装的标准方式，一旦它正常工作，通常不需要做太多更改。MSBuild或其他一些构建框架（NAnt等）对于设置部署（重命名文件、替换字符串等）非常有用，然后再组装最终的MSI包。

运行一家开发公司，开发web应用已经五年了，我们为此进行了努力，并尝试了一系列解决方案。以下是一些提示：

• 始终用代码替换整个web目录（除非您有网站生成的内容，如CMS）。这样做的速度非常快，如果文件不存在，增量部署可能会引入虚拟bug
• 让您的构建过程（Nant、MSBuild等）为每个环境修改.config文件，并为您所推动的内容进行构建。或者，您可以使用注册表设置，使.config文件相同，但这意味着每个环境都有一台专用计算机。可能是问题，也可能不是问题
• 不要在生产中做出改变。如果您需要进行更改（站点上的拼写错误），请将这些更改放在最优先的位置，以便在dev中进行更改，这样您就不会在下一次推送时覆盖它们
• 如果您没有使用MSI，那么请确保您有一个回滚过程。在你改变网站之前保留一份副本，当一些无法解释的东西在推广过程中横行时，这真的很有帮助

我不知道这些提示指向MSI或脚本。我想这是你最满意的事情。MSI很难定制，但很容易运行和管理。微软有很多工具来管理MSI在整个组织或农场的推出。脚本可能需要定制工具和定制工具，或者在生产端进行大量手动工作

---

我们使用Nant和自定义部署工具运行脚本。现在（VS2008）构建部署包要容易得多。

你最好的选择是找一个像样的MSI构建器来完成这项工作-我说的是InstallShield等（有几个，所以一定要四处看看）。虽然这些都是成本，但它们可以为你节省大量的时间/金钱/痛苦。话虽如此，疼痛并没有完全消除，只是减轻了：）

您需要做的任何棘手的事情都可以作为msi中的自定义任务来完成，甚至可以使用Visual Studio附带的安装生成器（如果您使用的是VS）来完成

我对您的配置文件有一个建议-将所有四个文件都包含在msi中，然后使用一个可以从命令行设置的公共属性。然后可以修改该公共属性以安装相应的配置文件（并设置该属性的默认值，以便安装发布配置）。这样，您的客户只需使用msi并获得正确的配置文件，但是您的测试团队可以通过更改公共属性的值来获得他们的配置文件；他们将使用以下命令行进行安装：

msiexec /i "MyInstaller.msi" CONFIG=test

您完全可以安装脚本