Ch 30 工程师日常工作流与变更场景¶

面包屑

项目第 1 年 · 核心建设期——工程师工作流

本章你将学到¶

工程师的一天：从 PR 到生产的完整工作流
常见变更场景清单与对应仓库
代码质量门禁体系：静态检查/代码扫描/SQL 规范

30.1 工程师的一天：从 PR 到生产¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8'}}}%%
timeline
    title 工程师的一天：从 PR 到生产
    section 上午
        开发 : 拉分支 → 写代码 → 本地测试
    section 中午
        提交 : 推送 → CI 自动验证
    section 下午
        审查 : PR review → 合并 dev
    section 傍晚
        验证 : DEV 验证 → 打 tag
    section 按需
        晋升 : QA 验收 → PROD 审批

图 30-1 工程师的一天：从 PR 到生产

时段	活动	工具/仓库
上午	拉分支、写代码、本地测试	git / 本地 IDE
中午	推送、CI 自动验证	GitHub Actions / CI
下午	PR review、合并 dev	GitHub PR
傍晚	DEV 验证、打 tag	DEV 环境
按需	QA 验收、PROD 审批	QA/PROD 环境

表 30-1 工程师的一天：从 PR 到生产

这个"一天"的时间线不是理想化的——它是我观察团队工作模式后总结的"典型节奏"。其中最值得说的是"傍晚打 tag"这个节点——很多团队习惯"写完代码就 push，等 CI 跑完就 merge"，但没有"DEV 验证后打 tag"这个仪式。我在企业征信时犯过这个错——代码 merge 到 dev 后直接触发 QA，结果 QA 跑出来的数据和 DEV 不一样（因为 DEV 没验证就晋了），来回排查浪费了一天。到 Aurora 我加了"傍晚打 tag"这个节点——开发者在 DEV 环境验证数据正确后，才打 tag 触发 QA。tag 是"我验证过了"的承诺——没有这个承诺，QA 验收的是"未验证的代码"，浪费 QA 资源。这个看似小的仪式，让 QA 的"有效验收率"从 50% 提升到 90%——QA 不再花时间验证"DEV 就能发现的问题"。

变更的分类决策¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TD
 CHANGE[需要变更] --> Q1{变更类型?}
 Q1 -->|加数据源/改映射|CONFIG[改 config-store<br/>配置发布流]
 Q1 -->|改 ETL 逻辑|CODE[改 runtime-glue<br/>Glue 发布流]
 Q1 -->|改调度/DPU|TF[改业务 IaC 仓<br/>Terraform 发布流]
 Q1 -->|加新 S3 桶|CORE[改 core-infra<br/>需平台组审批]
classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpData fill:#d9fbfb,stroke:#007d79,stroke-width:2px,color:#161616
classDef bpDecision fill:#fcf4d6,stroke:#f1c21b,stroke-width:2px,color:#161616
classDef bpSuccess fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616
classDef bpError fill:#fff1f1,stroke:#da1e28,stroke-width:2px,color:#161616
classDef bpExternal fill:#f2f4f8,stroke:#697077,stroke-width:2px,color:#161616
classDef bpInfo fill:#f6f2ff,stroke:#8a3ffc,stroke-width:2px,color:#161616
classDef bpGroup fill:#ffffff,stroke:#0f62fe,stroke-width:2px,color:#161616
class CHANGE bpDecision
class CODE bpProcess
class CONFIG bpProcess
class CORE bpProcess
class Q1 bpDecision
class TF bpProcess
linkStyle default stroke:#697077,stroke-width:2px

图 30-2 变更的分类决策

30.2 常见变更场景清单与对应仓库¶

变更场景	改哪个仓库	发布方式
新增一个 JDBC 数据源	config-store	配置发布流
修改某任务的加载模式（全量→增量）	config-store	配置发布流
修改某任务的调度时间	business-domain-{x}（tfvars）	Terraform 发布流
修改 Glue Job 的 DPU 配置	business-domain-{x}（tfvars）	Terraform 发布流
修复 ETL 脚本的 bug	runtime-glue	Glue 发布流
新增一种文件格式支持	runtime-glue	Glue 发布流
修改 Lambda 控制面函数	runtime-lambda	Lambda 发布流
新增 S3 数据湖桶	core-infra	Terraform 发布流（需平台审批）
修改 IAM 策略	core-infra 或 business-domain	Terraform 发布流
升级 Terraform 模块版本	business-domain-{x}（submodule 指针）	Terraform 发布流

表 30-2 常见变更场景清单与对应仓库

引申

"改哪个仓库"是新人最常问的问题。核心判据是 Ch 25 的边界划分：运行时配置→config-store，部署参数→业务 IaC 仓，运行时代码→runtime-glue/lambda，共享资源→core-infra。

这张表我在新人入职第一周都会让他背一遍——不是死记硬背，而是理解"每个变更该走哪条路"。新人最常犯的错是"改错地方"——比如想改加载模式（全量→增量），去改了 runtime-glue 的代码，而不是改 config-store 的配置。结果代码改了一堆，发布后发现加载模式没变——因为加载模式是运行时配置，不在代码里。我给新人的口诀是："先问改什么：改行为看配置，改资源看 Terraform，改逻辑看代码，改共享看 core"——四句话覆盖 90% 的变更场景。剩下 10% 的特殊场景（如改 IAM 策略、升级模块版本）在表 30-2 里有明确指引。好的文档不是让新人"自己摸索"，而是给出"决策树"让他快速定位——这张表就是变更的决策树。

30.3 代码质量门禁体系¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart LR
 subgraph 质量门禁["代码质量门禁体系"]
 PC[pre-commit<br/>提交前本地检查]
 CI_LINT[CI 静态检查<br/>代码规范/类型检查]
 SQ[SonarQube<br/>代码质量扫描]
 SQL[SQLFluff<br/>SQL 规范检查]
 end

 CODE[代码提交] --> PC
 PC -->|通过|CI_LINT
 CI_LINT --> SQ
 SQ --> SQL
 SQL -->|全绿|MERGE[允许合并]
classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpData fill:#d9fbfb,stroke:#007d79,stroke-width:2px,color:#161616
classDef bpDecision fill:#fcf4d6,stroke:#f1c21b,stroke-width:2px,color:#161616
classDef bpSuccess fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616
classDef bpError fill:#fff1f1,stroke:#da1e28,stroke-width:2px,color:#161616
classDef bpExternal fill:#f2f4f8,stroke:#697077,stroke-width:2px,color:#161616
classDef bpInfo fill:#f6f2ff,stroke:#8a3ffc,stroke-width:2px,color:#161616
classDef bpGroup fill:#ffffff,stroke:#0f62fe,stroke-width:2px,color:#161616
class CI_LINT bpProcess
class CODE bpProcess
class MERGE bpSuccess
class PC bpProcess
class SQ bpProcess
class SQL bpInfo
linkStyle default stroke:#697077,stroke-width:2px

图 30-3 代码质量门禁体系

门禁	检查内容	时机	阻断级别
pre-commit	格式化、基础 lint、密钥泄露检测	提交前（本地）	警告
CI 静态检查	Python 类型检查、HCL 语法校验	推送后（CI）	阻断
SonarQube	代码复杂度、重复代码、安全漏洞	CI	阈值阻断
SQLFluff	SQL 风格规范（大小写/缩进/关键字）	CI	阻断

表 30-3 代码质量门禁体系

质量门禁的分层设计¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TB
 subgraph 三层门禁["三层质量门禁"]
 L1[本地层：pre-commit<br/>快速反馈，不阻断推送]
 L2[CI 层：静态检查 + SQL 规范<br/>阻断不合格代码合并]
 L3[扫描层：SonarQube<br/>深度质量分析，阈值阻断]
 end

 L1 --> L2 --> L3
classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpData fill:#d9fbfb,stroke:#007d79,stroke-width:2px,color:#161616
classDef bpDecision fill:#fcf4d6,stroke:#f1c21b,stroke-width:2px,color:#161616
classDef bpSuccess fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616
classDef bpError fill:#fff1f1,stroke:#da1e28,stroke-width:2px,color:#161616
classDef bpExternal fill:#f2f4f8,stroke:#697077,stroke-width:2px,color:#161616
classDef bpInfo fill:#f6f2ff,stroke:#8a3ffc,stroke-width:2px,color:#161616
classDef bpGroup fill:#ffffff,stroke:#0f62fe,stroke-width:2px,color:#161616
class L1 bpProcess
class L2 bpProcess
class L3 bpProcess
linkStyle default stroke:#697077,stroke-width:2px

图 30-4 质量门禁的分层设计

Trade-off

质量门禁越多，代码质量越高，但开发体验越差。pre-commit 的价值是"在本地快速反馈"——格式问题在提交前就修复，不用等 CI 跑完才发现。门禁设计的核心原则是"快速反馈前置"——能本地检查的不放 CI，能在 CI 检查的不放人工 review。

本章小结¶

工程师的一天：上午开发→中午 CI→下午 review→傍晚验证→按需晋升
变更分类决策：运行时配置→config-store / 部署参数→业务 IaC / 运行时代码→runtime-glue/lambda / 共享资源→core-infra
三层质量门禁：pre-commit（本地快速反馈）→ CI 静态检查（阻断合并）→ SonarQube（深度扫描）——"快速反馈前置"

下一部分

Part V 平台演进：数据迁移与跨系统协同 —— 平台建好并运转后，接下来面临演进挑战：遗留系统迁移、跨账号同步、自研 DAG 调度器。