Model stack dependencies / deployment order

[RomainMuller]

Sometimes stacks need to be deployed in a particular order in order for the deployment to succeed, as one stack depends on artifacts created by another (either via Fn::Import, or indirectly through custom resources, SSM parameters, ...). Currently, the CDK does not understand those dependencies and cdk deploy processes stacks in an arbitrary order.

In order to enable more sophisticated scenarios for interactions between stacks, for example allowing a construct to create a "helper" CDK Stack to be deployed before it's host stack.

An example use-case is when creating a custom domain mapping for an edge-optimized API Gateway endpoint, the ACM certificate needs to reside in the us-east-1 region, regardless of the region the API is defined in. One might want to create a "helper" stack in us-east-1 to manage the certificate.

Initially, the dependency would be explicitly modeled, but it could be determined automatically in the future.

For example, it could look like the following:

const domain = 'api.foo.acme.com';
const stackFoo = new cdk.Stack(app, 'Foo', { domain });
const stackBar = new cdk.Stack(app, 'Bar', { domain, env: { region: 'us-east-1' } });

// 'Foo' needs 'Bar' to be deployed in order to be deployable
stackFoo.dependsOnStack(stackBar);

[eladb]

This is should be covered by cloud assemblies (#233). In some cases it should be possible to deduce these automatically when there are cross-stack dependencies.

[rix0rrr]

It will also help for integration tests.

Yes, it would be better if these were derived automatically, but they aren't right now and this is a low-effort investment to get at least some affordances in place and update our tools to be able to act upon the data. We can always improve the dependency collection mechanism later.

[eladb]

Sure

[abelmokadem]

Is there a way to force all these exports? So that there is no need to delete these Cfn Outputs in the first place.

[rix0rrr]

We actually have a stack dependency mechanism right now, so I'm closing this PR.

@abelmokadem, I don't really understand your comment about forcing exports and deleting outputs, but feel free to make a new issue about it.