Search…
April 2021/May 2021

New Features

New Product: Support for customer VPC Deployments

Environments are the heart of Release. Release is able to generate environments on-demand for any pull request as well as power production environments all running within your cloud provider. We have found that many customers have production environments that extend beyond their own cloud provider. Working with these companies we have developed the ability to deliver your SaaS based software into your customer cloud account.
Release VPC deployments can directly interact with your customers data and provide your customers with the peace of mind that everything is running with their cloud account. If you are thinking about delivering an enterprise version into your customer's cloud account talk to the folks at Release.

Better support for Github Deployment Statuses

Release now supports the Pending, In Progress, Success, and Failure states for the Github Deployments API.
Github Deployment in the Pending state
Github Deployment in the In Progress state
Github Deployment in the Success state
Github Deployment in the Failure state

Support for Windows Worker Nodes (AWS self-hosted customers)

Release can now deploy Windows 2019 and 2004 worker nodes with AMIs that are supported by Amazon EKS. This allows customers with self-hosted clusters to deploy Windows workloads, including IIS and .NET applications. Windows worker nodes can be managed, patched, and configured with our previously announced SSM support.
Read the AWS documentation for supported versions.

Deployment by Tag vs Branch

It’s now possible to build and deploy an environment using a repository tag. Some customers like to keep version tags and only deploy those specific tags, rather than deploying an entirely new branch on every push. There are two ways to build and deploy an environment tag: 1) from the Builds screen where you can toggle between a tag or branch, or 2) when you manually create an environment from the Environments screen.
Toggle between Branch or Tag when creating a new build.
Toggle between Branch or Tag when manually creating an Environment.

Automatically Generated Release Environment Variables available during app creation.

Release generates environment variables for you that can be required to get your environments up and running. In the past we did not expose the names of all of these variables for in your environment variable templates. If you knew what they were you could use them, but it wasn’t obvious. Now in Release when you create your application we will generate comments in your environment variable templates exposing each of these variables to you and showing examples of how mapping works.

Contributors on Open Source projects managing environments with release can see Environment Details screen

Open source maintainers love to use Release. Preview environments make it easy for maintainers and contributors to confidently create pull requests that deploy to ephemeral environments, allowing the maintainer and contributor to witness what these changes would look like when merged.
Now contributors can see their build logs and environment status without needing to hold a Release account or be part of the maintainer’s organization inside Release.
Are you an open source maintainer that could benefit from ephemeral environments? Drop us a line, we would love to hear from you!
GitHub Pull Request
Release Open Source Build Logs and Environment Status

Configurable Job Timeouts

Setting timeouts for service deployments is often crucial to making your deployments work correctly. In the past we didn't have configurable timeouts for jobs in Release, but we do now!
By default your jobs have a timeout of 180 seconds but you can change that by using the completed_timeout directive in the jobs stanza in your application template or environment configuration.
1
---
2
name: migrate
3
command:
4
- "./migration.sh"
5
from_services: backend
6
halt_on_error: true
7
completed_timeout: 600 ##600 seconds
Copied!

Support for Secondary Email addresses

Many users like to keep their work repositories and inboxes separated from any personal side projects. This new feature enables users to switch between work and personal email accounts that might be stored on their GitHub or BitBucket accounts. To access this feature, go to the upper right and click on Manage Profile, then you can switch between different email accounts.
Switch your primary email address for ReleaseHub notifications.

Blog Posts

Last modified 4mo ago