When to use SSIS Environments

Question

Ok, so I understand what they are, they're collections of parameter assignments that you can tell a package to use upon execution.

What I'm trying to understand is why or if I need to use them.

I'm migrated a bunch of old SSIS packages using the packages deployment model to some new servers using the project deployment model. I have one project containing about 35 packages. I've created parameters on all my packages, and have a couple of project level parameters for stuff like Server Name etc.

I'm developing on my PC and the packages will have their parameters set to my dev environment settings by default unless I change them.

I'm deploying my packages to 3 servers (Test, UAT, Prod). I deploy them from Visual Studio.

Each server runs an identically scripted SQL job to execute the package.

So now, I need to set my parameters for each environment/server.

Do I need to set up environments, or why can't I just right click - configure my Project in the SSIS Integration Services Catalog on each server, and set the parameters there for the project and each package?

If I create environments, I still need to enter all the parameter values for each server/environment, but then I need to set up the reference between the project and the environment, and set each SQL job to use the relevant environment when executing the job.

Are environments only useful if you have one server, one package catalogue, and one set of SQL Jobs, and you're just using different databases for each environment so you need the environments to toggle between each?

Aren't they overkill if you have your environments on different servers, or am I missing something?

Answer 1

A use case for Environments

As the DBA, I have access to the user names and passwords for systems. I can perform a one-time task of setting up environments that define all the things.

I can then empower the developers to create/deploy and configure their own SSIS projects without having to get involved or giving them a post-it with the associated credentials.

Environment vs Project configuration - I view this as automating what makes the most sense. I used to be a big advocate of Environments but I found migrating them difficult between servers (before I found the magic script) and the fact that you can only have 1 associated to a project a limitation I didn't like. At this point, I generally configure a project directly with SSMS and save the script off so I can replace values as I migrate up the environments.