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.
Release now supports the
Failure states for the Github Deployments API.
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.
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.
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.
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!
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.
---name: migratecommand:- "./migration.sh"from_services: backendhalt_on_error: truecompleted_timeout: 600 ##600 seconds
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.