Remote development enviroments

With Release remote development environments, you can "mount" an ephemeral environment to your local computer and work on it as you would if you were developing locally.
You work in your preferred IDE and when you save, Release automatically syncs your changes to the server. If your server is configured with live reloading, your changes will appear in near real-time.
You can mount your database to a local port and use your favorite database GUI tool to interact with it.
Setting up a remote development environment
We'll guide you through setting up a Release remote development environment with just a few lines of YAML.
Prerequisites
To set up a remote development environment, you need a working, deployed application on Release. If you don't already have a working application, follow getting started in the Release documentation and then create one of the Release example applications. In this guide, we use the full stack voting app to demonstrate setting up a remote development environment.
You will also need to have the Release CLI and the AWS CLI version 2.8.11 or higher installed.
Configuring your Application Template
The Application Template defines a top-level block named development_environment in which you can specify how the application should behave in development mode.
Here is an example development_environment block from the full stack voting app:
development_environment:
  services:
  - name: vote
    command: python app.py
    sync:
    - remote_path: "/app"
      local_path: "./vote"
    port_forwards:
    - remote_port: 80
      local_port: 5000
  - name: result
    command: nodemon server.js
    port_forwards:
    - remote_port: 80
      local_port: 5001
    sync:
    - remote_path: "/app"
      local_path: "./result"
If you're following along with an example full stack voting app, add this code to the top level of your Application Template and click Save as new version.
Using a different container image for development
You might prefer to use a different container image when running a service in development mode. This is useful if you have development-only tools or dependencies you'd prefer not to include in your production images.
To use a different container image for development mode, first add a top-level builds stanza to your Application Template specifying the Dockerfile or multistage build target you would like to use:
builds:
- name: vote-dev
  context: vote
  dockerfile: "./Dockerfile"
  target: dev
Then specify an image for your development_environment service:
development_environment:
  services:
  - name: vote
    command: python app.py
    image: my-org/release-example-voting-app/vote-dev
    sync:
    - remote_path: "/app"
      local_path: "./vote"
    port_forwards:
    - remote_port: 80
      local_port: 5000
Connecting to a development environment
Once you have configured your application for remote development, run release auth login in the Release CLI.
Select the app you want to use with release apps select.
In the root of your local copy of the repository you want to debug, kick off the remote dev process with release dev start --environment ID_OR_NAME.
Once everything turns green, you should be able to access http://localhost:5000 and http://localhost:5001 returning the vote and result services respectively (or whichever ports you configured for your application).
Now you can edit files locally, refresh the browser, and see your changes. You can view and tail the logs in the ~/.releasehub/dev/ folder to see the output of the different commands.
Debugging a development environment
The commands tail their output to log files in ~/.releasehub/dev/ENV_ID/. Use tail -f log-servicename.txt to see the output of the command running on the server.

Last modified 1mo ago