SSIS 部署最佳实践 - 包和其他工件
在我的环境中,大多数 SSIS 包都是独立的,只有包本身需要部署到生产中。
然而,现在我们有一组相当复杂的软件包,需要创建自己的表,并且如果可能的话,我希望能够在安装时检查权限。
我们考虑过创建一个 MSI 来使用分步向导进行生产安装。
我的问题:对于这样的 SSIS 部署场景是否有最佳实践?我们是否可以劫持 SSIS 默认生成的部署向导来添加我们自己的步骤? Microsoft 有相关文档/指南吗?
In my environment most SSIS packages are stand alone, and only the package it self needs to be deployed to production.
However now we have a fairly complex set of packages that need their own tables to be created, and I'd like to be able to check permission at install time if possible.
We have considered creating an MSI to do the production install using a step by step wizard.
My question: is there a best practices for a SSIS deployment scenario such as this? Can we possibly hijack the deployment wizard SSIS generates by default to add our own steps? Is there any Microsoft documentation/guidance around this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
通过在存在大量繁文缛节的大型组织中部署多个项目,msi 已被证明是最佳解决方案。就导入项目本身而不是部署工具而言,可以选择通过从 msi 内调用的命令行进行导入:
如您所见,用户界面步骤已添加到安装程序项目并通过上下文传递允许用户指定SSIS的实例名称。将 Sql 代理作业部署为 .sql 脚本以及其他 sql 依赖项也很有帮助,但批量部署 sql 脚本是一个更常见的问题。
From deploying multiple projects in a large organization with plenty of red-tape, msi's have proven to be the best solution. In terms of importing the project itself, rather then the deployment tool, it's an option to do the import via command line called from within the msi:
As you can see, a user interface step was added to the installer project and passed through the context to allow the user to specify the instance name of SSIS. It also helps to have the Sql Agent jobs deployed as a .sql script along your other sql dependencies, but bulk deploys of sql scripts is a more generic problem.
如果您使用的是 sql server 2012,您可能需要查看项目部署模型:
http://msdn.microsoft.com/en-us/library/hh213290" rel="nofollow">http:// /msdn.microsoft.com/en-us/library/hh213290
这消除了处理安装软件包的一些麻烦...就挂钩部署上的其他操作而言,我发现 powershell 或 msbuild 可以工作出色地。
if you are using sql server 2012 you may want to look at the project deployment model:
http://msdn.microsoft.com/en-us/library/hh213290
This eliminates some of the hassle of dealing with installing packages... as far as hooking in other actions on the deploy I have found powershell or msbuild to work well.