July 16, 2009 at 9:19 am
If I want to move the current SSIS package From development to QA environment /install the ssis package into QA environment,I am following the below approach :
Copy the deployment folder from bin and transfer it to the server(QA) where it has to be installed. Inside deployment folder 3 files will be available.
1. PackageName.SSISDeployementManifest
2. ConfigFileName.dtsConfig
3. PackageName.dtsx
Double click the manifest file , wizard will be open , i will select file system option and the package is deployed to the file system in the QA environment.
Instead of manually doing the install into the QA environment , is it possible to do it as a silent install/automate the above process without manual intervention.
Can any one guide me how to do it which help me to learn .
Regards
Muralidharan.N
July 16, 2009 at 10:21 pm
I have accomplished something similar, I did not use the deployment wizard though. I built *.cmd scripts that did several things. I built one for each environment. Deployment is limited to a double click on the script..
1. Copies config files to the correct location using UNC path
2. Writes dtsx file into package store using dtutil.
CEWII
July 17, 2009 at 5:09 am
Thanks Elliott .
you mean to say the config file should contain the package configuration details of SSIS package.
with the help of batch file, the .dtsx package need to be copy /moved to the target environment.
Dev ---> QA.
Configuration file need to be modified w.r.t the target environment(QA).
When we execute the package the package will run successfully .
Am I right.
Also please tell whether we can maintain the .dtsx package in the SVN (Source code management) for version control.
what are all the difficulties will be there if I do the deployment through command line?
Doing the deployment through silent install to different environment is a best approach or doing the deployment manually with the help of .manifest file is best approach.
Please advise.
Regards
Murali
July 19, 2009 at 9:02 pm
When I wrote my packages the default configuration information was development servers. All packages are stored in a version control system, VSS or TFS, or maybe some other one depending on your environment.
The package that is deployed from Dev -> QC -> Pre-Prod -> Prod is the same package for every environment, once developed I use the config files that I built and deployed to handle the differences between the different environments. For my that was connection configs, I had different servers for every environment. I have a single *.cmd file that would handle the deployment of all packages and config files for a particular environment. I used config files even for (local) connections just to be sure I could easily change them later.. I had about 12 packages that used around a total of 14 different connections in various combinations. Every connection that touched a particular server and database had the same config file and the same connection name(this is required to make it work). What this allowed me to do is move a database from one server to another and only touch the single config file that dealt with it..
I had tried to have all of the configurations in a single file but that generated warnings because every connection didn't exist in every package, so it complained about the ones that didn't..
A later poster referenced the pack config wizard stuff. For a method where you know and control all the variables and do not want or need manual intervention I would NOT go down that path.. My perspective, I messed with that method for a while and didn't like it.
Also as a side note, when I store packages in the package store I store them in directories, which is supported. Unlike DTS where they all exist in the same directory I like to add a project path and then any major sub paths, ie: /DataWarehouse and /DataWarehouse/Fact and /DataWareHouse/Dim
CEWII
July 22, 2009 at 2:41 am
Thanks Elliott.
I will also try to work on the same.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply