Typescript is a hell of a drug.
I’ve recently finished writing a Typescript serverless app using AWS services with a CD pipeline built on Github Actions.
Most of the pipeline runs in docker containers and so it can be run locally if needed and could be switched from github actions fairly easily.
The pipeline repository contains code that creates an S3 bucket to store the artifacts and state. This bucket triggers a lambda function that invokes the github actions workflows for the environments.
The pipeline bucket contains the following types of files:
- Artifacts - zip files that contain the deployable forms of projects. CDK will deploy the app from these files.
- Manifests - json files contain information about which artifact versions to deploy.
- Deployments - json files that contain information relating deployments that have been made to environments. Each of these are a specific colour (green or blue) and used to run automated tests.
- deployedColour.txt - a file that stores the current deployed colour for an environment.
The repo contains the code that triggers the deployment and automated tests for the environment.
The app repo will save artifacts and a manifest file to the bucket, triggering the deployment to
The deployment will start and if successful will trigger automated tests to run on the stage environment. If these tests are successful the deployment will report it to the lambda and this may trigger the same process on the non-live colour for
The app repo contains the code for:
deployartifact that contains the CDK code to deploy app
testsartifact that contains playwright tests to be run on environments
apiartifact that contains the back end code
siteartifact that contains the front end code.
tests artifacts contain zx script files that are executed by the pipeline code.
The app repo builds the artifacts then publishes the artifacts and creates a manifest file which may trigger the start of the pipeline, depending on the branch.
Pipeline required behaviours
manifests from the
main branch are auto deployed to
stage and then to the non-live colour on
prod if there are no failures.
manifest files are promoted from environment to environment and deploy the same exact artifact files at each stage.
the pipeline repo can also have non-prod environments for testing development changes. these environments will create their own bucket and not deploy to the
There are a few things that could be better about this setup. It is advisable to use a different AWS account for each environment. There are examples of how to do this with the CDK V2 in the AWS docs.
It also might be easier to use AWS Code(Build|Deploy) for a pipeline, but I thought it would be fun to try and implement one in Github Actions.
I had a lot of fun creating this example app and will use it as a base for future projects. Please feel free to do the same, information on how to do so is on the github repositories.