持续交付是什么？
持续交付（Continuous Delivery）是一种软件开发实践，核心目标是让代码变更能够随时以自动化的方式安全、快速地部署到生产环境。简单来说，就是每次开发人员提交代码后，系统会自动完成测试、打包、部署等流程，确保新功能或修复能随时上线。
比如你在一个团队做办公协同软件的开发，每次修改了一个文档共享的小问题，提交代码后，系统自动跑一遍测试，确认没引入新 bug，然后把更新推送到预发布环境。产品经理点开链接试用没问题，一键就能发布给所有用户——这个过程背后就是持续交付在起作用。
它和持续集成有什么区别？
很多人容易把持续集成（CI）和持续交付（CD）搞混。持续集成关注的是“合并代码后自动构建和测试”，而持续交付更进一步：不仅要测通，还要保证能随时部署。你可以理解为，持续集成是持续交付的前半段。
实际工作中的典型流程
一个典型的持续交付流水线可能包含这些步骤：代码提交 → 自动构建 → 单元测试 → 集成测试 → 代码质量扫描 → 部署到预发环境 → 手动验收（可选）→ 自动发布到生产环境。
例如你们公司用 GitLab CI/CD，配置好 .gitlab-ci.yml 文件：
stages:
- build
- test
- deploy
build_job:
stage: build
script:
- echo "Building the app..."
- npm run build
test_job:
stage: test
script:
- echo "Running tests..."
- npm test
deploy_prod:
stage: deploy
script:
- echo "Deploying to production..."
- bash deploy.sh
when: manual这里最后一步设置为 manual，意味着测试通过后由负责人手动触发上线，既保证了自动化效率，又保留了控制权。
为什么办公类网络系统也需要它？
现在很多企业用的办公系统，比如内部审批、考勤、知识库平台，其实也是软件。以前改个按钮颜色都要等版本发布，可能一个月一次。用了持续交付后，小改动当天就能上线。IT部门响应更快，员工体验也更好。
比如财务系统发现报销金额显示错位，前端改完提交代码，半小时后就能在正式环境看到修复效果，不用再等“下次大版本更新”。
实现它需要什么基础？
不是所有团队一开始就能上持续交付。几个关键前提是：代码仓库统一管理、自动化测试覆盖核心功能、有稳定的部署脚本、环境配置尽量一致（开发、测试、生产）。如果每次上线还靠人肉复制文件，那谈不上持续交付。
工具链也很重要。常见的组合有 Jenkins + Git + Docker，或者 GitHub Actions + Kubernetes。选择哪种不重要，关键是流程要能自动化跑通。
持续交付不是追求“每分钟发布十次”，而是让发布变得平常、低风险。当你团队里的实习生也能安全地上线代码时，说明这套机制真正落地了。