Creating production-like environments is an important best practice for developers to work effectively, debug and test their code before reaching production.
Traditional Staging is Not Enough:
Staging environments are an important place where you validate and test code in an environment that is almost like production. However, these processes become much more difficult when you’re dealing with more complex architectures such as microservices and cloud-native applications.So what happens when something changes in your applications' production infrastructure? Or multiple dependencies need to interact and integrate with different components?Velocity is set up to read, analyze and sync your application infrastructure and provision on-demand, production-like environments in real-time. So no matter how many components need to be integrated for you to develop or debug a feature, you will still have access to all that environments' dependencies. And you get the autonomy to create these environments as often as you need, so there is no need to be blocked by any bottlenecks that come with a shared, staging environment.
How Velocity Works
Velocity lets you move fast and deliver better products, with the autonomy to spin up fully isolated production-like environments on-demand.
Using read-only access, Velocity connects to your source control, CI/CD, and cloud account to extract the relevant information and automatically identify your environment’s dependency graph
Developers provision their own environments, working on their own machine while the rest of the environment is running on YOUR CLOUD
On-demand environments are continuously synchronized with the definition of production, so environments are always kept up to date. For example, if you change the docker-compose, Kubernetes resources, or helm charts, Velocity will identify the change and sync automatically.
Destroy environments, or enable time-to-live, when you've finished using your environment. You can check status and logs to enable maximum resource utilization.
Why should I use Velocity
Work locally with your existing dev toolbox:
Instantly spin up self-served ephemeral environments as part of every pull request. Work locally in your IDE to develop and debug, while your application’s dependencies run remotely. Self-serve also eliminates the bottlenecks of waiting for other teams to create environments, as every developer can create their own production-like environment, automatically, when they need it.
Work with your current tools:
Velocity automatically maps and configures your application infrastructure so you can develop and test multiple services in an environment that runs just like it would in production. Velocity is fully agnostic to your cloud and tech stack, as opposed to just focusing on Kubernetes-only environments. This means working on applications in parallel without disrupting one another, with full access to data and 3rd party dependencies.
Automatic Configuration & No Maintenance:
Velocity automatically configures and updates any changes within the production infrastructure’s mapping in real-time so ephemeral environments will always be synced with what is in production. Instead of having to spend time making sure any changes are configured, you will always have the right environment that replicates production, without having to wait.
Data & 3rd Party Dependencies:
Environments are complex, and don’t end with just the cluster. There are many additional elements such as AWS DynamoDB and Google Pub/Sub, and other 3rd party resources that are vital parts of the environment to test, work and debug against. Having the relevant data inside ephemeral environments is crucial to reflect real use cases that will occur in production. Velocity loads the relevant data so environments will be as close as possible to working on production.
Ephemeral environments are a good way of previewing what the product will actually look like, while also enabling immediate fixes. With every isolated, environment spun up, you will get a custom URL that you can use to preview and share with other stakeholders so they get visibility and collaborate for faster feedback cycles. You can also share the custom URL while you debug some of the environment locally, or even purposely break things to preview in CI/CD and identify errors before reaching production.