I'm working on a rather large solution (client application, several windows services, several windows tasks).

Octo has been given a Project for each component within the solution for several reasons (some services provide integration and they can be rolled by the team consuming the integration, to better track the deployment of each component, to mitigate testing of unchanged components, process and variable isolation, etc)

We're currently rolling FEATURE based deployments... where a given deployment may involve several of the components (one rollout is to simply apply database indexes, another to tweak permissions, another for a new client feature which involves one of the services, another for a business rule change to a scheduled task, etc).

Unfortunately, while Octo is able to make the deployment of components easier, we're still left with a somewhat manual process of performing the FEATURE based deployment.

The complexity and incompatibility with the current Octo model, is that I'd need to create a project for each feature, for them to all coexist in the same environment, and be deployed across environments in any order. This negates the benefits of reusing a deployment process. Other suggestions have included use of variables/etc, but those won't work because variables (such as which components to deploy) are scoped to the release being deployed, which requires them to be deployed in a specific order.

What I would like, is to be able to create a "multi-project release", in which I am able to select the components being deployed (and the version number).

In my case, we've been careful to avoid dependencies across the rollouts (or, to combine them where they exist)... but I understand the concern... ideally, just as with a nuget package, I would be able to say that "Release A" includes "component A version >= 1.2.3.4"... which would also then provide a dependency of component A to the other components in Release A... by which "Release B" containing "component A version 2.0" would also require deployment of "Release A". But this use case is not something that applies to my need, and can be a vAfterNext kind of goal, given the scope.

Obviously, given that feature-based development is generally discouraged (given dependencies in code and databases), such a feature should probably include a "warning"... but the problem is somewhat common, so I believe a worthwhile feature request.