style: apply global formatting fixes (struct, spacing, zhlint)

15_cases/ci/README.md

@@ -1,6 +1,6 @@
 # CI/CD
 
-**持续集成（Continuous integration）**是一种软件开发实践，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。**持续部署（continuous deployment）** 是通过自动化的构建、测试和部署循环来快速交付高质量的产品。
+**持续集成 (Continuous integration)**是一种软件开发实践，每次集成都通过自动化的构建 (包括编译，发布，自动化测试) 来验证，从而尽早地发现集成错误。**持续部署 (continuous deployment)** 是通过自动化的构建、测试和部署循环来快速交付高质量的产品。
 
 
 与 `Jenkins` 不同的是，基于 Docker 的 CI/CD 每一步都运行在 Docker 容器中，所以理论上支持所有的编程语言。

15_cases/ci/actions/README.md

@@ -23,6 +23,10 @@ jobs:
           args: go version
 ```
 
+## 概述
+
+总体概述了以下内容。
+
 ## 参考资料
 
 * [Actions Docs](https://docs.github.com/en/actions)

15_cases/ci/devops_workflow.md

@@ -1,20 +1,22 @@
 ## DevOps 工作流完整示例
 
-本章将演示一个基于 Docker, Kubernetes 和 Jenkins/GitLab CI 的完整 DevOps 工作流。
+本章将演示一个基于 Docker，Kubernetes 和 Jenkins/GitLab CI 的完整 DevOps 工作流。
 
 ### 工作流概览
 
-1. **Code**: 开发人员提交代码到 GitLab。
-2. **Build**: GitLab CI 触发构建任务。
-3. **Test**: 运行单元测试和集成测试。
-4. **Package**: 构建 Docker 镜像并推送到 Harbor/Registry。
-5. **Deploy (Staging)**: 自动部署到测试环境 Kubernetes 集群。
-6. **Verify**: 人工或自动化验证。
-7. **Release (Production)**: 审批后自动部署到生产环境。
+1. **Code**：开发人员提交代码到 GitLab。
+2. **Build**：GitLab CI 触发构建任务。
+3. **Test**：运行单元测试和集成测试。
+4. **Package**：构建 Docker 镜像并推送到 Harbor/Registry。
+5. **Deploy (Staging)**：自动部署到测试环境 Kubernetes 集群。
+6. **Verify**：人工或自动化验证。
+7. **Release (Production)**：审批后自动部署到生产环境。
 
 ### 关键配置示例
 
-#### 1. Dockerfile 多阶段构建
+本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
+
+#### 1。Dockerfile 多阶段构建
 
 使用 Docker 多阶段构建可以有效减小镜像体积。
 
@@ -37,9 +39,9 @@ COPY --from=builder /app/main .
 CMD ["./main"]
 ```
 
-#### 2. GitLab CI 配置
+#### 2。GitLab CI 配置
 
-GitLab CI（.gitlab-ci.yml）配置如下：
+GitLab CI (。gitlab-ci.yml) 配置如下：
 
 
 ```yaml
@@ -79,6 +81,6 @@ deploy_staging:
 
 ### 最佳实践
 
-1. **不可变基础设施**: 一旦镜像构建完成，在各个环境（Dev, Staging, Prod）中都应该使用同一个镜像 tag (通常是 commit hash)，而不是重新构建。
-2. **配置分离**: 使用 ConfigMap 和 Secret 管理环境特定的配置，不要打包进镜像。
-3. **GitOps**: 考虑引入 ArgoCD，将部署配置也作为代码存储在 Git 中，实现 Git 驱动的部署同步。
+1. **不可变基础设施**：一旦镜像构建完成，在各个环境 (Dev，Staging，Prod) 中都应该使用同一个镜像 tag (通常是 commit hash)，而不是重新构建。
+2. **配置分离**：使用 ConfigMap 和 Secret 管理环境特定的配置，不要打包进镜像。
+3. **GitOps**：考虑引入 ArgoCD，将部署配置也作为代码存储在 Git 中，实现 Git 驱动的部署同步。

15_cases/ci/drone/README.md

@@ -10,7 +10,7 @@
 
 在 Github 新建一个名为 `drone-demo` 的仓库。
 
-打开我们已经 [部署好的 Drone 网站](install.md) 或者 [Drone Cloud](https://cloud.drone.io)，使用 GitHub 账号登录，在界面中关联刚刚新建的 `drone-demo` 仓库。
+打开我们已经[部署好的 Drone 网站](install.md)或者 [Drone Cloud](https://cloud.drone.io)，使用 GitHub 账号登录，在界面中关联刚刚新建的 `drone-demo` 仓库。
 
 ## 编写项目源代码
 

15_cases/ci/drone/demo/README.md

@@ -4,9 +4,9 @@
 
 ## 目录结构
 
-*   `app.go`: 简单的 Go Web 服务器代码。
-*   `.drone.yml`: Drone CI 的配置文件，定义了构建和测试流程。
-*   `Dockerfile`: 定义了如何将该应用构建为 Docker 镜像。
+*   `app.go`：简单的 Go Web 服务器代码。
+*   `.drone.yml`：Drone CI 的配置文件，定义了构建和测试流程。
+*   `Dockerfile`：定义了如何将该应用构建为 Docker 镜像。
 
 ## 如何运行
 

15_cases/ci/drone/install.md

@@ -1,5 +1,7 @@
 ## 部署 Drone
 
+本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
+
 ### 要求
 
 * 拥有公网 IP、域名 (如果你不满足要求，可以尝试在本地使用 Gogs + Drone)
@@ -22,7 +24,7 @@
 
 ### 配置 Drone
 
-我们通过使用 `Docker Compose` 来启动 `Drone`，编写 `compose.yaml`（或 `docker-compose.yml`）文件。
+我们通过使用 `Docker Compose` 来启动 `Drone`，编写 `compose.yaml` (或 `docker-compose.yml`) 文件。
 
 ```yaml
 services:
@@ -80,6 +82,10 @@ DRONE_GITHUB_CLIENT_ID=
 DRONE_GITHUB_CLIENT_SECRET=
 ```
 
+#### 概述
+
+总体概述了以下内容。
+
 #### 启动 Drone
 
 运行以下命令：