SSIS 部署最佳实践 - 包和其他工件

发布于 2024-10-18 01:34:45 字数 233 浏览 4 评论 0原文

在我的环境中,大多数 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

千秋岁 2024-10-25 01:34:45

通过在存在大量繁文缛节的大型组织中部署多个项目,msi 已被证明是最佳解决方案。就导入项目本身而不是部署工具而言,可以选择通过从 msi 内调用的命令行进行导入:

    [RunInstaller(true)]
    public partial class CustomInstaller : System.Configuration.Install.Installer
    {

        public override void Commit(IDictionary savedState)
        {
                base.Commit(savedState);
                string InstallPath = System.IO.Path.GetDirectoryName(this.Context.Parameters["assemblyPath"]) + @"\";
                string SqlServer = Context.Parameters["SqlServer"];
                SsisInstaller.ImportPackage(InstallPath + "MyProject.dtsx", "MyProject", SqlServer);
        }

    }

public class SsisInstaller
{


    public static void ImportPackage(string packagePath, string packageName, string sqlServer)
    {
        ProcessStartInfo ProcessStartInfo = new ProcessStartInfo(@"""c:\program files\Microsoft SQL Server\100\DTS\Binn\dtutil.exe""");
        ProcessStartInfo.Arguments = @" /File """ + packagePath + @""" /Copy SQL;" + packageName + " /Q /DestS " + sqlServer;
        Process.Start(ProcessStartInfo);
    }

}

如您所见,用户界面步骤已添加到安装程序项目并通过上下文传递允许用户指定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:

    [RunInstaller(true)]
    public partial class CustomInstaller : System.Configuration.Install.Installer
    {

        public override void Commit(IDictionary savedState)
        {
                base.Commit(savedState);
                string InstallPath = System.IO.Path.GetDirectoryName(this.Context.Parameters["assemblyPath"]) + @"\";
                string SqlServer = Context.Parameters["SqlServer"];
                SsisInstaller.ImportPackage(InstallPath + "MyProject.dtsx", "MyProject", SqlServer);
        }

    }

public class SsisInstaller
{


    public static void ImportPackage(string packagePath, string packageName, string sqlServer)
    {
        ProcessStartInfo ProcessStartInfo = new ProcessStartInfo(@"""c:\program files\Microsoft SQL Server\100\DTS\Binn\dtutil.exe""");
        ProcessStartInfo.Arguments = @" /File """ + packagePath + @""" /Copy SQL;" + packageName + " /Q /DestS " + sqlServer;
        Process.Start(ProcessStartInfo);
    }

}

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.

一瞬间的火花 2024-10-25 01:34:45

如果您使用的是 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文