October 30, 2015 at 10:34 am
We are upgrading our SQL server 2008 R2 to SQL server 2014.
We have about 10 packages in 4 solutions.
And we have been using configuration file and save packages in the file system (not msdn) for our 2008 servers.
I know 2014 have a new way of project deployment, I just cannot see what the benefits of using project deployment mode than package deploy mode in our case.
Usually when we deploy a package we just copy the .dtsx file to the different environment like dev, test, prod.
So at the time of the upgrade to 2014, I would still keep the original save package to file system and use configuration file method.
Is that a good approach, or it is not.
Thanks,
October 30, 2015 at 10:43 am
sqlfriends (10/30/2015)
We are upgrading our SQL server 2008 R2 to SQL server 2014.We have about 10 packages in 4 solutions.
And we have been using configuration file and save packages in the file system (not msdn) for our 2008 servers.
I know 2014 have a new way of project deployment, I just cannot see what the benefits of using project deployment mode than package deploy mode in our case.
Usually when we deploy a package we just copy the .dtsx file to the different environment like dev, test, prod.
So at the time of the upgrade to 2014, I would still keep the original save package to file system and use configuration file method.
Is that a good approach, or it is not.
Thanks,
If you are happy with things as they are, perhaps there is no strong case to change.
But if you would like to take advantage of native logging, project level connections and parameters, configuration of projects from SSISDB environments rather than clunky environment variables, I suggest you at least check out the new way.
Perhaps migrate one of your smaller projects over there and give it a test drive.
Personally, I would hate to have to go back to using the old method.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
November 5, 2015 at 12:36 pm
One company I was at went to project level deployment in 2012. While the use of variables for data connections and parameters and such were really helpful there are some other considerations.
If you have multiple packages in a project then you have to deploy all or none of the changes. So working on two packages at the same time means you can roadblock one while working on the other. It's a big thing to take into consideration.
The other thing (and this may have been resolved but I doubt it) is the permission needed to read the catalog reports. In the version of 2012 we were using you needed full permissions to the catalog database to read reports. You couldn't grant a read access at all. This was bad. The suggested resolution was to make SSRS reports into the catalog.
On the upside the DBAs made PowerShell scripts to do the 90 day data center cutovers a piece of cake. And the reuse of data sources was nice.
November 5, 2015 at 1:04 pm
JustMarie (11/5/2015)
One company I was at went to project level deployment in 2012. While the use of variables for data connections and parameters and such were really helpful there are some other considerations.If you have multiple packages in a project then you have to deploy all or none of the changes. So working on two packages at the same time means you can roadblock one while working on the other. It's a big thing to take into consideration.
The other thing (and this may have been resolved but I doubt it) is the permission needed to read the catalog reports. In the version of 2012 we were using you needed full permissions to the catalog database to read reports. You couldn't grant a read access at all. This was bad. The suggested resolution was to make SSRS reports into the catalog.
On the upside the DBAs made PowerShell scripts to do the 90 day data center cutovers a piece of cake. And the reuse of data sources was nice.
I have read that all of your concerns are addressed in 2016. That permissions thing is a bit 'all or nothing' and not very refined.
But regarding your 'working on two packages at the same time' comment, I don't agree. Packages should be deployed from a 'production' source control branch. Half-finished development work should not be checked into that branch.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply