Deploy to Multi Environments

This section will mainly focus on UI operation on multi-environments delivery, if you want to deploy with YAML, just refer to multi-cluster delivery doc, just compose the topology policy with different clusters and namespaces to make them work as environment.

Environments represent your deployment targets logically ( develop, test, production, etc). VelaUX (the UI of KubeVela) provides for more flexible deployments on UI operations.

You can place multi targets to the same environment as you need. In KubeVela, the environment bond a namespace in the control plane cluster. The application instance will be deployed into the Kubernetes namespace bond with the specified environment. Actually, the application created in VelaUX is an application template before bound with environment. As a result, VelaUX allow you to easily deploy the same app into different environments.

note

In the following sections, we’ll guide you how to manage application to deploy into multi-environments with VelaUX.

Create environment on VelaUX is very straight forward.

One environment could includes multi targets. The environment belongs to a project, One project could include multi environments. Only the application belonging to this project could bond this environment.

note

You could select multi environments when you create an application, or modify the application later to bind more environments. The UI will automatically generate a workflow when the application bond to an environment, that includes some type steps. You can manually modify the workflow later. The default behavior is to deploy targets one by one in workflow steps. You could add other steps such as between two steps.

We usually need to set different configurations for different environments, such as environment variables, replicas or resource limits. In this case, we can create some override policies. When we create an override policy, we need to choose affected environment or targets through selecting workflow and steps.

You can refer to override policy documentation for parameter spec details.

For example, if you want to deploy the production environment only after the test environment is completed successfully. You can create a trigger with the custom type for the production environment, and get a webhook URL. Then, edit the workflow of the test environment, add a webhook workflow step at the end.