一、企业开发的基本路径个人项目常见流程是“写代码—本地运行—提交 Git”。进入真实企业环境后通常还会增加一套完整的质量控制与发布过程因为代码一旦进入生产环境就可能影响其他模块和真实用户。一个典型的软件功能开发过程可以概括为需求 → 开发分支 → 编码 → Commit / Push → Merge Request → CI 自动测试 → Code Review → Merge → Staging → E2E 测试 → 灰度发布 → Production → 监控理解这条路径是从个人开发过渡到企业工程的重要一步。二、Merge Request 与 Code Review开发新功能时通常会创建独立 Git 分支例如feature/user-history功能完成以后执行 Commit再 Push 到 GitLab 或 GitHub并创建 Merge Request。GitHub 中对应的概念通常称为 Pull Request。Merge Request 可以理解为一组代码修改已经完成现在申请进入项目正式代码。随后进入 Code Review。Reviewer 会检查业务逻辑、代码结构、潜在 Bug、性能、安全性和可维护性。如果发现问题通常由原开发者继续修改并重新 Push。Merge Request 会自动更新。Review 通过以后代码才会被 Merge 到主分支。因此Code Review 的主要作用是让团队成员从工程角度判断代码是否适合进入正式系统。三、CI/CD 是什么CI 是 Continuous Integration即持续集成。代码 Push 后服务器可以自动执行一系列检查例如编译 → 单元测试 → 接口测试 → 代码规范检查 → 构建CI 可以理解为机器自动完成基础质量检查。Code Review 主要由工程师判断设计和实现是否合理两者可以同时进行。CD 通常表示 Continuous Delivery 或 Continuous Deployment可以暂时理解为把已经通过检查的软件版本继续自动部署到后续环境。因此一套常见流程是提交代码 → CI → Code Review → Merge → 构建 → 自动部署四、Staging、E2E 和 Canary代码 Merge 后通常还不会直接开放给全部用户。Staging 是预生产环境用于尽量模拟真实服务器、数据库、Redis、外部服务等生产条件。E2E 是 End-to-End Test即端到端测试。例如一个电商系统可以完整验证登录 → 搜索商品 → 加入购物车 → 下单 → 支付它关注完整业务过程能否正常完成。Canary 通常指灰度发布。例如系统有 100 台服务器新版本先部署到其中少量服务器只让一部分真实请求进入新版本。确认错误率、延迟和业务指标正常以后再逐渐扩大范围。因此本地成功运行只是软件发布过程中的一个早期阶段。五、上线以后还发生什么Production 是真实用户使用的生产环境。系统上线后需要持续监控例如请求量 响应时间 错误率 CPU 内存 数据库状态异常达到一定条件后可以触发 Alert也就是告警。On-call 是值班机制。某个时间段由明确的工程师负责响应生产故障并协调问题定位和恢复。SLO 是 Service Level Objective即服务等级目标。例如99.9% 请求成功 P95 响应时间 300ms因此企业软件开发最终形成的是一个持续循环开发 → 测试 → 发布 → 监控 → 发现问题 → 修复 → 再发布。理解这条路径以后Git、CI/CD、Code Review、Staging、灰度发布和 On-call 等概念就能够进入同一个工程框架。