Configurations is a redundant, overloaded term (see what I did there?) when it comes to Visual Studio SSIS projects. When people talk SSIS and configurations mostly it is regarding runtime configurations which allow values to be passed into an SSIS package. That’s not what these posts are about.
Instead these three posts are about Visual Studio Project Configurations and how they work (or don’t work) with SSIS.
- What are Visual Studio Project Configurations
- SSIS 2008 Project Configurations
- SSIS 2012 Project Configurations
As SQL Server Data Tools (SSDT) and SSIS 2012 have been promoted and talked about, one of the things that has been mentioned is that SSIS 2012 now works with configurations. Yay. SSDT is now built on Visual Studio 2010 shell (Yes Visual Studio 2012 was just released and no we are never going to get away from running multiple versions of Visual Studio). Here’s the documentation for Visual Studio 2010 Managing Configuration Options.
For those that haven’t seen SSIS 2012 yet, there have been some significant changes. One of the many changes is SSIS packages are managed as a project in what’s called Project Deployment Model (vs. the package deployment model which we have been using – see the comparison here). Within this model there is the ability to set project level options including Project Parameters which allow values to be passed into the project at runtime. This is the replacement for the SSIS runtime configurations we have used.
So first thing is checking BOL see what is mentioned and what is configurable. Surprisingly I was unable to find much of anything about them in BOL. Course searching for combinations of SSIS, SSDT, VS, Environment, Configuration brings back a whole lot of stuff, per the overloaded terms as already stated above.
So what can be configured using Visual Studio Configurations? Turns out that the only thing that works with VS configurations is setting and changing the values of the project parameters within SSDT. Nothing regarding deployment options, build options, logging options, etc. Here are the dialogs:
Selecting the environment in SSDT will only apply these values within the scope of SSDT. This can be useful for validation purposes against different environments or runtime execution, provided it is being executed within SSDT. So how do we manage automated builds? Well we’re back to installing a codeplex project. Take a look at this where Matt Masson (b | t) has provided msbuild support for ispac file. You might see the trend that SSIS build ispac files, while SSDT builds dacpac files (no we don’t have rspac or aspac deployment files, at least not yet).
Overall SSIS 2012 is a huge improvement and personally I have really been enjoying using it, however I must confess to seeing irony in an integration product not being fully integrated within its own development platform. Where’s the continuous integration? Where’s the code analysis? Where’s the unit testing? Where are those things that allow confidence in creating and maintaining quality code? Yes SSIS has automated logging now through the catalog, great it is easier to investigate crap code in production, however where’s the validation prior to release?
I’m not saying these aren’t difficult problems to solve, and I’m a big proponent of code reviews. However I’m going to continue to trumpet how data, arguably one of many companies’ most valuable assets needs to have quality code surrounding it. Until the data tools mature to provide more, we’re going to continue to have issues.