refine envrionment deploy doc (#999)

Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>

Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>

docs/tutorials/multi-env.md

@@ -1,50 +1,55 @@
 ---
-title: Deploy across Multi Environments
+title: Deploy to Multi Environments
 ---
 
-Environments represent your deployment targets logically (QA, Prod, etc). You can add the same Environment to as many Targets as you need.
-In KubeVela, the environment bond a namespace in the hub cluster. The application CR should create in this namespace. If the application does not configure the target cluster and namespace(such as Topology policy). The default target namespace to create the pod or service resources is the same as the environment.
+:::tip
+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](../case-studies/multi-cluster), just compose the topology policy with different clusters and namespaces to make them work as environment. 
+:::
 
-For one application, If you want to deploy to a multi-environment, you need to apply the application CR to multi namespaces in hub cluster. There is a way in UI that you only need to manage one application configuration.
+Environments represent your deployment targets logically ( develop, test, production, etc). VelaUX (the UI of KubeVela) provides [some new concepts, the environment and delivery target](../reference/addons/velaux#concept-of-velaux) 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.
+
+![environment](../resources/environment.jpg)
+
+:::note
+If no delivery target configured, a default one  will be used with the default namespace in the control plane cluster.
+:::
+
+In the following sections, we'll guide you how to manage application to deploy into multi-environments with VelaUX.
 
 ## Deploy the application to multi-environment
 
 ### 1. Create an environment
 
-```bash
-vela env init prod --namespace prod
-```
-
-You could create an environment via CLI, but that does not sync to UI before you create an application in this environment. A more elegant way is to create it directly in the UI.
+Create environment on VelaUX is very straight forward.
 
 ![create-env](https://static.kubevela.net/images/1.5/create-env.jpg)
 
 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.
 
-![environment](https://static.kubevela.net/images/1.5/environment.jpg)
+:::note
+You could create an environment with command ( `vela env init prod --namespace prod` ), but currently( v1.5) that does not sync to UI before you create an application in this environment.
+:::
+
 
 ### 2. Bind the application to an environment
 
-You could select multi environments when you create an application. Or at any time bind the other environments. The UI will generate a workflow when the application bind to an environment, that includes some `deploy` type steps. The default rule is one target one step. You could add other steps such as the `suspend` between the two `deploy` steps.
+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 `deploy` 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 `suspend` between two `deploy` steps.
 
 ![env workflow](https://static.kubevela.net/images/1.5/env-workflow.jpg)
 
 ### 3. Set the different configuration
 
-We always need to set different configurations for different environments. such as environment variables, replicas or resource limits. Let's create some override policies. When we create an override policy, we need to select a workflow and steps, this means selecting the environment or target. So, you could make the different configurations take effect in the specific environment or targets.
+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.
 
 ![override-policy](https://static.kubevela.net/images/1.5/override-policy.jpg)
 
-Refer to [the override policy](../end-user/policies/references#override)
+You can refer to [override policy](../end-user/policies/references#override) documentation for parameter spec details.
 
 ### 4. Deploy
 
-By default, every environment is deployed independently. When you deploy an application needs to select a workflow to deploy an environment. If you want to deploy to multi environments in one workflow, there is a way to link the multi workflows.
+By default, all environments are independent with each other. When you deploy an application, you need to select the environment to be deployed. You can also leverage the [custom trigger](../how-to/dashboard/trigger/overview) to connect deploy actions between environments.
 
-For example, you want to deploy the prod environment after the QA environment is completed deploy. you could create a trigger with the custom type for the prod environment, you could get a webhook URL. Then, edit the workflow of the QA environment and added a webhook type step that uses the trigger webhook URL at the end. Now, the QA workflow will trigger the prod workflow.
-
-## Deploy the helm chart to multi-environment
-
-Some teams deploy the application to a multi-environment through the helm chart and multi values files. You also move this solution to the KubeVela.
-
-The operation is the same as in the previous section. The key point is to use different value files. Refer to [this section](./helm#specify-different-value-file)
+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. 

i18n/zh/docusaurus-plugin-content-docs/current/README.md

@@ -1,3 +1,8 @@
+---
+title: README
+slug: /readme
+---
+
 ![alt](resources/KubeVela-03.png)
 
 *Make shipping applications more enjoyable.*

i18n/zh/docusaurus-plugin-content-docs/current/tutorials/multi-env.md

@@ -1,50 +1,55 @@
 ---
-title: Multi Environment Delivery
+title: Deploy to Multi Environments
 ---
 
-Environments represent your deployment targets logically (QA, Prod, etc). You can add the same Environment to as many Targets as you need.
-In KubeVela, the environment bond a namespace in the hub cluster. The application CR should create in this namespace. If the application does not configure the target cluster and namespace(such as Topology policy). The default target namespace to create the pod or service resources is the same as the environment.
+:::tip
+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](../case-studies/multi-cluster), just compose the topology policy with different clusters and namespaces to make them work as environment. 
+:::
 
-For one application, If you want to deploy to a multi-environment, you need to apply the application CR to multi namespaces in hub cluster. There is a way in UI that you only need to manage one application configuration.
+Environments represent your deployment targets logically ( develop, test, production, etc). VelaUX (the UI of KubeVela) provides [some new concepts, the environment and delivery target](../reference/addons/velaux#concept-of-velaux) 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.
+
+![environment](../resources/environment.jpg)
+
+:::note
+If no delivery target configured, a default one  will be used with the default namespace in the control plane cluster.
+:::
+
+In the following sections, we'll guide you how to manage application to deploy into multi-environments with VelaUX.
 
 ## Deploy the application to multi-environment
 
 ### 1. Create an environment
 
-```bash
-vela env init prod --namespace prod
-```
-
-You could create an environment via CLI, but that does not sync to UI before you create an application in this environment. A more elegant way is to create it directly in the UI.
+Create environment on VelaUX is very straight forward.
 
 ![create-env](https://static.kubevela.net/images/1.5/create-env.jpg)
 
 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.
 
-![environment](https://static.kubevela.net/images/1.5/environment.jpg)
+:::note
+You could create an environment with command ( `vela env init prod --namespace prod` ), but currently( v1.5) that does not sync to UI before you create an application in this environment.
+:::
+
 
 ### 2. Bind the application to an environment
 
-You could select multi environments when you create an application. Or at any time bind the other environments. The UI will generate a workflow when the application bind to an environment, that includes some `deploy` type steps. The default rule is one target one step. You could add other steps such as the `suspend` between the two `deploy` steps.
+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 `deploy` 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 `suspend` between two `deploy` steps.
 
 ![env workflow](https://static.kubevela.net/images/1.5/env-workflow.jpg)
 
 ### 3. Set the different configuration
 
-We always need to set different configurations for different environments. such as environment variables, replicas or resource limits. Let's create some override policies. When we create an override policy, we need to select a workflow and steps, this means selecting the environment or target. So, you could make the different configurations take effect in the specific environment or targets.
+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.
 
 ![override-policy](https://static.kubevela.net/images/1.5/override-policy.jpg)
 
-Refer to [the override policy](../end-user/policies/references#override)
+You can refer to [override policy](../end-user/policies/references#override) documentation for parameter spec details.
 
 ### 4. Deploy
 
-By default, every environment is deployed independently. When you deploy an application needs to select a workflow to deploy an environment. If you want to deploy to multi environments in one workflow, there is a way to link the multi workflows.
+By default, all environments are independent with each other. When you deploy an application, you need to select the environment to be deployed. You can also leverage the [custom trigger](../how-to/dashboard/trigger/overview) to connect deploy actions between environments.
 
-For example, you want to deploy the prod environment after the QA environment is completed deploy. you could create a trigger with the custom type for the prod environment, you could get a webhook URL. Then, edit the workflow of the QA environment and added a webhook type step that uses the trigger webhook URL at the end. Now, the QA workflow will trigger the prod workflow.
-
-## Deploy the helm chart to multi-environment
-
-Some teams deploy the application to a multi-environment through the helm chart and multi values files. You also move this solution to the KubeVela.
-
-The operation is the same as in the previous section. The key point is to use different value files. Refer to [this section](./helm#specify-different-value-file)
+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. 

i18n/zh/docusaurus-plugin-content-docs/version-v1.3/README.md

@@ -1,3 +1,8 @@
+---
+title: README
+slug: /readme
+---
+
 ![alt](resources/KubeVela-03.png)
 
 *Make shipping applications more enjoyable.*

i18n/zh/docusaurus-plugin-content-docs/version-v1.4/README.md

@@ -1,3 +1,8 @@
+---
+title: README
+slug: /readme
+---
+
 ![alt](resources/KubeVela-03.png)
 
 *Make shipping applications more enjoyable.*

i18n/zh/docusaurus-plugin-content-docs/version-v1.5/README.md

@@ -1,3 +1,8 @@
+---
+title: README
+slug: /readme
+---
+
 ![alt](resources/KubeVela-03.png)
 
 *Make shipping applications more enjoyable.*

i18n/zh/docusaurus-plugin-content-docs/version-v1.5/tutorials/multi-env.md

@@ -1,50 +1,55 @@
 ---
-title: Multi Environment Delivery
+title: Deploy to Multi Environments
 ---
 
-Environments represent your deployment targets logically (QA, Prod, etc). You can add the same Environment to as many Targets as you need.
-In KubeVela, the environment bond a namespace in the hub cluster. The application CR should create in this namespace. If the application does not configure the target cluster and namespace(such as Topology policy). The default target namespace to create the pod or service resources is the same as the environment.
+:::tip
+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](../case-studies/multi-cluster), just compose the topology policy with different clusters and namespaces to make them work as environment. 
+:::
 
-For one application, If you want to deploy to a multi-environment, you need to apply the application CR to multi namespaces in hub cluster. There is a way in UI that you only need to manage one application configuration.
+Environments represent your deployment targets logically ( develop, test, production, etc). VelaUX (the UI of KubeVela) provides [some new concepts, the environment and delivery target](../reference/addons/velaux#concept-of-velaux) 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.
+
+![environment](../resources/environment.jpg)
+
+:::note
+If no delivery target configured, a default one  will be used with the default namespace in the control plane cluster.
+:::
+
+In the following sections, we'll guide you how to manage application to deploy into multi-environments with VelaUX.
 
 ## Deploy the application to multi-environment
 
 ### 1. Create an environment
 
-```bash
-vela env init prod --namespace prod
-```
-
-You could create an environment via CLI, but that does not sync to UI before you create an application in this environment. A more elegant way is to create it directly in the UI.
+Create environment on VelaUX is very straight forward.
 
 ![create-env](https://static.kubevela.net/images/1.5/create-env.jpg)
 
 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.
 
-![environment](https://static.kubevela.net/images/1.5/environment.jpg)
+:::note
+You could create an environment with command ( `vela env init prod --namespace prod` ), but currently( v1.5) that does not sync to UI before you create an application in this environment.
+:::
+
 
 ### 2. Bind the application to an environment
 
-You could select multi environments when you create an application. Or at any time bind the other environments. The UI will generate a workflow when the application bind to an environment, that includes some `deploy` type steps. The default rule is one target one step. You could add other steps such as the `suspend` between the two `deploy` steps.
+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 `deploy` 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 `suspend` between two `deploy` steps.
 
 ![env workflow](https://static.kubevela.net/images/1.5/env-workflow.jpg)
 
 ### 3. Set the different configuration
 
-We always need to set different configurations for different environments. such as environment variables, replicas or resource limits. Let's create some override policies. When we create an override policy, we need to select a workflow and steps, this means selecting the environment or target. So, you could make the different configurations take effect in the specific environment or targets.
+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.
 
 ![override-policy](https://static.kubevela.net/images/1.5/override-policy.jpg)
 
-Refer to [the override policy](../end-user/policies/references#override)
+You can refer to [override policy](../end-user/policies/references#override) documentation for parameter spec details.
 
 ### 4. Deploy
 
-By default, every environment is deployed independently. When you deploy an application needs to select a workflow to deploy an environment. If you want to deploy to multi environments in one workflow, there is a way to link the multi workflows.
+By default, all environments are independent with each other. When you deploy an application, you need to select the environment to be deployed. You can also leverage the [custom trigger](../how-to/dashboard/trigger/overview) to connect deploy actions between environments.
 
-For example, you want to deploy the prod environment after the QA environment is completed deploy. you could create a trigger with the custom type for the prod environment, you could get a webhook URL. Then, edit the workflow of the QA environment and added a webhook type step that uses the trigger webhook URL at the end. Now, the QA workflow will trigger the prod workflow.
-
-## Deploy the helm chart to multi-environment
-
-Some teams deploy the application to a multi-environment through the helm chart and multi values files. You also move this solution to the KubeVela.
-
-The operation is the same as in the previous section. The key point is to use different value files. Refer to [this section](./helm#specify-different-value-file)
+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. 

versioned_docs/version-v1.5/tutorials/multi-env.md

@@ -1,50 +1,55 @@
 ---
-title: Deploy across Multi Environments
+title: Deploy to Multi Environments
 ---
 
-Environments represent your deployment targets logically (QA, Prod, etc). You can add the same Environment to as many Targets as you need.
-In KubeVela, the environment bond a namespace in the hub cluster. The application CR should create in this namespace. If the application does not configure the target cluster and namespace(such as Topology policy). The default target namespace to create the pod or service resources is the same as the environment.
+:::tip
+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](../case-studies/multi-cluster), just compose the topology policy with different clusters and namespaces to make them work as environment. 
+:::
 
-For one application, If you want to deploy to a multi-environment, you need to apply the application CR to multi namespaces in hub cluster. There is a way in UI that you only need to manage one application configuration.
+Environments represent your deployment targets logically ( develop, test, production, etc). VelaUX (the UI of KubeVela) provides [some new concepts, the environment and delivery target](../reference/addons/velaux#concept-of-velaux) 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.
+
+![environment](../resources/environment.jpg)
+
+:::note
+If no delivery target configured, a default one  will be used with the default namespace in the control plane cluster.
+:::
+
+In the following sections, we'll guide you how to manage application to deploy into multi-environments with VelaUX.
 
 ## Deploy the application to multi-environment
 
 ### 1. Create an environment
 
-```bash
-vela env init prod --namespace prod
-```
-
-You could create an environment via CLI, but that does not sync to UI before you create an application in this environment. A more elegant way is to create it directly in the UI.
+Create environment on VelaUX is very straight forward.
 
 ![create-env](https://static.kubevela.net/images/1.5/create-env.jpg)
 
 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.
 
-![environment](https://static.kubevela.net/images/1.5/environment.jpg)
+:::note
+You could create an environment with command ( `vela env init prod --namespace prod` ), but currently( v1.5) that does not sync to UI before you create an application in this environment.
+:::
+
 
 ### 2. Bind the application to an environment
 
-You could select multi environments when you create an application. Or at any time bind the other environments. The UI will generate a workflow when the application bind to an environment, that includes some `deploy` type steps. The default rule is one target one step. You could add other steps such as the `suspend` between the two `deploy` steps.
+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 `deploy` 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 `suspend` between two `deploy` steps.
 
 ![env workflow](https://static.kubevela.net/images/1.5/env-workflow.jpg)
 
 ### 3. Set the different configuration
 
-We always need to set different configurations for different environments. such as environment variables, replicas or resource limits. Let's create some override policies. When we create an override policy, we need to select a workflow and steps, this means selecting the environment or target. So, you could make the different configurations take effect in the specific environment or targets.
+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.
 
 ![override-policy](https://static.kubevela.net/images/1.5/override-policy.jpg)
 
-Refer to [the override policy](../end-user/policies/references#override)
+You can refer to [override policy](../end-user/policies/references#override) documentation for parameter spec details.
 
 ### 4. Deploy
 
-By default, every environment is deployed independently. When you deploy an application needs to select a workflow to deploy an environment. If you want to deploy to multi environments in one workflow, there is a way to link the multi workflows.
+By default, all environments are independent with each other. When you deploy an application, you need to select the environment to be deployed. You can also leverage the [custom trigger](../how-to/dashboard/trigger/overview) to connect deploy actions between environments.
 
-For example, you want to deploy the prod environment after the QA environment is completed deploy. you could create a trigger with the custom type for the prod environment, you could get a webhook URL. Then, edit the workflow of the QA environment and added a webhook type step that uses the trigger webhook URL at the end. Now, the QA workflow will trigger the prod workflow.
-
-## Deploy the helm chart to multi-environment
-
-Some teams deploy the application to a multi-environment through the helm chart and multi values files. You also move this solution to the KubeVela.
-
-The operation is the same as in the previous section. The key point is to use different value files. Refer to [this section](./helm#specify-different-value-file)
+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.