At minimum, a service should contain two files: Makefile and metadata.yaml. The Makefile contains instructions to build, package, deploy, test a given service using GNU make. The metadata.yaml file contains information such as dependencies and CloudFormation parameters.
When using one of the default Makefiles, there might be other files which will be described throughout this document.
For the list of targets for Makefile, please refer to the Make targets page.
The metadata.yaml files contains information such as its name, dependencies and feature flags. See the schema definition to know what you can use for your service. Here's an example of a metadata file:
name: my-service
# These will be used to check whether all dependencies for a service are
# deployed and check if there are any circular dependency. This allows to
# redeploy the entire infrastructure from scratch.
dependencies:
- products
- platform
# This section is used for service discovery. See the 'Service discovery' page in the documentation for more information.
parameters:
EventBusName: /ecommerce/{Environment}/platform/event-bus/name
ProductsApiArn: /ecommerce/{Environment}/products/api/arn
ProductsApiUrl: /ecommerce/{Environment}/products/api/url
# Boolean flags regarding a specific service. For example, the pipeline service
# does not support environments, or some services might not support tests.
# This section is optional and the values provided there are the default values.
flags:
environment: true
skip-tests: falseThis section is applicable when using one of the default Makefiles. If you're using a custom Makefile, you have the freedom to structure this section as you see fit.
The template.yaml file is the CloudFormation template that defines the resources that are part of the service.
This section is applicable when using one of the default Makefiles. If you're using a custom Makefile, you have the freedom to structure this section as you see fit.
This folder contains resource files such as OpenAPI document for API Gateway REST APIs or EventBridge event schemas, nested CloudFormation templates, etc.
By convention, the API Gateway REST API document should be named resources/openapi.yaml and the EventBridge event schema documents should be named resources/events.yaml. These files are linted automatically as part of the process using the lint command. See the testing section of the documentation to learn more.
This section is applicable when using one of the default Makefiles. If you're using a custom Makefile, you have the freedom to structure this section as you see fit.
This section contains the source code of Lambda functions. The code should not be placed directly into this folder but Lambda functions should have dedicated folders within it.
This section is applicable when using one of the default Makefiles. If you're using a custom Makefile, you have the freedom to structure this section as you see fit.
The tests/ folder contains unit and integration tests for the service. See the testing section of the documentation to learn more.