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
Named the same as the Github application; it is derived from the git remote origin URL. Contains Beanstalk environments.
For each application there is an S3 bucket with the same name as the application used for storing the Application version packages.
Note
This S3 bucket must be in the same AWS region as the Beanstalk application.
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.
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}
.
Note
The RDS instance and security group are not otherwise tied to the Beanstalk environment and therefore need to be manually removed or unlinked (via the security group) from the environment before it is terminated.
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).
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}
.
Note
Version names have a length limit of 100 characters.