为什么要在部署流水线里做代码检查
前两天同事小李上线了个新功能，本地测试没问题，结果一推到生产环境就报错。查了半天才发现是有个变量名拼错了，这种低级错误其实在提交代码时就能拦住。现在我们团队的部署流水线里都加了代码检查环节，类似的问题基本不会再发生。
常见的检查项有哪些
静态代码分析是最基础的一环。比如用 ESLint 检查 JavaScript 语法风格，Pylint 扫描 Python 代码里的潜在问题。这些工具能在不运行代码的情况下发现拼写错误、未使用的变量、不符合规范的写法。
还有更进一步的，比如单元测试覆盖率。流水线会自动跑一遍测试用例，如果新增代码没覆盖到关键路径，就会提醒补全。有些项目还集成了安全扫描，像检测是否误把密钥写进了配置文件。
怎么接入 CI/CD 流程
以 GitLab CI 为例，在 .gitlab-ci.yml 里加个 job 很简单：
lint-check:
image: node:16
script:
- npm install
- npx eslint src/**
only:
- merge_requests这样每次提合并请求时都会自动执行 ESLint。如果报错，MR 页面上就会显示失败标记，没法直接合并。
别让检查变成负担
刚开始我们设得太严，连空格数量不对都报错，导致开发频繁被打断。后来调整策略，分成警告和错误两级。非关键问题只给提示，严重问题才阻断流程。本地也配好编辑器插件，大部分问题在写代码时就已经亮红了。
上周上线那个活动页面，从提交到发布全程不到二十分钟，中间自动完成了代码检查、构建、测试和部署。没人手动点按钮，但每一步都稳稳当当。