SSIS deployment best practices - package and other artifacts

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 d开发者_如何学Pythoneployment 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?

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.

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.