阿拉丁·CI/CD 与部署编排工坊

问题从哪来

写好业务代码之后，配一套能跑的 CI、写不翻车的 Dockerfile、把服务挂到 K8s 上，往往还是每次从零抄 YAML：镜像标签用 :latest、探针漏配被运维打回、密钥误提交进仓库。skillhub 上常见的部署类能力多是单点——只绑一家云、只做评审、或只给规范文档，很少把「构建 → 测试 → 安全 → 部署 → 发布」整条链路当成可版本化的工程产物。

技能在做什么

阿拉丁·CI/CD 与部署编排工坊面向「给路径或一份 profile.json → 拿到可提交、可先校验的交付配置」。核心能力包括：

• 自动探测仓库：扫描 requirements.txt、package.json、go.mod 等 marker，推断语言、构建/测试命令与端口，落成统一中间表示。
• 多平台 CI 对齐输出：同时生成 GitHub Actions、GitLab CI、Jenkinsfile，stage 语义一致。
• 容器与编排：多阶段 Dockerfile（非 root、健康检查）+ docker-compose.yml；K8s Deployment/Service/Ingress（探针、资源限制、securityContext）及 Helm 骨架。
• 质量门禁接线：把 aladin 系列的代码审查、接口契约测试、SQL 迁移检查以流水线 stage 形式内嵌，而不是只跑一次性本地脚本。
• 本地 dry-run：用标准库做 YAML 结构检查、疑似硬编码密钥告警、:latest 提醒、探针缺失等静态排雷。
• 发布与复盘闭环：语义化版本、CHANGELOG、tag 与发布说明；cicd_retro 把真跑踩坑写入 playbook，下次 cicd_build --playbook 自动硬化配置。

典型工作流是：探测或填写 profile → 生成 CI/容器/K8s 产物 → 本地校验 → 提交后由平台执行；脚本不联网、不代你推集群，只产文本配置。

边界与注意点

• 产出偏通用容器/K8s，不替代单一云厂商专有 PaaS 的深度集成，也不做容量规划、多区域容灾、服务网格选型等 SRE 架构决策。
• 不提供拖拽式可视化编排器；所有产物是可进版控的 YAML/Groovy/Dockerfile。
• 校验是静态的：不跑容器、不连 apiserver；涉密合规环境仍需先确认是否允许本地扫描与留痕。
• 与 aladin 系列分工：code-pilot / api-pilot / sql-forge 管质量与存储，本技能管交付收口，五者可串成统一工程闭环。