In order to confidently design a CI/CD deployment experience that supports assets and multiple stack ordering constraints, the Cloud Assembly document format needs to be defined, at least in an initial version.

Use-cases

1. An arbitrary number of stacks, some of which may be related
   • Nested stacks, too
2. Embedded support files (for example: Runtime code for Lambda; Static assets to be loaded to S3; Docker Images; CloudFormation documents for nested stacks; AMI baking instructions; ...)
   • Some of the support files may be too large to "bundle in", so support for external storage (S3, ...) may be relevant
   • Managed build steps (specific build steps for specific asset types (e.g: Python lambda bundle, NodeJS lambda bundle, Docker image, ...).
     • Need to consider CodePipeline limits (can be raised, but defaults are quite low & would come in the way of un-capped step count) as well as CodeBuild billing model (aka cost implications of many fast builds versus one slower build).
   • Self-contained means it can be digitally signed, and provisioning mechanisms can be configured to refuse handling un-signed or tampered with assemblies.
3. Phasing of deployments to honor dependencies between stacks & support files
   • Through use of the CDK CLI tools
   • Using a CI/CD pipeline
4. Re-use of the exact same artifacts in several stacks (in a CI/CD environment, deploy to QA environment, run integration tests, roll forward to production environment)
5. Interaction with context (in particular, when doing CI/CD, need to handle missing context correctly).
6. Workflows similar to:
   1. Build assembly, send to QA
   2. QA tests assembly, signs it if it passes, send to release management
   3. Release management verifies assembly is signed by QA key, deploys it to production

Remarks

• Phases: build then synthesize then package then deploy.
• The output of a CDK App execution is not the Cloud Assembly, but would describe instructions on how to piece it together.