Remote Development enviroments

Release's remote development environments allow you to "mount" an ephemeral environment to your local computer, and work on it as you would if you were developing locally.
You use your normal IDE, and when you save, we automatically sync your changes up to the server. If your server is configured with live reloading, your changes will appear in near real-time.
You can mount and access ports on your machine, mount your database to a local port and use your favorite database GUI tool to interact with it.
Setting up a remote development environment is straight forward and takes just a few lines of yaml.
Setting up a Development Environment
Prerequisites
First things first, you need a working, deployed application on Release. If you don't already have a working application, go through the Getting Started section in the Release documentation and then through the an Example application tutorial. The Full stack voting app is a good place to start.
You also need to have at least version 2.8.11 of the AWS cli installed.
Configuring your Application Template
The Application Template schema definiton defines a top-level block named development_environment. In brief, you use this to override how the application is normally deployed, and how it should behave instead when using development mode.
Here is an example development_environment block that works for the Full stack voting app referenced above.
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"
Plug this in to the top level of your Application Template. Click Save as new version.
Using an Alternate Image for Development
It is possible 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 like to avoid including in your production images.
First add a top-level builds stanza to your Application Template specifying the Dockerfile and/or multi-stage 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 Enviroment
Now that your application is all configured, it's time to start developing!
Make sure have installed the Release cli and run release auth login.
First, select the app you want to use with release apps select.
Finally, from within 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).
You should be able to edit files locally, refresh the browser, and see your changes.
Finally you should be able to view and tail the logs inside the ~/.releasehub/dev/ folder to see the output of the different commands.
Debugging a Development Environment
The commands tail their output to log files inside ~/.releasehub/dev/ENV_ID/
You can tail -f log-servicename.txt to see the output of the command running on the server.

Last modified 5d ago