The running version, or instance, of your application. An environment can span both local and cloud-hosted resources, and it contains the various services that make up your application.
An indication of where an environment is deployed:
- A Velocity-managed cluster.
- A remote cluster, such as Amazon EKS.
- An on-prem cluster, such as a shared staging cluster that exists in the organization.
- A local development cluster: such as a local MiniKube.
An indication of how an environment should be deployed. A blueprint holds all the definitions needed to create ephemeral environments, including services, dependencies, and other deployment configurations. Velocity's blueprints are defined using industry-standard formats such as Kubernetes Resources, Helm, and Kustomize augmented with Velocity annotations and templates.
Velocity presents a visual representation of your environment blueprint.
Blueprint definitions may come from different locations, such as GitHub repositories, CD pipelines, and even Velocity's Catalog. Velocity merges together these definitions into a single blueprint that represents your environment configuration.
A blueprint source represents a configuration of one or more resources, which are imported from the same location and updated together.
For example, the worker blueprint source in the image below is located in a GitHub repository, it consists of a Helm chart and values files. With every update to this blueprint source, the three services (backend-cache, backend, and backend-queue) will be updated together.
Velocity uses an operator installed in your Kubernetes cluster to spin up isolated ephemeral environments. The operator pulls environment requests and manages the environments in your cluster. Once an environment is running, you can directly interact with it.
A single application, or process, without its dependencies. A service can be a micro-service in a complex micro-service architecture, or a large self-contained monolith without external dependencies.
Developing services refers to changing one or more services in a development session and testing them using an ephemeral environment.
Velocity supports two development modes:
- 1.Develop code using a Hybrid Environment: Develop code locally with remote dependencies running in the cloud environment.
- 2.Develop code using a Remote environment: Run a full environment remotely while syncing local file changes with remote containers (hot-reload).
When you create a new environment in Velocity, you only need to specify the services you wish to develop. These are your development candidates. Velocity will automatically detect all their dependencies and will provide you with a working environment for the selected development candidates.
The Portal is a long-living process that runs in your local computer in the background and manages all the tunnels between your local machine and the remote environment.