We've been listening to customers and a common request has been users want more control over the security and access Release has to repositories. Our initial implementation used Github oAuth, but there are limitations with access controls. So we decided to make a switch to GitHub Apps which give you have full control over what you want Release to have access to. This allows you to also revoke permissions from Release to any repositories.
View from GitHub.
Release shines in multi-service applications. You probably have a frontend, a backend, a database, some API's and potentially numerous services that have external hostnames. But generally there is a main link into your app. Usually it's a frontend website or some URL that users mainly interact with. Since a lot of Release users only care about this primary URL, you can now choose which link is the Primary App Link so Release can use it throughout the user experience correctly (a good example of it's use is via our Github Deployment integration).
If you're interested in using Github's Deployment feature, you can now have Release manage the deployments for you.
Deployments are defaulted to off in your Account settings, flip the switch to on and you'll see the deployments start flowing on Github!
Deployed button will take you back to Release to view the logs on the deployment, where as the
View Deployment button will take you to your live site! The other great thing about using Github Deployments is it automatically updates your "Environments" in Github so if you'd like to see every environment that is live on Release through Github, turn on the Github Deployment updates setting on your Account.
If a Deploy is running and you realize that you've triggered the wrong thing, you can now instantly abort via a button in the Deploy Info section. Release will check as often as possible on whether or not the Deploy should be aborted.
Aborted deploys are clearly marked with a yellow badge and should stand out from your successful deploys.
What is a "sidecar"? It is a container that sits "next to" or "beside" another container inside a pod. A pod can have many containers, but the usual practice is to have a single working container inside a pod. If you bundle more than one container inside a pod, the "extra" containers are referred to as "sidecars". All of the containers in the pod will share the same filesystem, network ports, routing, process space, and so on.
What does a "sidecar" do? There are a few patterns related to sidecars you can read about on the internet, but several examples of common sidecar implementations involve serving content with Nginx or other proxies, offloading log aggregation and handling, running shared or third party agents, or running custom monitoring stacks.
Release now supports sidecar containers with the easy addition of a
sidecars attribute as shown here to add a common nginx container and a custom logging container from your own registry:
services:- name: frontendimage: kornkitti/express-hello-world:masterports:- type: node_porttarget_port: "80"port: "80"volumes:- name: nginx-logstype: empty_dirmount_path: /var/log/ngnixsidecars:- name: nginximage: nginx:1.7.9- name: logtailfrom: nginx-logtailersidecars:- name: nginx-logtailerimage: docker.elastic.co/logstash/logstash:7.10.1command:- tail- "-f"- /var/log/ngnix
If you didn't know already, at Release we're all about environments, but the phrase 'Ephemeral Environments' may be new to you. We wrote up an informational page about what Ephemeral Environments are and how they might be used at a fictional company. What is an Ephemeral Environment?
How can Product Managers, Designers, QA Teams, and Product Stakeholders gain the most from Release? User Acceptance Testing with Ephemeral Environments describes how Release Ephemeral Environments are used for many use-cases ranging from sales demos to UI/UX design to user studies.