NX-MOC

基础

nx-overview project-json-file-explained Monorepo 测试架构

“A typical way to conceptualize the application is as ‘containers’ that connect, package, and build functionality implemented in libraries.” Nx中的一个思想

进阶

Nx管理mcp

面试要点

来自 ci-cd-planning-interview-question 的面试视角整理。

一句话回答

CI/CD 的重点不是”会不会写 yml”，而是能不能让反馈更快、减少无意义构建、稳定构建测试发布规则，以及针对多端项目设计不同的流水线路径。

CI 设计原则

四个目标

1. 反馈更快：改完代码后尽快知道有没有问题
2. 减少无意义构建：不要每次改一个模块就把全仓跑一遍
3. 规则稳定：构建、测试、发布规则要一致、可预期
4. 多端差异化：不同应用走不同的流水线路径

实际做法（Nx Monorepo）

nx affected -t lint typecheck test build

• nx affected 根据 git diff 计算影响范围
• 只对受影响的项目跑 lint、typecheck、test、build
• 大幅减少 CI 时间，尤其在大仓库里

如果仓库同时包含前端、BFF、微服务和 agent，更合理的做法通常不是“PR 全量跑所有测试”，而是用 Monorepo 测试架构 的思路分层运行：PR 跑 fast / affected，nightly 跑全量集成与 eval，release 再做环境验证。

流水线分层

PR 阶段（快速反馈）：

• lint（代码规范）
• typecheck（类型检查）
• 受影响项目的单元测试

合并后（完整校验）：

• 全量 typecheck
• 全量 test
• build 验证产物

发布阶段（按需触发）：

• 版本号校验（tag 和 package.json 一致性）
• 按平台构建（桌面端产出 dmg/exe/appimage）
• 产物上传和发布

面试回答主线

如果问”你怎么规划 CI/CD”

我会分三个阶段。PR 阶段追求快速反馈，只跑 lint、typecheck 和受影响测试；合并后做完整校验，确保主干稳定；发布阶段按应用类型走不同路径，比如 Web 端部署到 CDN，桌面端按平台构建安装包。核心是让每一步都有明确目的，而不是盲目全量跑。

如果问”多端项目 CI 怎么设计”

不同端有不同的构建目标和产物。Web 端重点是构建产物和部署到服务器；Desktop 端需要按平台（macOS/Windows/Linux）分别构建；API 端重点是类型检查和测试。我会用 Nx 的 affected 机制让 CI 只跑受影响的部分，同时给不同端设计独立的发布流水线。

和亿格云场景的关联

亿格云作为企业安全平台，CI/CD 里我会额外重视安全扫描（依赖漏洞检查、SAST）、产物签名和发布审计。企业产品的发布不是”能跑就行”，而是要可追溯、可回滚、有审计记录。

常见误区

只说”用 GitHub Actions”

工具不是重点，重点是流水线怎么设计、怎么分层、怎么优化反馈速度。

不考虑增量构建

大项目全量跑 CI 会非常慢，affected 或类似机制是必须的。

忽略安全扫描

企业产品里，依赖漏洞扫描、代码安全扫描应该纳入 CI。

最短记忆方式

CI/CD = 快速反馈 + 增量校验 + 分层流水线 + 多端差异化 + 安全审计

Related notes

• nx-overview
• project-json-file-explained
• Monorepo 测试架构
• ci-cd-planning-interview-question