对 MSDeploy 的看法
你知道，微软的下一个“大”和“企业”产品。
是只有我这样，还是人类真的很难？主要亮点是（IMO）：
- 绝对神秘的语法（
-skip:objectName=filePath,absolutePath=App_Offline.*只是为了跳过App_Offline.html） - 表现为事后思考
- 缺乏完整的文档
- 没有提及可扩展性（除了几篇博客文章）。此外，所有这些费尽心思开发的扩展都必须在 GAC 和注册表中注册
- Waaay 级别太低（元数据/metakey；所有这些 IIS 爵士乐）
- 没有与 MSBuild
集成 授予，MSDeploy 和 MSDeployAgent 相当功能强大，但是对于相对简单的任务来说，它们真的需要那么复杂吗？
You know, the next "big" and "enterprisey" thing from Microsoft.
Is it just me, or is it really hardly for humans? Main highlights are (IMO):
- Absolutely cryptic syntax (
-skip:objectName=filePath,absolutePath=App_Offline.*just for skippingApp_Offline.html) - Manifest as an after thought
- Lack of thorough documentation
- Not a word about extensibility (except for several blog posts out there). Moreover, all these extensions developed in great pains have to be registered in GAC and registry
- Waaay too low-level (metadata/metakey; all this IIS jazz)
- No integration with MSBuild
Granted, MSDeploy and MSDeployAgent are quite powerful, but do they really need to be that complex for relatively simple tasks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我也和您一样，对缺乏文档以及该工具明显的低级性质感到沮丧。
然而，MS 所做的最终是创建一个免费工具，您可以使用它实际编写整个服务器部署的脚本，包括参数化地址、配置等。不幸的是，这是一件非常复杂的事情 - 考虑到实际有多少位配置进入 Web 服务器- 这可能是完成这一切的最好方法。
我们现在需要的是一个非常好的 GUI，可以帮助构建这些包和脚本等。嵌入 IIS 中的 GUI 很好 - 但同样，解释很短 - 所以希望很快就能解决这个问题。
在功能方面，我目前正在使用 dev -> 部署站点。分期->使用参数来更改绑定的 IP 地址等。我非常沮丧，因为我花了几天时间才使其全部正常工作 - 但现在我有了它，我可以消除许多可能出现的人为错误IT 支持方 - 负责我们的部署。我现在只需担心主登台服务器的配置 - 并且可以确保每次部署时网络场中的所有服务器都将保持同步。
正如 Sayed 提到的，2010 年有 MSBuild 任务（网站部署功能现在使用 msdeploy 实现）来处理此问题 - 这也为 VSTeamSystem 带来了真正的持续集成环境的可能性 - 拥有一个实际上可以执行完整的 Web 部署，因为最后一步非常令人兴奋（当然也很可怕！）。
I too share your frustrations over the lack of documentation and the apparent low-level nature of this tool.
However what MS has done is finally create a free tool with which you can actually script whole server deployments, including parameterising addresses, configurations etc. This is unfortunately a very complicated thing to do - given how many bits of configuration actually go into a web server - and this is probably the best way to do it all.
What we need now is a really good GUI that can help build up these packages, and scripts etc. The GUI that is embedded within IIS is good - but again, short on explanation - so hopefully soon that'll be addressed.
On the functional side, I'm using at the moment to deploy a site from dev -> staging -> live with parameters to change bound IP addresses etc. I was deeply frustrated that it took me a few days to get it all working - however now I have it, I can remove a lot of the possibly of human error at the IT Support side - who are responsible for our deployments. I now only have the configuration of my master staging server to worry about - and can be sure that all the servers in the web farm will be kept in sync whenever I deploy.
As Sayed mentions, as well, there are MSBuild tasks in 2010 (the Website Deployment feature is now implemented using msdeploy) to work with this - which also brings the possibility of a true Continuous Integration environment to VSTeamSystem - having a team build that can actually perform a full web deployment as its last step is very exciting (and scary, granted!).
实际上，MSDeploy 有 MSBuild 任务。它们将随 .NET 4/Visual Studio 2010 一起提供。
Actually there are MSBuild tasks for MSDeploy. They will be shipped with .NET 4/Visual Studio 2010.
虽然有点粗糙，但我已经非常喜欢 MSDeploy。使用它来同步场中的 Web 服务器非常有用，因为它非常高效（仅复制更改），并且除了内容文件之外还可以处理实际的 IIS 设置。 MSDeploy 似乎是各种场景和用途的构建块。另外，如前所述，.NET 4 中有一个用于 MSDeploy 的 MSBuild 任务。我利用此 MSBuild 任务使从 TeamCity 部署 Web 应用程序变得非常简单。我在这里写了博客：
Web Deploy (MS Deploy) from TeamCity - http://www.geekytidbits.com/web-deploy-ms-deploy-from-teamcity/
Although a bit rough around the edges, I've come to like MSDeploy quite a bit. Using it to sync web servers in a farm is very useful as it is efficient (only copies changes) and takes care of actual IIS settings in addition to content files. It seems like MSDeploy is a building block for various scenarios and uses. Also, as previously mentioned, there is a MSBuild task for MSDeploy in .NET 4. I've taken advantage of this MSBuild task to make deployment of my web applications from TeamCity trivially easy. I've blogged here it here:
Web Deploy (MS Deploy) from TeamCity - http://www.geekytidbits.com/web-deploy-ms-deploy-from-teamcity/
我最近开始实现部署管道，我发现以下链接非常有用：
http://www.troyhunt.com/2010/11 /you-deploying-it-wrong-teamcity_24.html
http://sedodream.com/2012/08/20/WebDeployMSDeployHowToSyncAFolder.aspx
我还使用了这些参考资料：
最后，“ Continuous Delivery》一书，给了我关于部署管道的很好的想法，虽然这本书不是专注于MSDeploy，但是确实值得一读。
I have recently started implementing a deployment pipeline and I found below links quite useful:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html
http://sedodream.com/2012/08/20/WebDeployMSDeployHowToSyncAFolder.aspx
Also I used these references:
Finally, "Continuous Delivery" book, gave me good ideas about deployment pipe line, although the book is not focusing on MSDeploy, but it is really worth reading.
文档声明是典型的 MSFT 1.0 产品，不幸的是，MSDN 不再有专门的开发技术工程师来填补空白——相反，人们盲目相信网络会提供它。
我实际上正在考虑重新审视我的写作技巧并写一本简短的电子书，因为它可能有市场......
The statement of documentation is typical of a MSFT 1.0 product, unfortunately MSDN no longer have dedicated Developer Technology Engineers to fill the gaps --- instead, there is a blind faith that the web will provide it.
I am actually considering dusting off my writing skills and write a short ebook on it since there is likely a market for it....
Msdeploy 确实带有一点 PowerShell 的味道：权力胜过简单性，而不是更坏更好。
没有 Windows 可以替代它，但是您可以混合它的一些功能来进行自动化部署。例如：
作为一种工具，它显然是针对服务提供商的，因为它是一把巨大的瑞士军刀。您可以使用它对 IIS 执行各种操作，这对于小型企业来说大多数情况下都是过分的。我没有大规模 IIS 设置的经验，所以也许这就是它的优点。
Msdeploy definitely has a touch of the PowerShell to it: power over simplicity rather than worse is better.
There is no Windows alternative to it, however you can hybridize some of its powers to make automated deployments. For example:
As a tool it's clearly aimed at service providers as it's an enormous Swiss army knife. You can do all kinds of things to IIS with it, which for the most part are over kill for small businesses. I've no experience of large scale IIS setups so maybe that's where it shines.