VSTS Release Management - Multiple Release Definitions that share common environments

Question

I am trying to wrap my head around a problem I'm having with Release Management - I've have seem a solutions to this in other automated deployment tools such as uDeploy but am wondering if it can be handled in VSTS RM.

Here's my case:

I'd like to automated deployment for several (10+) windows service components in my application plus a UI component.

All artifacts are built using a single TFS Build definition.

The client would greatly appreciate the ability to deploy some or all of the components to Production on a release by release basis, as per the micro service architecture, and leave unaffected services untouched.

Creating 10 + Release Definitions, one for each component seems nuts, especially since environment configuration will be repeated across definitions.

But at the same time if I use a single definition, how can I make deployed components configurable?

Create Task per component under one definition and enable / disable the task per release? In which case I'll have to be constantly updating the Release Definition?

An 'environment' per component? And only deploy to the 'component environment' that I wish to deploy?

Any advice on this much obliged.

Thanks in advance.

Answer 1

You have multiple valid approaches here. Either your components are really independent from one another and you want to build (and deploy) them only when source has been changed, therefore split build definitions and release definitions make more sense. (think of it as each component having it's own release pipeline)

Or your components have some kind of dependencies and it'd make more sense to deploy all the web components at once, all the back end at once for eg. Then fewer build definitions and release definitions per role make more sense. (and will allow you to fine tune triggering)

Finally if your components are highly inter-dependent a unique build definition and release definition using environments and pre-deployment approval makes more sense.

What'd I'd like to emphasize here is the more build definitions and release definitions you have, the most options you have.
Focus on the essence of each component (what does it do, where is the workload located), interdependence, and who gets to approve what usually the answers comes itself after that.

Also even if environments could technically help you to achieve what you're trying to do, in my understanding they are meant to materialize things like "qa", "staging" and "production" in a build promotion flow. (vs source promotion)

Hope that helps.