Visual Studio Code

This guide will help you get started with Velocity from 0 to your first remote debugging session and a breakpoint hit

Prerequisites for Velocity Development and Remote Debugging

Before you start developing and debugging with Velocity, ensure you have the following essentials:

  1. Kubernetes Environment: A running Kubernetes cluster hosting the service you intend to develop or debug.

  2. Cluster Permissions: Necessary permissions for the Kubernetes cluster, such as the ability to deploy Pods.

  3. Visual Studio Code IDE version v1.79.0 and above

With these prerequisites in place, you're all set to leverage Velocity for your development and debugging needs.

Installation

To install the Velocity plugin, navigate to the VSCode extensions tab, search for Velocity, and click "Install".

After installing the Velocity plugin, it will download any required resources, and the Velocity Getting Started walkthrough will launch.

To start working with Velocity, you can follow the steps of the walkthrough or follow this guide.

Log in to Velocity

Click on the "Login to Velocity" button, choose your preferred login method, and complete the login flow. Once you are logged in, you can go back to the IDE.

Create your first run configuration

Once logged in, you will be asked to open a folder. Make sure that the folder you choose is matching to the workload that you would like to develop.

Next, let's create your first Velocity Debug Configuration- Velocity works with native Visual Studio Code Debug Configurations.

If you are working as part of an organization with pre-configured Velocity configurations you can choose the option of "Start from a Base Configuration". If not, choose the "Create a new configuration״ option and the onboarding wizard will launch.

In the first screen of the wizard, you will be asked to choose the programming language you are developing, and between creating a configuration based on an existing workload or a dockerfile. For this guide, choose "Based on Dockerfile"

In the next screen of the onboarding wizard, you will define the "where" and the "what" of the workload that you are developing

FieldDescription
  1. Configuration name

It's recommended to choose a name that suggests the goal of the Run Configuration

  1. Dockerfile

The path to the Dockerfile associated with the service you're developing.

  1. Build context path

The build context is the set of files that your build can access. The positional argument that you pass to the build command specifies the context that you want to use for the build. Read more here

  1. Kubernetes context

The Kubernetes cluster you're working in.

  1. Kubernetes namespace

The namespace in which your deployed service is running

  1. Kubernetes workload

The specific Kubernetes workload you are developing

The fields shown above are auto-populated by Velocity. Confirm that the selections in the fields shown above are correct, or update them as needed, and click "Next."

In the next screen of the onboarding wizard, you will help Velocity to understand how to build your Dockerfile.

If your targeted workload doesn't require these additional options, you can simply accept all defaults and click on "Create"

  1. [Optional] In case the build step of the application is outside of the dockerfile, you will be able to provide the build command so that Velocity will be able to build it and copy it into the new image.

  2. [Optional] In case your dockerfile requires any build arguments that would be passed with the --build-arg flag in a docker build command, you will see a list of expected build arguments.

    For example, if your Dockerfile includes the ARG instruction, it is setting a variable that is passed as a build argument. If you were to build this Dockerfile locally, you would pass the --build-arg flag; however, with Velocity this build argument is supplied in the Velocity Setup Wizard, as follows:

  1. [Optional] If your dockerfile requires SSH key to access private packages or repositories during the docker build process, you'l be asked to choose the SSH key. If this option is not visible to you, it means that your dockerfile doesn't require SSH key and you can continue

When you click "Create," a new Velocity Run Configuration will be created and you will be ready to start your first Velocity development session

The Velocity development session

Once you have a Velocity Debug Configuration ready, you can start your first Development Session. To start the session, open the Velocity side panel and hit either Run or Debug

  1. Run- Builds an image with your code and deploy it to the remote environment. The remote pod now runs with the logic you have in your local IDE. Any code change will be synced to the remote environment and the workload will be updated (see Making your first code change section)

  2. Debug- The Debug mode includes everything in the Run mode + the ability to debug the application that runs on the remote environment. (see Hitting your first breakpoint section)

Your development session is ready when your Kubernetes Pod logs, or a "Debugger attached" message, is printed in the Velocity output.

Making your first code change

Once you see logs coming from your application, it means that your application is ready and you can start developing with Velocity.

To make a code change and have it synced to the remote pod:

  1. Make the code change you would like to apply

  2. Save the changes

  3. In the Velocity toolbar (right above the terminal) hit or

  4. Once you see the logs coming from your application, it means that the new code is already running in the remote pod

Hitting your first breakpoint

After clicking the button associated with your newly defined Velocity Run Configuration, you simply need to set a breakpoint in your IDE as you would if you were debugging locally. Then, you can interact with the remote breakpoint just as you would locally.

Ending a Velocity development session

When you complete a Velocity development session by clicking the "Stop" button, the Velocity-built image is torn down, and your original image that was running prior to the Velocity development session is restored.

Last updated