2

I have a bunch of SSIS packages created in SQL Server 2012. As new SQL Server versions come out, we have to provide a these packages in a format for SQL Server 2014, 2016 (every time for a new SQL Server version).

To do this, we manually upgrade packages, and store them in our repository for each SQL Server version. Obviously, this isn't great as the only difference is the SQL Server version they are compatible with.

Currently, there is an Integration Services project behind these in Visual Studio 2017, and via the IDE, you can upgrade all the packages via the flick of a switch.

Ideally, I'd like my Jenkins CI to do this conversion for me to each SQL Server version and make the packages available in each SQL Server version. Can this be done? I don't want to store every version package in my repo for distribution really...

TIA.

Hadi
  • 36,233
  • 13
  • 65
  • 124
Max Power
  • 350
  • 4
  • 15
  • I'm actually not sure I follow. I you're using SSDT 2017 then when deploying your project you simply have to make sure the correct destination server is selected in the project. You don't have to upgrade every package at all. Are you *not* using SSISDB? If not, I suggest you do; you'll find things vastly easier. – Thom A Feb 24 '19 at 20:39
  • I'm not using that to deploy the package as it stands. We manually have all the packages in each version of SQL (so 2012, 2014 and 2016 currently). The 2014+ packages are made by importing the 2012 package into the SQL server, right-clicking then selecting upgrade. Export the package out, and we have our 2014 package. We use a dtspackage.exe with a manifest package to deploy this to a server on site. It sounds like we should be using SSISDB to deploy to different servers if that does the necessary upgrades. – Max Power Mar 04 '19 at 15:17
  • Using SSISDB sounds like the right plan, imo. – Thom A Mar 04 '19 at 15:32

0 Answers0