VSTS Release Management; many release targets

Question

I have a solution with 8 web projects and 12 executables They are all very tightly coupled, as there are a lot of business libraries shared between them; we have a single build definition in VSTS to the entire solution, but have 20 different release definitions.

We have single environments for Dev/QA/Pre-Prod/Production, enough concurrent active development, and administration restrictions that the single change moving up all environments model doesn't quite work for us; a Dev and QA test that will later move over to a nightly composite build for release candidates.

It seems to me that we want to have two sets of release definitions (a development & a QA set, as well as a user-acceptance through production set), but if that model is followed, we end up having 40 release definitions. Am I missing something? We have separate definitions for the EXEs because we don't want one release failure to affect another's, and since they are all separate payloads to separate directories, it seems like they should all be distinct.

Is the pattern of 1 release def per deployable project correct, and in the case of nightly builds, two sets of all deployable release definitions correct?

Answer 1

You should always aim towards having one release definition deploying either the whole application on one environment at once or at least deploying a whole sub system at once if you have some kind of micro services pattern in place. You don't want to have to trigger multiple releases when facing highly coupled dependencies. That can introduce at lot of errors in the cycle or at least complexity. That definition can also have the same sequence multiple times for each environment.