Release Environments are created based on a Release Application Template and Environment Variable defaults that define your application and its environments.

Release can automatically generate these templates or you can write them on your own from a library of examples of common frameworks. We generally recommend letting Release analyze your repository and automatically generating them as a starting point.

We currently support the following mechanisms to create your Release Application/Environment Variable defaults:

• Write your own templates from a library of examples for common frameworks and services.

• Automatically generated by parsing docker-compose.yaml files found in your repository

• Automatically generated by parsing package.json files for Javascript applications

• You can bring your own Kubernetes yaml and environment definitions can be derived from them

• Helm charts

You can create an infinite number of development, staging, demo and production environments without ever having to deal with the underlying infrastructure. These environments can then be automatically generated and updated whenever you push a code change or create a PR. They can also be manually deployed via the Release user interface.

Developers generally interact with Release by creating a Pull Request in their VCS (version control system) and Release will automatically create an environment with the code changes in the PR.

In addition, organizations can create permanent staging and production environments and automate all of the steps from code push to running in production.

Prerequisites to running an application in Release

Frontend Javascript Applications

1. A package.json file containing a build command in the scripts.

Container Based Applications

1. A working Docker build. See Docker builds.

2. A definition of your application in a docker-compose.yml.

3. Your application's source code is checked into a VCS (i.e. Github/Bitbucket).

4. For OAuth based VCS integrations (Bitbucket) you'll need a user who has admin permissions on the repository to install webhooks and deploy keys. For Github, we use Github Apps and the app authorization handles the management of the repository.

5. Admin access to an AWS account where you'd like your environments to run.

Core Concepts of Release

Static Sites

Release supports standalone static sites running without Docker backends. These sites are pushed into a CDN and hosted on your behalf. See Static Service Deployment for more information.​

Docker & docker-compose

Release builds services running in Docker containers derived from your docker-compose.yaml file. Your application can have any combination of one or more services. For more information about creating an application that builds via Docker and docker-compose please see these useful reference guides from Docker.

• ​Docker overview​

• ​Getting started with Docker​

• ​Building with Dockerfile​

• ​docker-compose overview​

In order to run Docker based applications in Release, there needs to be a working Docker build and a docker-compose file that will run all of the services needed.

Hybrid Sites (Static Sites + Docker Containers)

Release supports applications with both static frontends with other Dockerized services. Static applications are defined in a package.json while your other services are defined through a docker-compose.yaml file. When both of these are present in a repo, Release will automatically detect and provide you with options to build these services correctly. Release manages all facets of creating environments and connecting frontends and backends together seamlessly.

Connecting to Your Cloud Account

Release supports running environments in your AWS account through the creation of a Kubernetes cluster using AWS Cloud Formation templates. This cluster will be fully and remotely managed by Release, meaning you don't need to know anything about Kubernetes to use Release.

To integrate your cloud provider with Release, you will need to go to your Account Settings > Integrations where you will be walked through a simple setup to connect your AWS account to Release.

*Currently Release only supports AWS.

The Application Template

Release automatically generates an Application Template for your app. This is created from your docker-compose file (and package.json file for your frontend javascript applications). This file defines the following high level concepts (see the Default Environment Configuration Schema for the full schema):

• The Kubernetes cluster your application is running in

• The domain where your application will be running

• Templates used to create ephemeral and permanent environments

• Hostnames where your application will be publicly accessible

• Resources allocated to your services

• Application services

• Application jobs (i.e. running migrations or other scripts)

• Application workflows

This configuration is automatically generated when you create your application and contains smart defaults that will allow your application to run. Release has been designed with minimal configuration in mind, but every application is unique and the application template allows developers to customize their application to suit their needs.

Webhooks

Webhooks are calls made from your VCS back to Release when certain events happen. This tells Release there is something of interest to pay attention to in your repository and kick off automated workflows in Release. Release listens to webhooks for the following actions:

• New pull request

• Pull request closed

• Pull Request re-opened

• Pull Request merge

• Code pushed to repository

The user account that creates an organization's Release account, must have Admin privileges for the application's repository. See Github permissions and Bitbucket permissions for more information on setting up a repository to allow the proper webhooks for Release.

Ephemeral Environments

Ephemeral environments are environments that live for the life of a Pull Request or are created manually. These environments will automatically track the branch from your Pull Request. An ephemeral environment is given a unique URL for each service. This allows developers to share work-in-progress development with stakeholders easily. Ephemeral environments are designed to be close replicas of production environments.

See the full documentation on Application Templates.

Permanent Environments

Permanent environments are environments that are not destroyed. Typically they are for more traditional staging or production workloads. These environments get static URL's that are based on the domain field in your application template. They can be set to track a branch and deployed automatically on a code push to your source control system, or they can be deployed manually.

See the full documentation on Application Templates.

Where do the applications and environments run?

Release Starter Account applications are hosted within the Release cloud. Professional and above accounts host applications running on a Kubernetes cluster in your AWS account (optional) and static sites hosted out of Cloudfront. Release remotely manages the cluster and CDN so your teams can focus on building your applications.