By nature, Ephemeral Environments have always been temporary spaces that will expire and be discarded in a relatively short time span, say 1 week. We added a new feature that displays how long the environment will last and a button to extend it for a longer period of time. When you manually create environments in Release, you can now specify how many days and hours you want it to persist before being discarded. When your environment is on the verge of expiration, Release will send you an email 24 hours in advance to let you know.
We have completely revamped our build system from a homegrown solution to use BuildKit (https://github.com/moby/buildkit) as the way to build and distribute container images. We have been using BuildKit internally at Release over the past month and have noticed blazing fast build times between 20-50 seconds for most code changes.
BuildKit provides multiple caching mechanisms and pushes images directly to your docker registry. If you would like to use BuildKit for your application please reach out to us and we will enable your application and ensure that your builds are blazing fast too.
If you like going slow, that's fine too, we won't judge you. 🐢💨
Over the course of the last year, we have seen customers build out amazing ideas using Release. As your business scales, so does Release. One of the patterns that we have seen across our customer base is that as teams grow they need to create new versions of their micro-service or application.
Historically teams that were integrating with another team's application would share the repository and builds. We noticed that this was confusing to development teams. When they created their version of another team's application, they would see all of the builds that had already been created by the other team.
We have listened to the feedback, and applications will now all have their own build for a given GitHub repository. We have already seen the increased velocity across teams, by letting each team work independently and autonomously.
Many of our customers are running production workloads with Release. Historically, they have used the application config to adjust the number of replicas to handle peak traffic conditions. It's very simple to manually add replicas with Release in your production environment and scale your site to meet customer demand.
But what happens when a customer of yours, in New Zealand, throws thousands of employees at your site in the middle of the night to build their latest report on COVID-19 without your knowledge?
Now, you don't have to worry about manually scaling your site. Release now supports horizontal pod autoscaling to scale up and down your production workloads while you are sleeping comfortably in your bed.
Please reach out to us here at Release to learn more about this feature and help drive the roadmap for autoscaling your production workloads.
Release has integrated with Github Labels to allow users to create environments by applying a label to their Pull Requests in Github. Turn on this feature in your Account Settings and read the full documentation on our Pull Request Labels documentation page.
Previously, build arguments could only be entered globally from the account settings and it would affect every app tied to that account. Now, with App-Level Build Arguments, we have the ability to inject build arguments directly into a specific app as needed. This allows for apps to have their own relevant, unique build arguments that can be isolated in a single place, which supports things like secret variables. You still have the ability to enter global build arguments into the account settings too.