October 2020
What's new on Release?

October 23, 2020

New Features

✨ Now Introducing the Application Dashboard!

Previously, an application had pages but nothing to tie those pages together. This made it difficult for a new user to navigate. They didn't have a clear path to discover their application. There was a need to let users step back and view their whole application at a high level.
The Application Dashboard is your application's landing page. On this page, you have quick links to the major Application pages that you are already familiar with, an assortment of widgets, and an activity feed.
The Widgets show you your environments--how many you have, their types, and their statuses. The Activity Feed shows the application's builds and deploys and the current status of those. Both the widgets and the activity feed are updated in real-time to reflect the current status of your application.
We will continue to monitor, adapt, and grow this page.

Introducing Subdomain Wildcard Routing Beta!!

It is not unusual to have a large amount of wildcards you might want to support for your website. This could be subdomains to support your production-like routing, or could support use cases only for testing before production. For example, you might want to use a country-code subdomain for specific languages supported on your site:
Or, you might have a long laundry list of categories that your site supports for SEO and you want to verify all the links work before production is hit:
Lastly, you might have subdomains that you customise for customers, employees, or other tenants on your own custom self-hosted domains:
In the above cases, if there are only one or two subdomains, you could easily list them one by one in your application configuration. But if the number of subdomains is not known in advance, or can change and grow over time, or if there are simply too many of them to manage manually, you can now create a wildcard subdomain that will be routed automatically to your dynamic or static site, no matter what subdomain is used.
The best part is that we manage all the DNS, routing configurations, SSL certificates, and deployment complexity in real-time for you so your use case just works!
Although the routing configuration works and customers are using it, this is a new feature so we're still working on improving the ergonomics of the configuration interface. If you need this feature or want to see it in action for now, please reach out to us to get it setup and tested. We'll add it to the documentation once it's fully vetted.
Just-in-time File Mounts
Just-in-time File Mounts allow you to mount a file within a container at a specified mount point when your container is created. This allows you to have configuration files that you don't check-in to your source control repository that are accessible to your services. A good use case for this helpful is when you have secrets stored in a file that you'd rather not checkin to your repository (and if you're doing this, stop!). When you check the 'secret' box within the Just-in-time File Mounts dialog, that tells Release to encrypt and store the file securely.
You can find Just-in-time file mounts in your App Settings and in the Advanced section when you create a new application.
Customer account management
As an account owner, you can switch your fellow team member's role from "member" to "owner" which allows more permission levels such as editing the Application Template.
Switching User Role Example

Bug Fixes and Other Improvements

  • Fixed a bug in static builds where an S3 path with a plus sign ("+") would be interpreted as a space by the browsers. If you do notice any issues with strange characters or symbols in a path, try to avoid using them and also let us know so we can try to deal with them.
  • Secondary email addresses for Github are now supported. If you logged in with your non-primary email address, Release wouldn't validate your email and now we do!

October 9, 2020

New Features

It's been awhile since we announced what's new on Release, but that's not because we haven't been heads down working on improvements. In fact this week we released a major overhaul of the experience that changes some of the fundamentals that we've realized were important as we've worked with many of our customers. This update will be longer than most but it's worth the read!
Static Javascript Frontends
We've had a lot of fun learning from our customers. It's amazing what everyone is building. We get to see all of the cool ways people are building technology. One thing that we've bumped up against repeatedly is most customers have a Javascript SPA for their frontend. Typically these are deployed to a CDN in production and served. That creates a pretty decent challenge for building environments. They don't fit neatly into a Docker/container strategy. For our early users, we hacked our way to a solution... usually doing static builds out of a frontend container and either hosting from within the container or pushing to a CDN as a job. It was pretty custom.
We decided to add full support so we can build and deploy Static Javascript Frontend environments right alongside our existing Docker based environment solution. This lets users with complex, hybrid Docker/Javascript apps have on-demand environments that look just like production with frontends hosted out of a Cloudfront CDN and backends/APIs running out of containers.
Release manages all aspects of building, deploying, updating DNS, Cloudfront and connecting frontend apps to the rest of the services within their environment.
We've made major changes to creating application in Release to make creating complex applications dead simple. Take a read through our Static Service Deployment reference for more information.
Here are a couple great examples that show off what you can do with Static Javascript Frontends
Enhanced Application Templates
Every environment in Release is derived from the Application Template. The Application Template is a YAML description of services, hostnames, networking, environments. This template is what all created environments are derived from and is their starting point. All new environments use this template and pull their initial settings from here. In this update, the Application Template has been enhanced with a ton of new capabilities.
Modifiable Environment Configurations
We've also added modifiable Environment Configurations. This allows you to modify an instantiated environment beyond its initial settings inherited from the Application Template.
This was a major change in the system, prior to this update there was no way to modify a running environment's configuration without updating the Application Template. This was a big limitation that made it impossible to change a running environment without impacting other running environments. Any change to the template was immediately applied to subsequent deployments of other environments which made experimenting with an environment impossible. If you're interested, read through our Environment Settings reference to dig deep!
With Application Templates and modifiable Environment Configurations Release environments are infinitely flexible and approachable. Feel free to tinker and experiment with your environments.
Last modified 9mo ago