If you were logged in you would be able to see more operations.
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
We have established generic promotion paths for our environment deploys leveraging the manual promotion specified script evaluates to true to allow it to recursively look for a child configuration matching the configuration name we are looking for, and if so, then to display the "Deploy to {Environment Name}". The issue is, we have some application teams that want to have their environment named something other than what we are calling it. For example if we are calling it "Deploy to Dev" but they want it to say "Deploy to CrazyDev" If the promotions name field allows the use of variables; then we could do this for the customer without having to override the promotion. We want to avoid overriding the promotion because if we do, then later on if a bug is found with the promotion then we would need to fix it at the parent level as well as find all child levels in which it needs to be fixed as well.
|
Description
|
We have established generic promotion paths for our environment deploys leveraging the manual promotion specified script evaluates to true to allow it to recursively look for a child configuration matching the configuration name we are looking for, and if so, then to display the "Deploy to {Environment Name}". The issue is, we have some application teams that want to have their environment named something other than what we are calling it. For example if we are calling it "Deploy to Dev" but they want it to say "Deploy to CrazyDev" If the promotions name field allows the use of variables; then we could do this for the customer without having to override the promotion. We want to avoid overriding the promotion because if we do, then later on if a bug is found with the promotion then we would need to fix it at the parent level as well as find all child levels in which it needs to be fixed as well. |
Show » |
There are no comments yet on this issue.
|
|