代码提交触发自动化流程
小李是某电商平台的技术负责人，每次大促前最怕出问题。以前发版本要熬夜、手动操作，一不小心就点错服务器。现在他们团队用了持续部署，代码一合并，系统自动跑完整套流程，几分钟就上线了，他终于能准时下班。
这一切的起点，就是开发人员把代码推送到主干分支。比如在 Git 仓库执行 git push origin main，这个动作会触发 CI/CD 工具（比如 Jenkins、GitLab CI 或 GitHub Actions）开始工作。
自动化构建与单元测试
系统收到代码后，第一件事是拉取最新代码，然后运行构建脚本。前端项目可能是 npm run build，后端 Java 项目则可能是 mvn package。这一步生成可部署的产物，比如一个 Docker 镜像或者静态资源包。
紧接着跑单元测试。如果连最基本的逻辑都过不了，就没必要继续往下走。比如有个订单计算函数写错了，测试一失败，流程立刻中断，开发者马上收到通知去修复。
代码质量检查与安全扫描
构建通过后，系统会用工具做静态分析。比如 ESLint 检查 JavaScript 风格，SonarQube 扫描潜在漏洞或坏味道代码。同时还会用 Dependabot 这类工具检查依赖库有没有已知安全问题。
曾经有次，团队引入了一个有远程执行漏洞的 npm 包，CI 流程卡在安全扫描这步，避免了一次可能被攻击的风险。
自动化集成测试与预发布部署
代码没问题，下一步是部署到预发布环境。这个环境和生产几乎一样，有独立的数据库、缓存和域名。部署完成后，自动运行集成测试，比如用 Cypress 或 Postman 跑 API 测试用例。
比如模拟用户下单流程：登录 → 加购 → 提交订单 → 支付。只要其中一步失败，部署就停止，不会影响真实用户。
自动发布到生产环境
所有测试都通过，系统就会自动把新版本推到生产环境。常见做法是滚动更新 Kubernetes Pod，或者替换 AWS 的 ECS 任务定义。
以他们的前端项目为例，CI 脚本会把打包好的文件上传到 CDN，并刷新缓存。整个过程不需要人点“确认”，但会发消息到钉钉群：“v1.8.0 已上线”。
# 示例：GitHub Actions 中的部署片段
deploy:
runs-on: ubuntu-latest
needs: test
if: github.ref == 'refs/heads/main'
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Deploy to production
run: |
scp -r dist/* user@server:/var/www/html
ssh user@server "systemctl reload nginx"监控与回滚机制
上线不是终点。系统会立刻接通监控，观察错误率、响应时间、CPU 使用情况。如果发现异常，比如 500 错误猛增，自动触发回滚——把上一个稳定版本重新部署上去。
有次他们上线了个新功能，结果监控显示数据库连接数飙升，两分钟内就被自动回滚了。运维甚至还没来得及反应，用户几乎无感。
持续部署不是追求“快”，而是让发布变得安全、可重复。每个步骤都像流水线上的检测点，有问题就停，没问题就走。时间久了，团队不再害怕上线，反而觉得是个日常动作，就像每天早上打卡一样自然。