Recommendations or abstractions for deployment stages

[mitchlloyd]

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.

[rix0rrr]

@eladb, what do you think about auto-deriving the stack name from the construct path (similar to logical IDs), then we can do something like:

class MyApplication extends cdk.Construct {
    constructor(scope: cdk.Construct, id: string, props: MyApplicationProps) {
        new MyStack1(this, 'Stack1', { env: props.env });
        new MyStack2(this, 'Stack2', { env: props.env });
        new MyStack3(this, 'Stack3', { env: props.env });
    }
}

// Creates Dev-Stack1, Dev-Stack2, Dev-Stack3
new MyApplication(app, 'Dev', { cheap: true, env: { accountId: '...', region: '...' }});
// Creates Prod-Stack1, Prod-Stack2, Prod-Stack3
new MyApplication(app, 'Prod', { env: { accountId: '...', region: '...' }});

Related ticket: #1479

[rix0rrr]

(Not to say we shouldn't do configurable stackName as well)

[eladb]

Somewhat related to how we implement nested stacks (#239)

[milch]

Any updates on this? We used to use an older version of the CDK that used the AWS::AccountId (etc.) pseudo parameters, where deploying the same template to multiple accounts worked reasonably well. We've upgraded to 0.22 recently and now it seems the CDK hardcodes the account IDs, completely breaking this rather simple approach. Edit: Actually just double checked and that's not true, never mind then. Still would like an update, please 😄

The only solution I can think of is synthesizing one template per account, but that seems overly complex to me

[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.

[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.

[plumdog]

Might another way of handling this to be to have separate deployment stages to be separate files in bin/? Eg have bin/myproject-prod.js and bin/myproject-stage.js? These, when run, could verify that the current account matches what they expect as needed, then load any config files (or contain config themselves), verify the config and pass it as props to the stack(s).

Then I pick one to be the default in cdk.json, probably stage or test or something, then to deploy prod I would run npm run cdk --deploy --app ./bin/myproject-prod.js.

However, this doesn't neatly handle being able to create a deployment stage using a name I pass, ie creating a deployment based on the current git branch, or something. This could be bodged with environment variables I think, but I being able to create and teardown arbitrarily named deployments easily would be great.

[bionicles]

cicd is a key area where CDK could be useful, any guidance on how to do this correctly is greatly appreciated!

[eladb]

This will be addressed as part of #3437

[tibbe]

This will be addressed as part of #3437

@eladb I read through that PR but since it's a bit more specific for CD could you summarize (or point me to something that summarizes) the best practice for adding configuration per deployment stage using CDK?

[hoegertn]

Maybe this can be of help: https://www.taimos.de/blog/deploying-your-cdk-app-to-different-stages-and-environments

[bionicles]

Maybe this can be of help: https://www.taimos.de/blog/deploying-your-cdk-app-to-different-stages-and-environments

absolutely. Might be good to fix the contrast on the code syntax highlighting as the comments are pretty hard to read

[hoegertn]

Thanks, fixed.