A deployment tool for deploying Digital Marketplace applications to Beanstalk.

Install with pip:

pip install git+https://github.com/alphagov/digitalmarketplace-deployment.git

dm-deploy uses boto under the hood. AWS credentials can be provided to boto in few different ways, check their config tutorial for more information. At the minimum you will need an access key ID and a secret access key.

View the dm-deploy help to verify the installation:

dm-deploy --help

Navigate into the project you want to deploy:

cd ../digitalmarketplace-api

If your project has not been set up in Beanstalk yet you will have to bootstrap it. This will create:

• An S3 bucket for storing application versions
• A Beanstalk application named after the Github repo
• A Beanstalk configuration template named default

For each environment it will create:

• A security group for the RDS instance named db-{app sha}-{environment name}
• An RDS instance named db-{app sha}-{environment name}
• A Beanstalk configuration template inheriting from default with the RDS database details.
• A Beanstalk environment named {app sha}-{environment name}

Environment variables can be added to the default configuration template from the current environment with the --proxy-env argument. In the example below the FOO and BAR environment variables will be taken from the current environment and added to the configuration template:

dm-deploy bootstrap --proxy-env='FOO,BAR'

To create an ephemeral environment for a feature branch use the deploy-to-branch-environment command. This will create a development version, a development environment with that version and an associated RDS instance. If a branch is not explicitly provided then the current branch name will be used:

dm-deploy deploy-to-branch-environment

When the ephemeral environment is no longer needed it can be removed with the terminate-branch-environment command. If a branch is not explicitly provided then the current branch name will be used:

dm-deploy terminate-branch-environment

When we want to deploy a new version of the application to staging or production we need to explicitly create a new version with the create-version command. The new version will be created from the current HEAD:

dm-deploy create-version release-1234

Once we have a version label of the form release-{ something } we can deploy it to staging and production. The following command will deploy the most recent 'release' version to the staging environment:

dm-deploy deploy-latest-to-staging

Then we can deploy the version that is currently deployed to staging up to production:

dm-deploy deploy-staging-to-production

AWS documentation

Named the same as the Github application; it is derived from the git remote origin URL. Contains Beanstalk environments.

AWS documentation

For each application there is an S3 bucket with the same name as the application used for storing the Application version packages.

AWS documentation

Beanstalk environments are named {app sha}-{environment short name}. {app sha} is a short unique identifier for the application, this is needed because environment names must be unique across all Beanstalk applications. {environment short name} is the environment name we use; for example staging or production for our permanent environments or dev-{label} for ephemeral environments.

Each environment has it's own RDS instance associated with it, see RDS instance.

Each environment has a configuration template called {environment name}, see Configuration template.

AWS documentation

An RDS instance is created for each environment and named db-{environment name}. The associated Beanstalk environment is given access to this via a Security group also called db-{environment name}.

AWS documentation

When a new application is bootstrapped a configuration template called default is created and local environment variables can optionally be added to it. A configuration template inheriting from this one is also created for each environment which contains the RDS details (connection information and credentials).

AWS documentation

An application version is a package (zip file stored in S3) containing application code with an associated version label. The package files are named after the full git commit sha that they represent. When bootstrapping an application a version called initial is created all other versions are named as follows:

• Release versions should be called release-{build number}.
• Ephemeral versions will be called dev-{label}-{short commit sha}.