Feat: add gitlab & acr best practice (#427)

* Feat: add gitlab & acr best practice

Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>

* add en docs

Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>

* change the title and add in tutorials

Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>

* resolve comments

Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>

* change the cn title

Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>

docs/case-studies/trigger.md

@@ -0,0 +1,78 @@
+---
+title: Integrate Image Registry for Continuous Delivery
+---
+
+## Introduction
+
+In our daily development, when image tags changed, it is more convenient for CI/CD if the environments can automatically deploy the new image. KubeVela provides this mechanism.
+
+In KubeVela 1.2, [VelaUX](../install#3-install-velaux) provides a good way to do this. We can use KubeVela triggers to apply applications automatically.
+
+In this section, we will use GitLab as code repository and ACR as image repository to integrate with KubeVela triggers, as a result, it will automatically update application when image tags changed.
+
+## Create Application
+
+To use triggers, we need to create a new application on VelaUX first. We can create a new WebService type application and use LoadBalancer to expose port 80 for access.
+
+![alt](../resources/acr-trigger-newapp.png)
+
+## Create Triggers for Application
+
+After creating the application, use `New Trigger` to create a trigger. Here we use `ACR` as payload type to support requests from the `ACR` image registry.
+
+![alt](../resources/acr-trigger-newtrigger.png)
+
+Check the details of the trigger, you can see the specific Webhook URL and the manual trigger command.
+
+![alt](../resources/acr-trigger-info.png)
+
+## Setup ACR Trigger
+
+ACR payload triggers need to cooperate with Ali Cloud ACR image registry. After creating a trigger of type ACR, we can copy the Webhook URL of the trigger and configure it in the ACR image registry.
+
+![alt](../resources/acr-trigger.png)
+
+## Test and Apply
+
+After these setups, we can now test the trigger.
+
+Let's start by looking at the current app page, you can directly jump to the LoadBalancer address through the `Service Endpoint` of the application.
+
+![alt](../resources/acr-trigger-endpoints.png)
+
+As you can see, the current Demo application's version is `v1.0.0`.
+
+![alt](../resources/acr-trigger-appv1.png)
+
+This source code of this demo is on the [GitLab] (https://gitlab.com/FogDong/KubeVela-GitOps-Demo-Code). There is also a CI file in this repo, in which steps are simple, every time the code is updated, it will automatically build the image and pushed to the image registry.
+
+We can change the version in the code to `v2.0.0`:
+
+```javascript
+data(){
+    return {
+      v: 'v2.0.0',
+    }
+  },
+```
+
+After changing the code, the GitLab CI will automatically build the image and push it to the image registry.
+
+In the access log of the ACR trigger, we can see that ACR sends a request to our Webhook URL when the latest image is pushed to the image registry.
+
+![alt](../resources/acr-trigger-acrrecord.png)
+
+Check the application revisions in VelaUX, you can see that the most recent revision was from `Webhook`.
+
+![alt](../resources/acr-trigger-revisions.png)
+
+Looking back at the app page, you can see that the app version has changed to `v2.0.0` and the background of the page has changed with the version.
+
+
+![alt](../resources/acr-trigger-appv2.png)
+
+## Summary
+
+The KubeVela triggers' combination with the image registry is smooth and seamless. In addition to ACR, KubeVela also supports Harbor and custom trigger payload types.
+
+With KubeVela triggers, we can easily apply application based on image tags automatically and complete iterations of application versions.

i18n/zh/docusaurus-plugin-content-docs/current/case-studies/trigger.md

@@ -0,0 +1,77 @@
+---
+title:  在持续交付中集成镜像仓库
+---
+
+## 简介
+
+在日常研发的过程中，当项目中的镜像版本发生变化时，通常我们需要将最新版本更新到各个环境中。在这个更新部署的过程中，手动部署不仅繁琐，且容易出错。因此，我们需要一个工具来完成基于镜像版本的自动化部署。
+
+在 KubeVela 1.2 版本中，[VelaUX](../install#3-安装-velaux) 自带的应用触发器提供了一个很好的入口。我们可以使用这个触发器，来帮助我们完成这些自动部署的工作。
+
+本文将详细介绍如何使用 KubeVela 触发器来完成基于镜像版本的自动化部署，在本文的例子当中，我们将使用 GitLab 作为代码仓库，ACR 作为镜像仓库来完成演示。
+
+## 创建应用
+
+要使用触发器，首先我们需要在 VelaUX 上新建一个应用。在这里，我们可以新建一个 WebService 类型的应用，并使用 LoadBalancer 为其暴露 80 端口以便访问。
+
+![alt](../resources/acr-trigger-newapp.png)
+
+## 为应用新建触发器
+
+在新建完应用后，使用 `New Trigger` 来创建新的触发器，这里我们选择 `ACR` 格式的触发器，使该触发器支持来自 `ACR` 镜像仓库的请求。
+
+![alt](../resources/acr-trigger-newtrigger.png)
+
+查看这个触发器的详细信息，可以看到具体的 Webhook URL 以及手动触发的命令。
+
+![alt](../resources/acr-trigger-info.png)
+
+## 配置 ACR 触发器
+
+ACR 格式触发器需要配合阿里云 ACR 镜像仓库使用。当创建完 ACR 类型的触发器后，我们可以复制该触发器的 Webhook URL，并在 ACR 镜像仓库中进行配置。
+
+![alt](../resources/acr-trigger.png)
+
+## 测试部署
+
+完成这些触发器的配置之后，我们可以进行一个简单的测试来查看自动部署效果。
+
+首先我们来查看一下当前应用的页面，通过应用的 `Service Endpoint`，可以直接跳转到应用的 LoadBalancer 地址。
+
+![alt](../resources/acr-trigger-endpoints.png)
+
+可以看到，当前的 Demo 应用显示版本为 `v1.0.0`。
+
+![alt](../resources/acr-trigger-appv1.png)
+
+这个 Demo 应用的源码放在了 [GitLab](https://gitlab.com/FogDong/KubeVela-GitOps-Demo-Code) 上。仓库里除了源码，还有一份 CI 文件，里面的步骤也十分简单，每次代码被更新时，都将自动构建镜像推送到镜像仓库中。
+
+我们将代码的版本修改为 `v2.0.0`：
+
+```javascript
+data(){
+    return {
+      v: 'v2.0.0',
+    }
+  },
+```
+
+修改完成后，GitLab CI 将自动构建并推送最新镜像。
+
+在 ACR 触发器的访问记录中，我们可以看到，当镜像仓库中有了最新镜像时，ACR 会往我们配置的 Webhook URL 中发送一个请求。
+
+![alt](../resources/acr-trigger-acrrecord.png)
+
+查看 VelaUX 的应用部署版本列表，可以看到，最近一次部署是来自 `webhook` 的部署。
+
+![alt](../resources/acr-trigger-revisions.png)
+
+重新查看应用页面，可以看到，应用的版本已经变更成了 `v2.0.0`，同时页面的背景也随版本发生了变化。
+
+![alt](../resources/acr-trigger-appv2.png)
+
+## 总结
+
+KubeVela 触发器与制品仓库的对接是十分顺滑且无缝的，除了 ACR 之外，KubeVela 还支持 Harbor 以及自定义触发的格式。
+
+通过使用 KubeVela 触发器，我们可以轻松地根据镜像版本实现自动部署，从而完成应用版本的迭代。

sidebars.js

@@ -32,6 +32,7 @@ module.exports = {
         "deliver-app/workflows",
         "case-studies/jenkins-cicd",
         "case-studies/gitops",
+        "case-studies/trigger",
         // "case-studies/canary-blue-green",
       ],
     },