⚙️核心能力详解
平台的关键差异化能力
① Jenkinsfile 全链路自动化
用声明式 Pipeline 把代码提交→单元测试→代码扫描→镜像构建→推送 Harbor→自动部署串成一条流水线，全程无人工干预。
pipeline {
agent any
stages {
stage('测试') { steps { sh 'mvn test' } }
stage('代码扫描'){ steps { sh 'sonar-scanner' } }
stage('构建镜像'){ steps { sh 'docker build -t $HARBOR/app:$TAG .' } }
stage('推送') { steps { sh 'docker push $HARBOR/app:$TAG' } }
stage('部署') { steps { sh 'kubectl set image ...' } }
}
}
② 四环境独立流水线
dev/test/staging/prod 四套环境各自独立流水线，环境差异（域名、副本数、配置）通过 Ansible 统一管理，避免"测试好的到生产就出问题"。
③ 钉钉审批与通知
对接钉钉 API：生产发布前推送审批卡片，负责人点同意才放行；关键节点（构建完成、部署成功/失败）自动推送通知，整个发布过程透明可追溯。
④ 一键回滚机制
每次发布的镜像版本和部署记录都留存，出问题时一键回滚到任意历史版本，大幅缩短发布失败的恢复时间。
kubectl rollout undo deployment/app --to-revision=3
kubectl rollout history deployment/app
⑤ 统一镜像规范
Docker + Harbor 统一镜像命名、tag 规范（如 服务名:环境-commitID），推动全团队镜像标准化，缩短镜像构建时间。
❓面试常见问题
点击展开查看答题思路（请核对真实性）
Q1这个 CI/CD 平台和你简历里 GitOps 流水线、ACK 项目有什么区别？+
这个问题很可能被问，因为三处都涉及 CI/CD，要讲清侧重点不同：
- 本项目：聚焦"发布平台"本身——流水线设计、四环境规范、审批流、回滚机制，是把发布这件事产品化、标准化。
- ACK 项目：聚焦"上云改造"，CI/CD 只是其中一环，重点在容器化迁移和可观测。
- GitOps：是发布模式的演进——以 Git 为唯一可信源，声明式同步，更偏理念。
关键：别让面试官觉得你"同一件事写了三遍"。强调本项目的差异化抓手是审批流 + 一键回滚 + 四环境治理。
Q2声明式 Pipeline 和脚本式 Pipeline 怎么选？+
- 声明式：结构化、易读、有固定语法骨架（pipeline/stages/steps），团队协作和维护友好，大多数标准流水线用它。
- 脚本式：本质是 Groovy，灵活度高，适合复杂逻辑、动态生成 stage 的场景。
- 实践：主体用声明式保证规范统一，个别复杂逻辑用 script 块嵌入脚本式，两者可混用。
Q3生产发布失败了，怎么快速回滚？回滚要注意什么？+
- K8s 层回滚：
kubectl rollout undo 回滚 Deployment 到上一版本或指定 revision，靠 K8s 保留的 ReplicaSet 历史。
- 镜像版本管理：每次发布镜像 tag 唯一（带 commitID），回滚就是把 Deployment 镜像换回旧 tag。
- 注意数据库：代码能回滚，但数据库 schema 变更不能简单回滚——要做向前兼容的迁移，这是回滚最大的坑。
- 回滚后告警：回滚也要走通知，让相关人知道，并触发故障复盘。
加分点：主动提"数据库变更不可逆"这个坑，说明你考虑过回滚的真实边界，不是只会敲命令。
Q4四套环境的配置差异是怎么管理的？怎么保证一致性？+
- 配置外置：环境差异（域名、副本数、资源、外部地址）不写进镜像，镜像在所有环境完全一致，只有配置不同。
- Ansible 统一管理：各环境基础配置用 Ansible Playbook 维护，可复现、可审计。
- 镜像不可变：同一个镜像从 dev 一路晋级到 prod，杜绝"重新构建导致环境不一致"。
- 预发兜底：staging 尽量贴近生产，上生产前最后一道验证。
Q5钉钉审批是怎么对接的？审批没通过流水线怎么处理？+
- 对接方式：Jenkins 在生产部署 stage 前调用钉钉自定义机器人/工作流 API，推送审批卡片。
- 阻塞等待：流水线用 input 步骤或轮询审批结果，等到审批通过才继续，超时则自动终止。
- 未通过：审批拒绝则流水线标记为 ABORTED，不部署，并通知发起人。
- 可追溯：谁发起、谁审批、什么时间，都有记录，满足合规要求。