It is common practice to have different instances of an application stack to support Development, Test and Production stacks. The configuration of each of these application stack instances vary so LazyStack allows you to define stacks with unique configurations. LazyStack requires at least one Stack Definition called "Dev". LazyStack following example defines additional stacks Test and Prod.
# LazyStack Version 1.0.0 Stacks: Dev: ProfileName: default RegionName: us-east-1 StackName: PetStoreDev UriCodeTarget: Debug/netcoreapp3.1 Test: ProfileName: default RegionName: us-east-1 StackName: PetStoreTest UriCodeTarget: Debug/netcoreapp3.1 Prod: ProfileName: minordiety RegionName: us-east-1 StackName: PetStoreProd UriCodeTarget: Release/netcoreapp3.1
Note forward slash in UriCodeTarget property values.
ProfileName is the AWS profile that contains your credentials for accessing an AWS account with a specific role. Usually, the default profile and production profile ("minordiety" in this example) don't reference the same AWS Account. We recommend that each developer to have their own separate AWS development account. In most SDLC flows the developer might not have access to a production account.
The ProfileName "default" is created for you when you install the AWS CLI. You may have multiple profiles where each profile allows you access to different AWS accounts or different access privileges in an account. We strongly recommend that you do not use your development account to host production stacks. Create a separate account for production and use a production profile to access it. Updating a production stack with a development stack by mistake is not a happy time.
RegionName is the AWS region your stack is deployed to.
StackName is the the AWS logical stack name. The LazyStack convention used to name stacks is to append the stack name to the application name. In this example the application name is "PetStore" and the Stack is "Dev" so the StackName is "PetStoreDev".
UriCodeTarget is the build target to use. Usually one of: Debug/netcoreapp3.1 or Release/netcoreapp3.1
When you run Generate Projects, a Stacks directory is created in your Solution Project's root directory. Then a sub-directory for each environment is created under that and an serverless.template file is placed into that sub-directory. These serverless.template files contain the necessary information to publish an application stack to AWS for that environment. For example, the Stacks Directive shown above would produce the following directory structure.
Note: After you publish a stack you will also use Generate Settings to generate an AwsSettings.json file in the associated Stacks Environment folder. AwsSettings.json files contain the connection information necessary for client applications to call the stack.
PetStore Stacks Dev serverless.template Prod serverless.template Test serverless.template