Recommendations or abstractions for deployment stages

An approach to deploying many stacks to different stages was outlined by @eladb on Gitter:

const app = new cdk.App();

defineStage(app, 'dev',  { account: DEV_ACCOUNT_ID, region: DEV_REGION });
defineStage(app, 'prod', { account: PROD_ACCOUNT_ID, region: PROD_REGION });

app.run();

function defineStage(app: cdk.App, name: string, env: { account: string, region: string }) {
  new MyAppStack1(app, `my-app-stack-1`, { env, stage: name });
  new MyAppStack2(app, `my-app-stack-2`, { env, stage: name });
  new MyAppStack3(app, `my-app-stack-3`, { env, stage: name });
  // ...
}

// then, in `MyAppStackX` classes, you could consult the `stage` parameter to determine
// if you are in "prod" or "dev".

interface MyAppStackXProps extends cdk.StackProps {
  stage: string; // dev/prod
}

class MyAppStackX extends cdk.Stack {
  constructor(app: cdk.App, id: string, props: MyAppStackXProps) {
    super(app, id, props);
  }
}

For this to work, each stack would need to have a different logical name based on the stage (e.g. “MyAppStackDev”, “MyAppStackProd”.

From @eladb

…stacks must have a unique name within the app, regardless of their target environment. That’s definitely something we should fix by allowing you to override the physical stack name when you create a stack. Something like this:

new MyStack(this, `MyStack-${stage}`, { stackName: 'MyStack', env });

---

There is documentation to alludes to this approach in the docs, but I don’t think the code sample there is still valid and it isn’t clear to me how it would work.

[jderose9]

It appears there is no support for merging parameters, such as a deployment stage/application environment name (dev, qa, prod, etc) at deploy time, which would be ideal (so that I can build once and deploy many times), though not a deal breaker.

However, I’m having trouble determining the best route for even passing them at synth time. It looks like I can pass context parameters using the -c flag, though this seems confusing as the parameters stored into cdk.context.json leads me to believe that the context is intended for stability/preservation rather than providing dynamic values on each synth run.

I also see that I can add parameters into cdk.json, but I don’t see any way of providing an alternate file name, so easily storing or generating multiple configurations doesn’t seem like an option.

[cynicaljoy]

Can’t say if this is “the way” but it’s currently my way 😉 – I welcome any feedback!

Pretty much all parameters for my stacks are using SSMParameterProvider. This provides me the by account/region configuration of a Stack I desire. I can use the same app.js for each application across multiple accounts/regions. I’ve deployed about 10 stacks using this method. I haven’t ran into any blockers.

Important: cdk will also error our (as expected) if you forgot to create an SSM Parameter in a given account. Though, I’ve found that using cdk synth --verbose is necessary to see which parameter you forgot to create.

Potential blocker: This doesn’t account for optional parameters. Because cdk will fail to synth when it cannot locate an SSM Parameter with a given name, you must have an SSM Parameter with the desired name in every account/region you’re going to launch the stack in.