Creates and destroys on-demand environments through separate ECS services. Works on ECS and Fargate.
How it works
ECS Deity provisions on-demand testing environments based on github branch names by creating separate ECS services on the same testing cluster. On creation, it creates a target group and listner and assigns a random unused port to a shared ALB and creates a branch-specific service based on a currently deployed task definition. On destruction, the proccess is reversed, after stopping all running tasks. Step functins are used for orchestration.
For example, when a branch named
feature/test123 is pushed for a repository named
my-project, the following is created:
- Target group named
- ALB listner with a random port which routes to the target group
- ECS service named
Any necessary app-specific deployments like database migration, data loading, etc. are de-coupled. A lambda arn is configurable for such tasks.
Notifications to the user are sent via SNS.
An ECS cluster using dynamic ALB, with a base service deployed by a sample definition. A system which consumes SNS for notifying users (not provided) A lambda function which handles deployment (can be blank)
npm install -g serverless sls plugin install -n serverless-step-functions sls plugin install -n serverless-pseudo-parameters sls plugin install -n serverless-prune-plugin
sls deploy -s dev
- Add API Gateways's endpoint as GitHub's webhook (https://xxxx/github)
- Configure trigger events (create, delete)
To receive Slack notifications, create a lambda function which consumes the notification SNS and posts to Slack. Example here: https://github.com/ijin/sns-slack
Notification is de-coupled, since including the function in this project will create unnecessary duplicates for multiple configurations.
The deployment lambda fits to your project's needs. If using CircleCI, you can simply call the API with
build_parameters[CIRCLE_JOB]=build from lambda. Tasks may include databae migration, data loading, etc. A blank lambda function can be set if deployment is unnecessary.
It's best to only build on pull requests if you use CircleCI for deployments to avoid double runs.
You can also manually create environments through chatops.
- optionally disable github's create trigger
- create a serverless framework stage environment (this will be your trigger word. ex.
- configure slack's outgoing webhook to the API gw path (https://xxxx/chat_ops) and set the trigger to the above stage (ex.
dev) in a desired channel
- create an environment by typing
dev feature/test) in the configured channel