August 19, 2008 at 1:56 am
Not seeing an answer to this in my searching. I have an SSIS exported maintenance plan that I have reconfigured with appropriate config values for log paths and db connection in Visual Studio... and I can manually import the package into MSDB\Maintenance Plans on a new server... schedule it... and everything works fine.
The issue is, I want to export the config properties so that servername and log paths can be set during deployment without having to modify the dtsx file every time in VS and doing an import. (quite necessary when dealing with cluster instances... otherwise localhost and a common log file path would work fine)
This way I can give a deployment manifest to the jr engineers on my team, and they can double click and push the maintenance plan with new config values.
I can get the package to deploy into the MSDB... just not the Maintenance Plan subfolder.
Any ideas?
August 19, 2008 at 2:45 am
Eh... dtutil doesn't allow for configuration files it seems. I decided to write a script to replace the values in the dtsx file and then call dtutil to load it.
So disregard this post.
August 19, 2008 at 5:08 am
I recently had to do the same thing. I found a freeware command line utility called replace.exe that I was able to use to modify connection string information through a command during deployment.
Package deployment is one area that MS seems to not have spent a great deal of time on.
August 19, 2008 at 5:14 am
I disagree.
There is nothing you cannot do. Granted, you have to edit the config file but that is a simple task with notepad or any number of free xml editors.
A package should not have any hardcoded values on it. All config.
A simple example was here, server died. 200 odd packages running.
Quick, move to new server. As we had come up with a decent method for config, we had to open about 15 different config files, update servername, root path etc and done.
If we had each of them as you are trying to do, we would still be trying to change / corrupt the packages.
Seriously - don't hardcode values. Everything changeable should be via config.
Cheers,CrispinI can't die, there are too many people who still have to meet me!It's not a bug, SQL just misunderstood me!
August 19, 2008 at 5:42 am
It's often the config files that I need modified during my deployment process. I have to pass off the deployment to an administrator that then has to change configuration files manually with notepad during the deployment process. This process pretty much sucks. The other problem is having configuration files in different locations depending on the environment I am deploying to.
Some kind of multi-server deployment utility would be nice - a utility I am going to probably have to build myself within a few months just to support some of the more complicated deployments and updates we have here.
This could all be smoother. It's pretty disconnected.
August 19, 2008 at 5:49 am
I would agree with you there. It is a bit. I suspect there are many many home built config editors out there. Maybe work a community project on CodePlex and write an all singing all dancing one. I would certainly use it.
Anyone up for it?
There are ways though that can save you some time:
Naming convention for connection objects.
One variable called _ROOT from which all other paths build themselves.
Global / shared config files. These contain all the common things that 80% of the packages actually use. The other packages have the variables / connection managers but just don't use them.
Would use of environmental variables not help your cause? I use them rather successfully.
I have built, over time, a nifty config system that works a charm. It actually makes deployment very very easy 🙂 I will share it once I have documented / packaged it. Not this week though 🙁
Right, anyone for a SSIS config thingy-ma-jig?
Cheers,CrispinI can't die, there are too many people who still have to meet me!It's not a bug, SQL just misunderstood me!
August 19, 2008 at 6:04 am
I may take you up on the co-sourced config-thingy. Not this week though.
I've also used environment variables, and setting the configuration values in the job agent, etc. It has all just felt a bit like a hack to me. Call me crazy, but I want to finish my package in Visual Studio and have the ability to generate an msi package with options for allowing the user to set config file locations and values, connection strings, and variable values through a setup GUI.
Now, I work for a pretty big company and we really have separation of duties. This has never been as much of an issue for me in the past because the environments supported me doing the install and handling all of the minor tweaks along the way. It's just a bummer that I am going to have to write something myself to solve it.
August 19, 2008 at 6:31 am
Cool - will sort out something on codeplex. See what happens.
As for MSIs, I did a stint with a company that used them. Used Wix to create them rather successfully. I _don't_ believe they altered the files though. I know they had environmental variables. But configs were mostly static.
Cheers,CrispinI can't die, there are too many people who still have to meet me!It's not a bug, SQL just misunderstood me!
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply