Developing with Velocity
Velocity supports two approaches to developing Velocity Services deployed in your Velocity Environment.
You can either replace a remotely running process with a locally running process that is networked to your Velocity Environment with Velocity's Env Develop feature, or you can keep the Velocity Environment running exclusively in your Velocity Context, and sync code changes you make locally to the remote environment with the Env Sync feature.
Velocity's Env Develop feature allows developers to debug and develop Velocity Services locally, within the context of the larger, remotely-running application.
This workflow simplifies the process of developing individual Velocity Services for developers who prefer to work on their local machine with a development process and tools they are already accustomed to.
It also reduces the required local compute resources by leveraging a remote Kubernetes cluster to run any additional processes the Velocity Service being developed may require.
The
env develop command works by stopping a remotely running Velocity Service, and replacing that Velocity Service locally with a local process that is reading from local files. This local process is networked to the remote Velocity Environment, so that code changes in these local files are reflected in the full Velocity Environment. Velocity supports this workflow using the
env sync command, which monitors a local folder on your computer, identifies when files are changed, and automatically synchronizes them with your running remote Velocity Environment. This approach is useful for the following reasons:
- Lower latency - If your application communicates with external services, developing and debugging locally introduces latency between your computer and the external service endpoint.
- Reduced resource consumption - If your application consumes a lot of resources, or if your local machine is low on resources, the development and debugging experience can degrade.
- Reduced drift - Developing and debugging your application on the remote container bears a lower level of drift than offloading it locally. The container configuration stays the same as in the cloud, and you do not need to install specific environment tools in a specific version.
For use with compiled languages (such as .Net, Golang or Rust). Velocity will detect the code changes, trigger an image rebuild, and update and restart the remote running service, making your application reflect the changes.
- 1.Trigger an image rebuild
- 2.Publish the image to a container registry hosted in your Velocity cluster
- 3.Pull the image and restart the container
- 4.Sync the logs back to the command line output, to allow you to identify problems that might have occurred when building and deploying the new image.
For use with scripted languages (such as Python). Velocity will push updated files to the remote service, making your application refresh and reflect the changes instantly.
In this mode, your local directory will be mapped with a single directory in the remotely-running container, and with every detected file change, Velocity uses rsync to copy the changed files to the remote container.