Allow service connections to be parameterized in task groups
Task groups allows us to combine tasks across our release environments, except for since most of our tasks interact with Azure they require a service connection parameter. Please make the service connections parameterizable as well. I've tried putting a variable in there with the name of the service connection but it doesn't seem to work.
We are happy to let you know that your suggestion is already supported in team services and TFS 2018.
Following is an example of what to expect.
1. Create a release definition with Azure resource group deployment tasks.
2. In all tasks, choose a valid endpoint. You’ll need to do it multiple times and a variable cannot be used here
3. Create a task group with the tasks above. It would not have Azure subscription as a parameter.
4. Go to the task group and for each task in the group, you can update the subscription to $(AzureSubscription)
5. On saving of the task group, the Azure subscription would be bubbled up a as a parameter
John Downs commented
Thanks Shashank. However this really feels like a workaround rather than a proper fix. Having to use task groups isn't ideal - it's not obvious, and it also means that any time we do this we end up having to create additional task groups, which will quickly become unmanageable. Are there plans to support this in the main release definition editor?
Akshay Shaha commented
Which TFS 2018 version this has been implemented ? Update 1 or Update 2 ?
I was very surprised that something basic as this is not supported in VSTS. Using Task Groups is a must to guarantee consistency when creating deployment steps and when promoting the deployments through environments. Our Prod environment sits in a different subscription and this means I need to create a separate deployment process for Prod.
Daniel Richardson commented
need this when environments are hosted in different subscriptions (e.g. Dev, Test, UAT and Prod)
Alan Isherwood commented
This is a must for our environment. If this cannot be addressed then we will have to roll our own Power Shell to work round this missing feature.
This one feature of not allowing service endpoints to be part of configurable task groups is what's keeping our deployment process copy and paste pasta. Help us out!
Reilly Mulligan commented
My team has individual Azure subscriptions per Geo, and we are dependent on other teams who take follow this model, so code the replication of functionality across our release definitions is ridiculous. Without this feature, there is no way for us to centralize functionality.
Will McMilleon commented
From a user point of view, it makes no sense that this would not be supported. Can we hear what the complication is which prevents this from going forward?
Mark Richman commented
The absence of this feature is almost unforgivable.
This is extremely crucial for our project as we're about to go to production soon and I don't see a point to having two separate copies of task groups to maintain just because I cannot make subscription name use a variable.
Michael Ferioli commented
This seems like a really simple fix. I have everything else in my steps variablized except this.
Can't even begin to count how much time this consumes. Please get it in asap!
Stoimen Stoimenov commented
We are creating service fabric clusters from arm templates and registering them automatically as service endpoints. Unfortunately the endpoint connection in the build task has to be manually selected and cannot be set using a build variable. This kind of breaks our CD process and currently we are looking into rewriting the whole task with pure powershell simply because the endpoints are unusable
john m commented
this is the same as an earlier comment to provide params for subscriptions . .
can blend these together. .
Samuel Ledoux commented
It would be very nice to be able to pass the connected service as a variable to all the tasks so we could have a task group to reduce the maintenance between all our release environments.
An example of this is where we follow a standard pattern for our app service deployments with staging, swapping and stopping the app service. We have to create specific task groups for each subscription (dev and prod) and each product.
It would be very usefull when we have to trigger a single release on different environments, across different Azure subscriptions.