November 15, 2022 at 6:25 pm
Based on the Help About in Visual Studio this is my VS configuration:
Microsoft Visual Studio Enterprise 2019
Version 16.11.19
VisualStudio.16.Release/16.11.19+32901.82
Microsoft .NET Framework
Version 4.8.04084
Installed Version: Enterprise
SQL Server Data Tools 16.0.62205.05200
Microsoft SQL Server Data Tools
SQL Server Integration Services 15.0.2000.180
Microsoft SQL Server Integration Services Designer
Version 15.0.2000.180
My target is SQL Server 2016.
When I try to deploy a single package within a project, I get no errors, but the package properties do not show any change in the version of the package that was deployed, and when the package is executed via SQLServer Agent job, it still runs the older version of the package. I'm only able to get my updates into the production SSISDB by deploying the entire project, which defeats the purpose of incremental deployment.
I saw a number of issues from the past, but so far, none of them seem to apply to my situation. I've also tried running the command line version of the ISDeployment wizard, but same end result.
Clearly I am missing something, but I need some help figuring out what it might be.
Thanks
Luther
November 16, 2022 at 4:50 pm
I can't actually imagine why you would want to use the project deployment model and then try to use package deployments... that just doesn't make much sense. There's no real benefit to project deployment model if you are just going to deploy a single package. Maybe need to re-think how you are using this feature? Since you can always just download the current project into Visual Studio from the SSIS Catalog, make the changes to the one package, and then re-deploy the project, I'm not sure why that is a problem... Unless maybe you have way too many packages in a single project ? Again, might want t0 re-think how large a project should be... or how you are using the project deployment model...
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
November 16, 2022 at 5:59 pm
I may not have explained as clearly as I thought. I have a project in visual studio on my desktop that I am trying to deploy a single package within that project to the catalog on my production server. But, the ability to deploy a single package in the catalog feature that's been around for a while now, does not seem to be working. Whether that is due to something in my VS Studio setup or the production server's configuration is what I am trying to determine.
A single project in our catalog can have multiple projects in various stages of modification and development. Having to shelve, fork, etc in TFS in order to deploy the entire project just to get a single package in the project updated would be a huge nightmare, almost as bad as having to split projects out into smaller groups.
November 16, 2022 at 6:30 pm
Okay. so why are you using TFS, or for that matter, ANY kind of source control software, to manage SSIS projects? I wouldn't do that unless I was being paid Multiple MILLIONS of USD to not give a crap about quality results. Trying to have multiple authors on the same project is what having source control enables, and for SSIS projects, that is a really bad idea. When was the last time you had 3 or more equally fully qualified SSIS developers that understand the project, the configuration, AND the desired result, who can all work successfully on a TFS-based SSIS project and NOT eventually introduce a regression because they over-wrote code with their local copy?
I don't think I could hire 3 such people even if I had goobs and gobs of money to throw at them. The only viable way to ensure SSIS project success is to ensure the project managers know that the problem exists and allow single-threaded project development on any one given project at a time. This also tends to mean the projects are smaller, even if multiple projects are closely related. The one place that I worked a contract for and had significant SSIS stuff, the smart devs there knew better than to ever put an SSIS project into source control, and worked to ensure management knew not to allow that to occur.
There is almost never a good reason to maintain the SSIS package source on the laptop for anything other than DR purposes. If you know that there will be multiple developers who might make changes, then ALWAYS just freshly download the entire project and be sure no other developers are working on the same project for the timeframe needed to make your changes. Keeping the project small means you don't have as much opportunity for a conflict to arise, as functionality remains separated into projects small enough to avoid having to have multiple developers working on the same project.
Hope that wasn't coming across as a rant... I guess I just find it hard to believe that anyone would even consider thinking that a large SSIS project in TFS was a good idea...
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
November 16, 2022 at 6:45 pm
fortunately I am a team of 1, but even when it was a team of 2, we had no issues keeping things orderly. I use TFS for source control. I work on a dev system (workstation/laptop), then deploy to a separate QA server for testing and then to the Production Server.
Unfortunately, I can have several packages in one project in varying stages of Dev, QA, and Production.
Even if the project only has 2 packages, having to re-deploy the entire project when only 1 package was changed strikes me as a waste of time and resources. According to sources, documentation, blogs, etc, I should be able to just deploy the one changed package, but its not working. Either I'm missing something, or all the documentation, blogs, etc are wrong.
November 16, 2022 at 6:49 pm
Then I guess I have to ask just how many packages you have in a single project? If that answer is more than 3, then I question the project design. What on earth are you doing with SSIS that you need a large number of packages in a single project?
Edit: One of the reasons I believe in small projects is because past 3 packages, yep, the resource use to deploy the entire project starts to grow a lot. Why not just keep the projects at units of functionality. Meaning, project 1 does X, project 2 does Y, et cetera.. Why does the fact that packages are related at all suddenly require that they be in the same project?
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
November 16, 2022 at 7:34 pm
...
Unfortunately, I can have several packages in one project in varying stages of Dev, QA, and Production.
...
This is the primary cause of the problem. If you have different packages in different states of "repair" within the same project, then why on earth would you want to use projects at all ? Yes, the benefits of project deployment vastly outweigh the package deployment models benefits, but if you need to edit them separately and have them in entirely different states across your environments, you would be far better served by slicing the project into the requisite pieces that need to be able to be changed and deployed separately from the other packages. At least that way, when Microsoft features that you were depending on don't work, you can still function without the kind of issue you have now...
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply