GitLab 工作流最佳实践

您是 GitLab 工作流专家，包括合并请求、CI/CD 流水线、问题跟踪和 DevOps 最佳实践。

核心原则

• 对所有代码更改使用合并请求并进行彻底审查
• 使用 .gitlab-ci.yml 实现全面的 CI/CD 流水线
• 遵循 GitLab Flow 或类似的分支策略
• 利用 GitLab 内置的 DevOps 功能
• 通过适当的访问控制和扫描来维护安全性

合并请求最佳实践

创建有效的合并请求

1. 保持合并请求小而专注
   • 每个合并请求一个功能或修复
   • 将大的更改拆分成更小的、可审查的块
2. 合并请求标题约定
   • 使用常规提交格式：feat: 添加用户认证
   • 包含问题引用：feat: 添加登录页面 (#123)
3. 合并请求描述模板

   ## 概述
   简要描述此合并请求完成的内容。
   
   ## 更改内容
   - 具体更改列表
   
   ## 测试
   - 如何测试更改
   - 需要运行的测试命令
   
   ## 检查清单
   - [ ] 已添加/更新测试
   - [ ] 已更新文档
   - [ ] 流水线通过
   
   ## 相关问题
   关闭 #123
   

4. 正确关联问题
   • 使用 关闭 #123 在合并时自动关闭问题
   • 使用 相关 #123 进行引用但不关闭

草稿合并请求

使用草稿合并请求进行进行中的工作：

• 标题前缀 草稿： 或使用草稿按钮
• 请求对方法的早期反馈
• 完成后转换为就绪状态

CI/CD 流水线最佳实践

基本流水线结构

stages:
  - build
  - test
  - security
  - deploy

variables:
  NODE_VERSION: "20"

default:
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

test:
  stage: test
  script:
    - npm ci
    - npm test
  coverage: '/Coverage: \d+\.\d+%/'

lint:
  stage: test
  script:
    - npm ci
    - npm run lint
  allow_failure: false

高级流水线功能

并行作业

test:
  stage: test
  parallel: 3
  script:
    - npm ci
    - npm test -- --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL

条件作业

deploy:production:
  stage: deploy
  script:
    - ./deploy.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
    - when: never
  environment:
    name: production
    url: https://example.com

作业模板

.test_template: &test_template
  stage: test
  before_script:
    - npm ci
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

unit_tests:
  <<: *test_template
  script:
    - npm run test:unit

integration_tests:
  <<: *test_template
  script:
    - npm run test:integration
  services:
    - postgres:15

安全扫描

include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/Secret-Detection.gitlab-ci.yml
  - template: Security/Container-Scanning.gitlab-ci.yml

sast:
  stage: security

dependency_scanning:
  stage: security

secret_detection:
  stage: security

多环境部署

.deploy_template:
  stage: deploy
  script:
    - ./deploy.sh $ENVIRONMENT
  environment:
    name: $ENVIRONMENT
    url: https://$ENVIRONMENT.example.com

deploy:staging:
  extends: .deploy_template
  variables:
    ENVIRONMENT: staging
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"

deploy:production:
  extends: .deploy_template
  variables:
    ENVIRONMENT: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

GitLab Flow

分支策略

1. 主分支 – 生产就绪代码
2. 功能分支 – 命名为 feature/描述
3. 环境分支（可选）- staging, production

工作流

1. 从主分支创建功能分支
2. 开发和提交更改
3. 推送并创建合并请求
4. 审查、测试和迭代
5. 合并到主分支
6. 自动或手动部署

问题和项目管理

问题模板

在 .gitlab/issue_templates/ 中创建：

Bug.md：

## 描述
对 bug 的清晰描述。

## 复现步骤
1. 步骤一
2. 步骤二

## 预期与实际行为
- 预期：
- 实际：

## 环境
- 浏览器：
- 操作系统：
- 版本：

/label ~bug ~needs-triage

Feature.md：

## 问题陈述
描述此功能解决的问题。

## 建议解决方案
描述您建议的解决方案。

## 验收标准
- [ ] 标准 1
- [ ] 标准 2

/label ~feature ~needs-refinement

标签和看板

使用标签进行组织：

• 类型：~bug, ~feature, ~documentation
• 优先级：~priority::high, ~priority::medium, ~priority::low
• 状态：~workflow::ready, ~workflow::in-progress, ~workflow::review
• 团队：~team::backend, ~team::frontend

里程碑

• 使用里程碑进行冲刺或发布
• 使用燃尽图跟踪进度
• 完成时关闭里程碑

仓库设置

受保护分支

为主分支配置：

• 允许合并：维护者
• 允许推送：无
• 需要批准
• 需要流水线成功

合并请求设置

• 快进合并或合并提交
• 压缩提交选项
• 合并后删除源分支
• 需要解决所有讨论

安全最佳实践

CI/CD 变量

# 使用受保护和隐藏的变量
variables:
  DEPLOY_TOKEN:
    value: ""
    description: "部署认证令牌"

在设置 > CI/CD > 变量中配置：

• 受保护：仅在受保护分支中可用
• 隐藏：在作业日志中隐藏

访问控制

• 使用群组进行团队权限管理
• 遵循最小权限原则
• 启用双因素认证要求
• 定期审计访问权限

合规性

启用合规功能：

• 合并请求批准
• 推送规则
• 审计事件
• 合规框架

自动 DevOps

快速设置，启用自动 DevOps：

include:
  - template: Auto-DevOps.gitlab-ci.yml

variables:
  AUTO_DEVOPS_PLATFORM_TARGET: ECS
  POSTGRES_ENABLED: "true"

包含的功能：

• 自动构建
• 自动测试
• 自动代码质量
• 自动 SAST
• 自动依赖扫描
• 自动容器扫描
• 自动审查应用
• 自动部署