部署：MSI包与脚本

发布时间：2020-12-14 05:29:05 所属栏目：Windows 来源：网络整理

导读：我的任务是调查我们的部署,并了解它们可以简化的地方.现在我们有4种不同的配置(Debug / Dev,Test,Staging,Release)和4 * .config文件.我们的任务将根据活动配置使用适当的* .config预构建时间覆盖app / web.config.创建了一个MSI,我们在发布之夜对该组件进行

我的任务是调查我们的部署,并了解它们可以简化的地方.现在我们有4种不同的配置(Debug / Dev,Test,Staging,Release)和4 * .config文件.我们的任务将根据活动配置使用适当的* .config预构建时间覆盖app / web.config.创建了一个MSI,我们在发布之夜对该组件进行了全面部署.

这并不完全理想,因为如果我们在配置文件中更改某些内容,或者在特定视图中修复拼写,我们必须重新部署整个内容.不要说MSI偶尔需要重启.另一个提出的选择是创建MSI,而不是创建MSI,我们可以创建自定义部署/回滚脚本,并具有执行增量释放的能力.

这里有没有人尝试过两种方式的部署？您找到了哪些优点/缺点？有没有第三种方式我们没有想到？

编辑：只是澄清一些事情……我们不会向客户部署.所有软件都部署到我们的服务器. (一些网站,以及很多Windows服务).我们从不改变生产中的东西.我们实际上使用VS中的内置系统来创建MSI,因此该部分不是可怕的部分.对我来说,如果你不得不改变1个视图,重新部署整个网站是没有意义的.我们还必须部署到多个服务器.现在,通过在每个上运行MSI来完成.

解决方法

MSI专业人士：

>应用程序/服务/站点像大多数其他Windows应用程序一样安装和注册,并显示在“添加/删除程序”中
>一些内置支持重新安装,升级
>对安装Windows服务/ IIS站点/低级Windows功能有一些内置支持

MSI缺点：

>一旦你“陷入困境”,似乎真的很神秘
>似乎比使用自定义脚本更难定制

剧本专家：

>更容易定制,虽然某些步骤可能需要大量/神秘的脚本(使用IIS,低级计算机管理)
>不必处理MSI的低级怪异

脚本缺点：

> .bat脚本不是最易读或可写的语言. (Powershell更好,但是你必须担心Powershell是否安装在目标机器上).
>低级别操作需要大量管理脚本来执行提交/回滚行为
>没有内置支持安装或回滚(MSI内置一些支持)

我遇到的一个有助于MSI的是WiX(http://wix.sourceforge.net/),但即便是WiX在很多方面看起来都很神秘.我们使用MSBuild和WiX的组合来进行自动构建和部署/安装,它对我们来说没问题.

总的来说,我可能更倾向于在脚本上进行MSI / WiX(或其他安装工具包)部署. MSI是在Windows上进行安装的标准方式,一旦你开始工作,你通常不需要做太多改变.在将最终的MSI包放在一起之前,MSBuild或其他一些构建框架(NAnt等)可用于设置部署(重命名文件,执行字符串替换等).

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!