Using Environment parameters as Project parameters
up vote
1
down vote
favorite
Our Change Approval team is trying to get us to use Octopus to deploy SSIS packages to our Production environment. The problem is that the tool (Azure DevOps) we use to generate the build for Octopus doesn't create or populate Project parameters when it deploys a project. It does, however, create and populate Environment parameters.
Up to now we have not used Environment parameters at all because we don't use multiple environments on any one server.
The CA team is suggesting that we work around the inability to deploy Project parameters by converting them to Environment parameters, and create one Environment per project.
This feels wrong to me, but I haven't been able to come up with a reason we can't do this, nor have I found one anywhere on the internet so far. On the other hand, I also haven't found anybody saying that they are doing this and it's working fine, either.
So, does anybody have any arguments for or against using Environment parameters to replace Project parameters per se?
Assume that I don't have to worry about any possible future need for multiple environments on a server.
ssis octopus-deploy
asked Nov 9 at 16:33
Tab Alleman
25.1k52440
|
show 2 more comments
up vote
1
down vote
favorite
Our Change Approval team is trying to get us to use Octopus to deploy SSIS packages to our Production environment. The problem is that the tool (Azure DevOps) we use to generate the build for Octopus doesn't create or populate Project parameters when it deploys a project. It does, however, create and populate Environment parameters.
Up to now we have not used Environment parameters at all because we don't use multiple environments on any one server.
The CA team is suggesting that we work around the inability to deploy Project parameters by converting them to Environment parameters, and create one Environment per project.
This feels wrong to me, but I haven't been able to come up with a reason we can't do this, nor have I found one anywhere on the internet so far. On the other hand, I also haven't found anybody saying that they are doing this and it's working fine, either.
So, does anybody have any arguments for or against using Environment parameters to replace Project parameters per se?
Assume that I don't have to worry about any possible future need for multiple environments on a server.
ssis octopus-deploy
asked Nov 9 at 16:33
Tab Alleman
25.1k52440
That's our setup, we don't use Octopus, we do project deployments and once deployed to the server we have a minimum of one environment per project, but can have more, majority don't. The project variables are deployed, but are reconfigured to point to environment variables. By default all project variables have a corresponding environment variable. all that sort of stuff is very specific to your setup.
– Tim Mylott
Nov 9 at 16:52
One question though, if Octupus does create project variables, how is that even referenced in the project itself? Meaning I have a SSIS package using project variable. When deployed, in your case, that isn't created on the server? In our case it's deployed, just reconfigured to point to the environment variable. Just curious.
– Tim Mylott
Nov 9 at 16:54
In our specific situation one of the main reasons is better/easier visibility into all of those configuration values. Have have a lot of code deployed across hundreds on instances. When needing do dependency checks, etc, we can just query the environment tables in SSISDB to find what projects/packages could be using a certain file path, connection string, etc, those items we have standardized as Project/environment variables.
– Tim Mylott
Nov 9 at 17:03
@TimMylott I'm getting a demonstration as to how it works in a couple of hours, but I would assume that the package would have to be reconfigured to associate its parameters with Environment variables instead of Project variables. I'm also assuming that Octopus is going to do this automatically. So, if you're not using Octopus, why are you setting up your Environments this way?
– Tab Alleman
Nov 9 at 18:50
@TabAlleman Not trying to be nit-picky, but when you say project variables, do you mean project parameters? I'm not familiar with "project variables" and just want to make sure it's not something I just have never encountered. We use Team City to build SSIS projects and Octopus to deploy. When our dev ops team sets up a new SSIS project in Octopus, we provide a mapping of Project Parameters to Environment Variables. Octopus does not create or populate the Environment Variables. That can be done through the SSMS gui or with scripts. I'd be glad to try to describe it in more detail if need be.
– Jeremy J.
Nov 9 at 19:15
|
show 2 more comments
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Our Change Approval team is trying to get us to use Octopus to deploy SSIS packages to our Production environment. The problem is that the tool (Azure DevOps) we use to generate the build for Octopus doesn't create or populate Project parameters when it deploys a project. It does, however, create and populate Environment parameters.
Up to now we have not used Environment parameters at all because we don't use multiple environments on any one server.
The CA team is suggesting that we work around the inability to deploy Project parameters by converting them to Environment parameters, and create one Environment per project.
This feels wrong to me, but I haven't been able to come up with a reason we can't do this, nor have I found one anywhere on the internet so far. On the other hand, I also haven't found anybody saying that they are doing this and it's working fine, either.
So, does anybody have any arguments for or against using Environment parameters to replace Project parameters per se?
Assume that I don't have to worry about any possible future need for multiple environments on a server.
ssis octopus-deploy
asked Nov 9 at 16:33
Tab Alleman
25.1k52440
Our Change Approval team is trying to get us to use Octopus to deploy SSIS packages to our Production environment. The problem is that the tool (Azure DevOps) we use to generate the build for Octopus doesn't create or populate Project parameters when it deploys a project. It does, however, create and populate Environment parameters.
Up to now we have not used Environment parameters at all because we don't use multiple environments on any one server.
The CA team is suggesting that we work around the inability to deploy Project parameters by converting them to Environment parameters, and create one Environment per project.
This feels wrong to me, but I haven't been able to come up with a reason we can't do this, nor have I found one anywhere on the internet so far. On the other hand, I also haven't found anybody saying that they are doing this and it's working fine, either.
So, does anybody have any arguments for or against using Environment parameters to replace Project parameters per se?
Assume that I don't have to worry about any possible future need for multiple environments on a server.
ssis octopus-deploy
ssis octopus-deploy
asked Nov 9 at 16:33
Tab Alleman
25.1k52440
asked Nov 9 at 16:33
Tab Alleman
25.1k52440
edited Nov 9 at 20:53
asked Nov 9 at 16:33
Tab Alleman
25.1k52440
asked Nov 9 at 16:33
Tab Alleman
25.1k52440
asked Nov 9 at 16:33
Tab Alleman
25.1k52440
25.1k52440
That's our setup, we don't use Octopus, we do project deployments and once deployed to the server we have a minimum of one environment per project, but can have more, majority don't. The project variables are deployed, but are reconfigured to point to environment variables. By default all project variables have a corresponding environment variable. all that sort of stuff is very specific to your setup.
– Tim Mylott
Nov 9 at 16:52
One question though, if Octupus does create project variables, how is that even referenced in the project itself? Meaning I have a SSIS package using project variable. When deployed, in your case, that isn't created on the server? In our case it's deployed, just reconfigured to point to the environment variable. Just curious.
– Tim Mylott
Nov 9 at 16:54
In our specific situation one of the main reasons is better/easier visibility into all of those configuration values. Have have a lot of code deployed across hundreds on instances. When needing do dependency checks, etc, we can just query the environment tables in SSISDB to find what projects/packages could be using a certain file path, connection string, etc, those items we have standardized as Project/environment variables.
– Tim Mylott
Nov 9 at 17:03
@TimMylott I'm getting a demonstration as to how it works in a couple of hours, but I would assume that the package would have to be reconfigured to associate its parameters with Environment variables instead of Project variables. I'm also assuming that Octopus is going to do this automatically. So, if you're not using Octopus, why are you setting up your Environments this way?
– Tab Alleman
Nov 9 at 18:50
@TabAlleman Not trying to be nit-picky, but when you say project variables, do you mean project parameters? I'm not familiar with "project variables" and just want to make sure it's not something I just have never encountered. We use Team City to build SSIS projects and Octopus to deploy. When our dev ops team sets up a new SSIS project in Octopus, we provide a mapping of Project Parameters to Environment Variables. Octopus does not create or populate the Environment Variables. That can be done through the SSMS gui or with scripts. I'd be glad to try to describe it in more detail if need be.
– Jeremy J.
Nov 9 at 19:15
|
show 2 more comments
That's our setup, we don't use Octopus, we do project deployments and once deployed to the server we have a minimum of one environment per project, but can have more, majority don't. The project variables are deployed, but are reconfigured to point to environment variables. By default all project variables have a corresponding environment variable. all that sort of stuff is very specific to your setup.
– Tim Mylott
Nov 9 at 16:52
One question though, if Octupus does create project variables, how is that even referenced in the project itself? Meaning I have a SSIS package using project variable. When deployed, in your case, that isn't created on the server? In our case it's deployed, just reconfigured to point to the environment variable. Just curious.
– Tim Mylott
Nov 9 at 16:54
In our specific situation one of the main reasons is better/easier visibility into all of those configuration values. Have have a lot of code deployed across hundreds on instances. When needing do dependency checks, etc, we can just query the environment tables in SSISDB to find what projects/packages could be using a certain file path, connection string, etc, those items we have standardized as Project/environment variables.
– Tim Mylott
Nov 9 at 17:03
@TimMylott I'm getting a demonstration as to how it works in a couple of hours, but I would assume that the package would have to be reconfigured to associate its parameters with Environment variables instead of Project variables. I'm also assuming that Octopus is going to do this automatically. So, if you're not using Octopus, why are you setting up your Environments this way?
– Tab Alleman
Nov 9 at 18:50
@TabAlleman Not trying to be nit-picky, but when you say project variables, do you mean project parameters? I'm not familiar with "project variables" and just want to make sure it's not something I just have never encountered. We use Team City to build SSIS projects and Octopus to deploy. When our dev ops team sets up a new SSIS project in Octopus, we provide a mapping of Project Parameters to Environment Variables. Octopus does not create or populate the Environment Variables. That can be done through the SSMS gui or with scripts. I'd be glad to try to describe it in more detail if need be.
– Jeremy J.
Nov 9 at 19:15
That's our setup, we don't use Octopus, we do project deployments and once deployed to the server we have a minimum of one environment per project, but can have more, majority don't. The project variables are deployed, but are reconfigured to point to environment variables. By default all project variables have a corresponding environment variable. all that sort of stuff is very specific to your setup.
– Tim Mylott
Nov 9 at 16:52
That's our setup, we don't use Octopus, we do project deployments and once deployed to the server we have a minimum of one environment per project, but can have more, majority don't. The project variables are deployed, but are reconfigured to point to environment variables. By default all project variables have a corresponding environment variable. all that sort of stuff is very specific to your setup.
– Tim Mylott
Nov 9 at 16:52
One question though, if Octupus does create project variables, how is that even referenced in the project itself? Meaning I have a SSIS package using project variable. When deployed, in your case, that isn't created on the server? In our case it's deployed, just reconfigured to point to the environment variable. Just curious.
– Tim Mylott
Nov 9 at 16:54
One question though, if Octupus does create project variables, how is that even referenced in the project itself? Meaning I have a SSIS package using project variable. When deployed, in your case, that isn't created on the server? In our case it's deployed, just reconfigured to point to the environment variable. Just curious.
– Tim Mylott
Nov 9 at 16:54
In our specific situation one of the main reasons is better/easier visibility into all of those configuration values. Have have a lot of code deployed across hundreds on instances. When needing do dependency checks, etc, we can just query the environment tables in SSISDB to find what projects/packages could be using a certain file path, connection string, etc, those items we have standardized as Project/environment variables.
– Tim Mylott
Nov 9 at 17:03
In our specific situation one of the main reasons is better/easier visibility into all of those configuration values. Have have a lot of code deployed across hundreds on instances. When needing do dependency checks, etc, we can just query the environment tables in SSISDB to find what projects/packages could be using a certain file path, connection string, etc, those items we have standardized as Project/environment variables.
– Tim Mylott
Nov 9 at 17:03
@TimMylott I'm getting a demonstration as to how it works in a couple of hours, but I would assume that the package would have to be reconfigured to associate its parameters with Environment variables instead of Project variables. I'm also assuming that Octopus is going to do this automatically. So, if you're not using Octopus, why are you setting up your Environments this way?
– Tab Alleman
Nov 9 at 18:50
@TimMylott I'm getting a demonstration as to how it works in a couple of hours, but I would assume that the package would have to be reconfigured to associate its parameters with Environment variables instead of Project variables. I'm also assuming that Octopus is going to do this automatically. So, if you're not using Octopus, why are you setting up your Environments this way?
– Tab Alleman
Nov 9 at 18:50
@TabAlleman Not trying to be nit-picky, but when you say project variables, do you mean project parameters? I'm not familiar with "project variables" and just want to make sure it's not something I just have never encountered. We use Team City to build SSIS projects and Octopus to deploy. When our dev ops team sets up a new SSIS project in Octopus, we provide a mapping of Project Parameters to Environment Variables. Octopus does not create or populate the Environment Variables. That can be done through the SSMS gui or with scripts. I'd be glad to try to describe it in more detail if need be.
– Jeremy J.
Nov 9 at 19:15
@TabAlleman Not trying to be nit-picky, but when you say project variables, do you mean project parameters? I'm not familiar with "project variables" and just want to make sure it's not something I just have never encountered. We use Team City to build SSIS projects and Octopus to deploy. When our dev ops team sets up a new SSIS project in Octopus, we provide a mapping of Project Parameters to Environment Variables. Octopus does not create or populate the Environment Variables. That can be done through the SSMS gui or with scripts. I'd be glad to try to describe it in more detail if need be.
– Jeremy J.
Nov 9 at 19:15
|
show 2 more comments
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53229729%2fusing-environment-parameters-as-project-parameters%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
That's our setup, we don't use Octopus, we do project deployments and once deployed to the server we have a minimum of one environment per project, but can have more, majority don't. The project variables are deployed, but are reconfigured to point to environment variables. By default all project variables have a corresponding environment variable. all that sort of stuff is very specific to your setup.
– Tim Mylott
Nov 9 at 16:52
One question though, if Octupus does create project variables, how is that even referenced in the project itself? Meaning I have a SSIS package using project variable. When deployed, in your case, that isn't created on the server? In our case it's deployed, just reconfigured to point to the environment variable. Just curious.
– Tim Mylott
Nov 9 at 16:54
In our specific situation one of the main reasons is better/easier visibility into all of those configuration values. Have have a lot of code deployed across hundreds on instances. When needing do dependency checks, etc, we can just query the environment tables in SSISDB to find what projects/packages could be using a certain file path, connection string, etc, those items we have standardized as Project/environment variables.
– Tim Mylott
Nov 9 at 17:03
@TimMylott I'm getting a demonstration as to how it works in a couple of hours, but I would assume that the package would have to be reconfigured to associate its parameters with Environment variables instead of Project variables. I'm also assuming that Octopus is going to do this automatically. So, if you're not using Octopus, why are you setting up your Environments this way?
– Tab Alleman
Nov 9 at 18:50
@TabAlleman Not trying to be nit-picky, but when you say project variables, do you mean project parameters? I'm not familiar with "project variables" and just want to make sure it's not something I just have never encountered. We use Team City to build SSIS projects and Octopus to deploy. When our dev ops team sets up a new SSIS project in Octopus, we provide a mapping of Project Parameters to Environment Variables. Octopus does not create or populate the Environment Variables. That can be done through the SSMS gui or with scripts. I'd be glad to try to describe it in more detail if need be.
– Jeremy J.
Nov 9 at 19:15