Add option for user defined environment stages that are additional to Staging and Production

[joshbrgs]

I am currently implementing the DSF for application teams at work, and we have more environments than just the predefined staging and production. I believe with a little refactoring we can add additional stages dynamically from the provided context.

Currently I have a work around patch locally, and would love to help contribute this, as at least some of our teams are seeing this need.

[vgkowski]

@joshbrgs good point! What do you have in mind in terms of user experience and API?

[joshbrgs]

What is your thought on the use of the cdk context to nest the environments in an object, and the name of the environment will still be the key of the stage object, this could leave the the environments dynamic in naming as well as preference of stages?

{
  "environments": {
    "dev": {
      "account": "XXXX",
      "region": "us-east-1"
    },
    "staging": {
      "account": "XXXX",
      "region": "us-east-1",
      "integTest": true
    },
    "prod": {
      "account": "XXXX",
      "region": "us-east-1"
    }
  }
}
    

[vgkowski]

Using the CDK context is a good idea. I have few remarks on the object structure:

• JSON arrays can provide ordering of stages we need to deploy to. In the construct code, we can iterate over the elements of the array and add stages.
• it's easier to work with the name of stage if it's a value and not a key. We can have fully dynamic names. We still need to pass the stage name to the application stack so users can adapt the behavior of the application stack.

As a result, I suggest to switch to this object structure:

{
  "environments": [
    {
      "stage": "dev",
      "account": "XXXX",
      "region": "us-east-1"
    },
    {
      "stage": "staging",
      "account": "XXXX",
      "region": "us-east-1",
      "integTest": true
    },
    {  
      "stage": "prod",
      "account": "XXXX",
      "region": "us-east-1"
    }
  ]
}

Last remark is it will break the current API. We can mark the current code as deprecated but we need to maintain backward compatibility until DSF v2 is released. To achieve this, we can test if the user provides the old or the new object structure and have 2 different code path in the construct. Then, we will remove the old one in v2.

Happy to look at your PR on this. We can help with the backward compatibility if needed, just let me know.

[vgkowski]

@joshbrgs your thoughts?

[joshbrgs]

@vgkowski I think that sounds like a great idea, and good point about the breaking change.

[vgkowski]

Additional requirement to integrate in the PR: allow passing parameters to the stack in the ApplicationStackFactory

[vgkowski]

@joshbrgs it's available in the v1.19.0