LazyStack

Stacks Directive

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. 


Stacks:
  Dev:
    ProfileName: default
    RegionName: us-east-1 
    StackName: PetStoreDev
    Stage: Dev
    UriCodeTarget: Debug/net6.0
  Test:
    Stage: Test
    UriCodeTarget: Debug/net6.0
  Prod:
    Stage: Prod
    UriCodeTarget: Release/net6.0

Note forward slash in UriCodeTarget property values.

Stacks Directive Properties

  • ProfileName - (Dev stack only)

    ProfileName is the AWS profile that contains your credentials for accessing an AWS account with a specific role. We recommend that each developer to have their own separate AWS development account. In most SDLC flows the developer does 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 - (Dev stack only)

    RegionName is the AWS region your stack is deployed to. RegionName is only relevant for the Dev stack. The Test and Prod regions are usually determined by your CI/CD pipelines.

  • StackName - (Dev stack only)

    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". The StackName directive is only relevant for the Dev stack. The Test and Prod stack names are usually determined by your CI/CD pipelines.

  • Stage

    The ApiGateway stage.

  • UriCodeTarget

    UriCodeTarget is the build target to deploy. Usually one of:

    • Debug/net6.0
    • Release/net6.0

How Stack Environments are used

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. 


PetStore
  Stacks
    Dev 
      serverless.template 
    Test 
      serverless.template
    Prod
      serverless.template

The Dev stack is used when you publish to your AWS Account from your Workstation. The Test and Prod stacks are used by CI/CD scripts in LazyStack SMF.

Note: After you publish a Dev stack you will also use LazyStack Generate Settings to generate an AwsSettings.json file in the Stacks Dev folder. AwsSettings.json files contain the connection information necessary for client applications to call the stack.

AwsSettings.json for Test and Prod Stacks

Test and Prod stacks are published by the LazyStack SMF CI/CD CodeBuild processes. The CodeBuild process generates an AwsSettings.json file for the published stack and places that AwsSettings.json file in the appropriate stacks folder in GitHub. Do a GitHub Pull to receive the latest AwsSettings.json file for the Test or Prod stack to use in your client app.