企业官网建设流程全解析

我经常在技术面试里问候选人一个问题：你们团队用的是持续交付还是持续部署？得到的回答里，十个有八个会愣一下，然后补一句"反正就是自动上线，CD嘛"。这个理解不算全错，但漏掉了CD体系里最关键的工程哲学。更要命的是，当你打开搜索引擎输入"CD"这个词，能看到的结果至少横跨五个完全不相干的领域：软件研发里的持续交付/持续部署、Linux下切换目录的cd命令、已经快进博物馆的CD光盘、银行里的大额可转让定期存单，甚至还有人搜"抄底cd热门系列"。本文聊的，是软件工程语境下的那个CD——持续交付（Continuous Delivery）与持续部署（Continuous Deployment）。

这两个概念的区别，一句话就能说完：持续交付让软件始终处于"随时可以上生产"的状态，但最后一步由人来按；持续部署连最后这一步都自动化了，代码通过全部检查后直接进生产。但围绕这句话展开的工程体系、风险策略、流程架构和团队能力要求，差别比大多数人以为的大得多。这篇我打算从定义差异讲到流水线架构，再讲透蓝绿、金丝雀、滚动这三种交付模式的选型逻辑，最后分享一些落地时的实战经验和坑。

1. CD这个词被用乱了：先分清持续交付、持续部署和另外那些"CD"

1.1 从持续集成到持续交付：补上"自动发布"之前的那些环节

很多人习惯把CI/CD连在一起喊，好像这是一件事。严格说不是。持续集成（Continuous Integration）解决的核心问题是"代码频繁合入主干，且每次都自动验证"。它最早被提出，是为了终结"集成地狱"——多个开发分支各自跑得欢，一合并就炸，然后再花几天时间修冲突。

持续集成把"编译、单测、静态检查"自动化之后，大家发现自己站在一个新的台阶上：代码每天合主干，质量有自动化把关，主干基本是绿的。接下来顺理成章的诉求是——既然主干天天绿，能不能让任何一个绿的主干提交，都自动部署到测试环境，让测试人员随时有东西可验？这一步就是持续交付的雏形。

持续交付的定义，业界公认的版本来自Martin Fowler那套理论：软件构建、测试、部署到类生产环境的整个过程全部自动化，保证任何一个通过验证的构建产物，都能在几分钟内一键部署到生产环境。注意关键词：一键部署，但没有说系统自动部署。这就是持续交付和持续部署最微妙的边界。

持续部署则更进一步：通过所有验证的代码，自动发布到生产环境，全程无人干预。从代码提交到用户可见，没有一个人为审批节点。

1.2 定义精读：持续交付和持续部署只差一个"按钮"

把两个定义放在一起对比，差异点就非常明确：

一句话总结：持续部署 = 持续交付 + 自动发布。但这句话背后，是两条完全不同的工程路线。没有了最后那个人工审批环节，意味着测试覆盖率、监控告警、回滚机制、配置管理都必须达到"机器可以信任"的级别。这个差异我后面专门展开。

1.3 同一缩写，多个语境：搜索引擎里的CD到底什么意思

写这篇的时候我特意去搜了一下"CD"相关热词，结果相当混乱：有人搜"shell命令cd"，有人搜"cd机"，有人搜"usb网卡接上出现cd驱动器错误"，还有人搜"concierto de aranjuez hiderto kanai quintet three blind mice tmb cd"这种音乐专辑。同一个时间线上，CD这个词至少承载着五种完全不同的含义。

如果你是为了搞懂持续交付和持续部署来搜CD的，建议先把语境锁死：在技术社区里，CD前面通常会有CI/USB/I之分，或者直接写全称Continuous Delivery/Continuous Deployment。搜索引擎的结果里如果出现"cd ~/downloads && sudo apt install ./spark-store*.deb"这种带路径切换命令的内容，那是Linux命令行教学，跟软件工程里的CD没有任何关系。划清楚这个边界，能帮你省掉不少无效信息筛选时间。下面正式进入持续交付和持续部署的深度拆解。

2. 分水岭在前方：那个"上生产"按钮，到底留给人还是交给机器

2.1 按钮背后的风险模型：人为判断的价值在哪里

持续交付理念里，那个"发布按钮"是有意保留的。为什么？因为自动化测试无法覆盖所有风险。想象一个业务场景：银行月底结算前两小时，一笔重要对账任务正在跑批，这时代码刚好通过了全部自动化检查，按流程可以发布了。一个有经验的发布负责人会看一眼日历，说"今天不适合发"。自动化系统很难做出这种基于上下文的风险判断。

这不是说自动化不可信，而是说软件发布不只是技术动作，它还牵扯业务节奏、合规窗口、外部依赖状态。持续交付支持"随时可发布"，但把"什么时候真发"这个决策权留给有全局信息的人。对强监管行业、金融核心系统、医疗系统来说，这个按钮几乎是红线。

持续部署反过来，它信任全部的自动化质量链路，认为只要测试、监控、灰度机制足够完善，人点按钮引入的延迟和错误比自动化更大。这不无道理——人工操作最经典的失误就是"点了发布，忘了看日志"，等到业务报警才发现版本有问题。机器虽然也会犯错，但错得比人有规律，且更容易快速修正。

2.2 持续部署对工程体系的硬性要求

我不会劝每个团队都冲持续部署。但如果你真打算把那个按钮交给机器，下面这些能力缺一项都可能出事：

• 测试可信度：单元测试、接口测试、端到端测试的覆盖率要到一个擅长持续部署的团队才会有的水平，而且测试套件必须稳定不抖动，不能有大量flaky test（偶发失败的那种测试）。否则机器自动发布时，跑到一个不稳定的测试用例，门禁误拦还好，最怕误放。
• 观测体系：日志、指标、链路追踪必须齐全，且要能自动对比发布前后的核心业务指标。没有指标对比，新版本上线后用户已经在报错了，监控上还是一潭死水。
• 回滚自动化：发布失败后，系统要能在几分钟内自动或一键回滚到上一个可用版本。这里要注意，代码回滚容易，数据库回滚难，后面第五章我会讲。
• 配置一致性：测试环境和生产环境的差异要降到最低，否则在预发环境验得好好的，一上生产就崩，持续部署的自动化就变成了自动闯祸。

上面四条做不到，持续部署就是在放大缺陷，而不是提升效率。这也是为什么很多一线大厂把CI做到了极致，但生产发布依然保留人工审批，特别是涉及核心链路的版本变更。

2.3 两种模式的取舍决策表

做技术选型的时候，别听别人说"持续部署是趋势"就硬上。我按团队规模、业务形态、基础设施成熟度列了一个对照表，你可以拿自己的情况去对：

没有哪个选项更高贵。我见过一家做企业服务的公司，产品两个月发布一次大版本，硬上了持续部署，结果一半精力花在应对自动化发布失败上，效率反而更低。他们的问题不是工具不够好，而是选型跟业务节奏不匹配。

2.4 部署（Deployment）和发布（Release）不能混为一谈

聊CD绕不开两个词：Deployment和Release。很多人把它们当成同义词，但在发布工程里它们是两个不同动作。

部署（Deployment）：把新版本代码装到目标环境并运行起来。这个动作面向的是服务器。

发布（Release）：让新功能对外部用户可见，通常通过流量切换、DNS解析、功能开关等动作实现。这个动作面向的是用户。

蓝绿部署就是典型的"先部署、后发布"：新版本先部署到备用环境，跑起来，确认没问题，再通过负载均衡把流量切换过去。那一刻才是发布。如果切换后发现有问题，切回旧环境即可，这个回滚动作不影响用户，因为部署和发布被刻意拆开了。

搞清楚这个区别，再看持续交付和持续部署的争议会发现，大家吵的其实是"部署动作是否自动化"，而"发布动作"无论哪种模式都牵扯流量策略。这两个概念混在一起，讨论就很难有结果。

3. 从git提交到生产环境：CD流水线的工程架构拆解

3.1 一条合格CD流水线至少要有的六个阶段

很多团队把CD流水线理解成"CI跑完了自动部署一下"，这其实只是最粗糙的脚本，不是架构。一条能稳定支撑业务的CD流水线，至少包含下面六个环节：

1. 提交触发与变更识别：开发者推送代码到主干或指定分支，流水线被触发，同时记录本次变更对应的Commit ID、改动文件列表。
2. 静态检查与单元测试：跑lint、代码规范检查、安全扫描（SAST）、单元测试，并计算覆盖率。这一环节速度要快，让开发者尽早得到反馈。
3. 构建不可变制品：把代码构建成容器镜像、JAR包或二进制产物，并推送到制品仓库。这里的关键要求是"不可变"——同一个构建产物在测试环境验过什么，在生产环境就跑什么，不允许发布时重新编译。
4. 部署到类生产环境：自动把制品部署到staging（预发）环境，执行冒烟测试、契约测试、端到端测试。这个环节的目的是用最接近生产的条件验证制品。
5. 质量门禁校验与准入：汇总所有测试结果、覆盖率、安全扫描报告、性能基线对比，全部达标才允许进入发布管道。任何一个门禁不过，流水线直接红灯。
6. 生产发布执行：根据选择，人工点击发布按钮（持续交付），或系统自动执行灰度/蓝绿/滚动发布（持续部署）。

环节5极其重要但不是所有人都设计了。质量门禁不是把测试跑完就算，而是要有一个"汇总判定"的节点——就像高考录取，单科成绩再好，总分不过线一样不录。

3.2 环境分层设计：pre-production为什么是CD的命门

CD流水线的天敌是"环境漂移"——测试环境和生产环境存在肉眼可见的差异，导致测试结果失真。常见的环境分层是：

• dev环境：开发者本地调试用，数据随意，配置随意。
• test/集成环境：团队共享，跑自动化测试和联调，数据是脱敏过的脏数据或造数工具生成的合成数据。
• staging/pre-production（预发环境）：配置尽量与生产一致，数据用脱敏但结构完整的生产拷贝，专门做发布前的最后验收。
• production（生产环境）：真实流量，真实数据。

CD体系里，staging环境的质量决定了整个流水线的可信度。如果staging和生产差距太大，流水线跑得再顺也是自欺欺人。我见过最典型的反面案例：staging环境用了老旧的脱敏数据，生产环境的数据结构已经因为业务迭代加了新字段，结果所有staging上的自动化测试都通过，一发布到生产就报SQL字段不存在。

要缓解环境漂移，核心手段是基础设施即代码（IaC）——用Terraform、Ansible、CloudFormation这类工具把环境定义成代码，保证各个环境从同一个模板创建，再配合配置中心把环境差异收敛到显式的配置文件中，而不是靠运维手工改服务器。

3.3 质量门禁与不可变制品：没有它们CD就是裸奔

不可变制品的核心价值是"可复现"。打个比方，你不可能让厨师把"试吃时的那盘菜"跟"端给顾客的那盘菜"分别做一遍——口味一定会有差别。正确做法是同一个盘子里做了三份，试吃一份，上菜一份，留样一份。CD流水线里的制品仓库就是那个盘子：一个构建产物（比如Docker镜像），打上唯一版本号，在测试、预发、生产三个环境用同一个镜像。

质量门禁可参考的几个具体指标：

• 单元测试覆盖率低于80%不允许进入构建阶段。
• 安全扫描（依赖漏洞、密钥泄漏、镜像基础层漏洞）发现高危项不允许部署。
• 关键接口的契约测试失败不允许部署。
• 性能基线对比（P99响应时间、吞吐量）劣化超过阈值不允许发布。

这些门禁的设置原则是"宁可误杀，不可放水"。门禁多了必然增加等待时间，所以要把能并行的检查并行掉，尽量缩短流水线总耗时。

3.4 最小可用的Python项目CD流水线

讲理论太多容易飘，我用一个Python项目的GitLab CI配置作为例子，演示一个最小可用的CD流水线长什么样。这个项目用FastAPI写了一个HTTP服务，构建成Docker镜像，部署到staging环境。

stages: - test - build - deploy variables: APP_NAME: fastapi-demo IMAGE_TAG: $CI_COMMIT_SHORT_SHA test: stage: test image: python:3.11-slim script: - pip install -r requirements-dev.txt - pytest --cov=app --cov-fail-under=80 -q only: - main build: stage: build image: docker:24 services: - docker:24-dind script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG . - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG only: - main deploy-staging: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client - eval $(ssh-agent -s) - echo "$STAGING_SSH_PRIVATE_KEY" | ssh-add - script: - ssh deploy@staging-server "docker pull $CI_REGISTRY_IMAGE:$IMAGE_TAG" - ssh deploy@staging-server "docker stop $APP_NAME || true && docker rm $APP_NAME || true" - ssh deploy@staging-server "docker run -d --name $APP_NAME -p 8080:8080 $CI_REGISTRY_IMAGE:$IMAGE_TAG" environment: name: staging only: - main

这个配置里值得注意的细节：

• 镜像tag用$CI_COMMIT_SHORT_SHA，保证每个提交对应唯一镜像，版本可追溯。
• deploy阶段依赖SSH密钥，不要用明文密码，密钥存到GitLab CI/CD Variables里。
• 部署完只起到了容器启动的程度，严谨的做法还要加一个健康检查步骤：等待接口返回200，再标记部署成功。

再往外延伸一步，如果要把staging切换到生产环境，就是在deploy-staging后面再加一个deploy-production阶段，并在其中根据你的发布模式实现流量切换逻辑——比如蓝绿模式下切换负载均衡后端，金丝雀模式下调整流量比例。

3.5 流水线中最容易翻车的三个环节

第一，构建阶段的网络依赖不稳定。很多Python项目用pip装依赖，只要requirements.txt里写了不精确的版本号（比如numpy>=1.20），某天pip解析到一个不兼容的新版本，构建就挂了，或者在测试通过后构建出了个"假版本"。解决办法：用pip-tools或poetry锁定依赖版本，生成requirements.lock，让构建完全可复现。

第二，测试阶段偶发失败。一次端到端测试包含大量异步操作、外部依赖，某个接口偶发超时就会让流水线红灯。红灯多了，团队就会习惯性"重跑一下"，最后测试门禁形同虚设。解决办法：先识别哪些是flaky test，把稳定的用例放门禁，不稳定的用例单独放一夜跑，逐步修复。

第三，部署阶段的密钥和权限问题。SSH密钥过期、sudo权限不足、防火墙规则变更，都可能让部署脚本半路失败。这个问题不复杂但很烦人，我的建议是建立一个"部署环境健康检查"前置任务，每次部署前先验证密钥连通性、磁盘空间、目标服务状态，提前暴露问题。

4. 蓝绿、金丝雀、滚动：三类交付模式的运行逻辑和选型

4.1 三种模式的运行机制与直观类比

交付模式解决的是"新版本怎么替换旧版本"的问题。三种主流模式各有各的脾气：

• 蓝绿部署（Blue-Green Deployment）：准备两套完全相同的环境，蓝色跑旧版本，绿色跑新版本。先把新版本部署到绿色环境并全面验证，再把流量从蓝色整体切到绿色，完成发布。直观类比就是双通道换水：先在新管道里蓄好净水，确认合格后直接切换阀门。
• 金丝雀发布（Canary Release）：先让新版本服务一小部分用户或流量，比如先放5%，观察一段时间没有异常，再逐步扩大比例，直到100%。类比就是矿井里的金丝雀——先让一小部分冒险，探明风险后再全体跟进。
• 滚动更新（Rolling Update）：本质上就是分批替换。在负载均衡后的一组服务器中，一批一批地停止旧实例、启动新实例，滚动过程中新旧版本共存，直到全部替换完。类比是逐节更换火车车厢：一节换新、一节验收、再换下一节，整列车一直在线运行。

4.2 为什么"部署"和"发布"在这一章必须分开

第2.4节我提过部署和发布的区别，在交付模式这里会体现得非常清晰。

蓝绿部署是典型的"先部署后发布"：绿色环境的部署动作跟流量完全隔离，部署完成不代表用户能看到新版本，只有负载均衡切换那一刻才是发布。金丝雀和滚动则是"部署即发布"的渐进过程：新版本实例一启动，就有一部分流量被导过去，部署的动作本身就是发布动作的一部分。

这个区分直接影响你的回滚设计。蓝绿部署的回滚就是一次流量切换，把负载均衡重新指回蓝色环境，秒级完成。滚动的回滚则要重新走一遍替换流程，把新实例逐个替换成旧镜像，耗时更长。选模式之前，先想清楚你能接受多快、多复杂的回滚动作。

4.3 选型决策：按团队、按业务、按基础设施打分

不同模式对基础设施的要求差异很大，选型时可以按下面这张表对照：

我给一个务实的建议：刚起步的团队别一上来就金丝雀，先把滚动更新玩明白。Kubernetes原生支持滚动更新，配置一个strategy参数就能用，成本最低。等到发布频率高了、业务规模大了，再逐步引入蓝绿或金丝雀。金丝雀的门槛不在于技术，而在于"怎么判断新版本好不好"——你需要一套能快速对比新旧版本业务指标的观测系统，没有这套东西，灰度比例调大调小完全靠拍脑袋。

4.4 灰度发布在真实系统里的落地细节

灰度发布（金丝雀的一个变体）在实际落地时，至少可以从三个维度切分流量：

• 按实例比例：比如Kubernetes中设置10%的Pod运行新版本，90%运行旧版本。这个方式最简单，但对多租户系统不够精细。
• 按用户维度：按IP段、用户ID哈希、地域、设备类型、内部员工标签等维度分流。实现上依赖API网关的规则引擎或服务网格的流量策略。
• 按功能维度：结合Feature Flag（特征开关），同一个Pod里新代码已部署，但只有特定功能开关打开的用户能看到新功能。这个方式把"部署"和"发布"彻底拆开了，团队可以随时通过开关调整用户可见范围，是大型系统高频发布的主流手段。

灰度发布最怕两件事：一是指标对比口径不对，新旧版本的流量特征本身有差异，没做同维度对比就误判；二是灰度放量过快，5%没扛住就直接放到50%，事故规模瞬间放大。我个人的经验是"前5%验证功能正确性，15%验证稳定性，40%验证容量，再逐步到100%"，每一档停留时间根据指标观察结果灵活伸缩，没有异常就快，有异常立即止损。

5. 把CD真正跑起来的实战账：环境、回滚、权限和推进路线

5.1 环境漂移：CD最隐蔽的敌人

在我接触过的团队里，CD流水线搭得漂漂亮亮，最后毁在环境漂移上的例子实在太多。最典型的场景：测试环境通过、预发环境通过、一上生产就挂。

根因通常是这几类：

• 配置漂移：预发环境配了缓存集群，生产环境忘了配，或者配置中心的key对不上。
• 依赖漂移：两个环境的依赖版本不一致，测试环境装到了新版本，生产环境还在旧版本。
• 数据漂移：生产环境的数据量级、分布特征跟测试环境完全不是一回事，测试环境几千行数据跑得好好的SQL，生产环境几亿行数据直接慢查询拖垮数据库。

对策层面，我反复跟团队强调三件事：一是坚持IaC，环境定义写进代码仓库，版本可追溯；二是构建镜像只使用锁定版本的依赖，杜绝"环境里各装各的"；三是staging环境的数据要大，最好是脱敏后的生产快照，且定期刷新。做不到这三点，CD流水线就是在一条飘忽不定的公路上跑车，技术再好的司机也拦不住翻车。

5.2 回滚设计：数据是前进的，代码才叫回滚

很多人设计回滚方案时脑子里只有"切换旧版本镜像"这一个动作，等到发布事故真的发生时才发现，代码可以回滚，数据回不滚。

比方说，新版本上线了一个数据库迁移，给用户表加了一个字段并回填了数据。运行两天后发现有问题要回滚，代码切回旧版本，但旧版本不认这个新字段吗？或者这个回填的数据已经影响了下游统计，怎么处理？这就是经典的"数据前滚"问题——数据库变更本质上是单向前进的，版本回退后数据库结构往往不能直接跟着倒退。

现实中的解决思路是：设计时要求所有数据库变更向前兼容。加字段只加可空字段，删字段先停用不物理删除，回填数据用可逆策略补偿。配合"功能开关"这种逻辑回滚手段——代码不滚，只把新功能关掉——很多时候根本不需要物理回滚镜像。在写CD流水线之前，先跟DBA约定好"兼容性变更"的军规，比临时抱佛脚管用得多。

另一个被低估的点是制品保留策略。回滚需要旧版本还在，所以制品仓库要保留足够多的历史版本。我的经验是容器镜像至少保留最近100个版本或30天，同时保证每个镜像是不可变且可复现的。很多人只保留最近一两个版本，结果发布后第3天才发现性能问题，想回退时发现旧镜像早被清理了。

5.3 权限、审批和密钥：安全边界不该被自动化抹掉

持续交付和持续部署可以提高发布频率，但安全意识不能跟着自动化一起"自动化掉"。实际落地时这几个问题要提前想清楚：

• 谁有权限触发生产部署？建议按角色分权，开发者的权限到预发环境为止，生产发布权限由发布负责人或平台管理员持有。
• 人工审批怎么留痕？即使是持续交付的人工按钮，也要有明确的审批记录：谁、什么时间、部署了哪个版本、部署到哪个环境。全程审计日志是合规底线。
• 密钥管理怎么做？流水线里的SSH密钥、云厂商AccessKey、镜像仓库密码，一律不要硬编码在仓库里，统一放到CI/CD平台的加密变量或专用密钥管理系统里，定期轮换。
• 紧急发布通道要不要？要，但紧急通道不能变成日常通道。团队要约定清楚什么级别的事故可以走紧急发布，事后必须补审计记录。

有一次我们客户的生产环境出了紧急事故，需要立即发布热修复，结果发现发布负责人密钥过期了，流程被卡在SSH认证这一步。后来我们做了一次复盘，给所有核心密钥加了自动到期提醒，并把"发布账号密钥有效性"纳入环境健康检查。这种细节不踩过一次坑，很难有体感。

5.4 团队推进CD的建议落地顺序

最后分享一条我认为比较稳妥的落地路径。如果你所在团队还没跑通完整的CD，别一上来就追求全自动部署。我的推荐顺序是：

1. 先追版本可追溯：每个提交对应唯一制品，能说清楚生产环境跑的是哪个Commit的什么镜像。
2. 再追环境一致性：用IaC管理环境，锁定依赖版本，staging数据接近生产。
3. 然后补质量门禁：从单测覆盖率、契约测试、安全扫描这几个最基础的指标开始，逐步增加门禁项。
4. 接着实现持续交付：做到一键发布到生产，但保留人工按钮，先把发布节奏稳定下来。
5. 最后才考虑持续部署或灰度自动化：当上述能力都稳定了，再把最后那个按钮交给机器。

这套顺序背后有一条主线：每一步都在为下一步增加"对自动化的信任"。发布工程本质上不是一个纯技术问题，而是一个"自动化程度与信任程度相匹配"的工程决策。我个人在实际操作中的体会是，很多团队卡住的不是工具和技术，而是没有按这个顺序渐进，跳级推进导致翻车，然后又缩回全手动发布的老路。

CD这个词在技术圈里被讨论了十几年，到今天依然有大量团队还停在"CI很完善、CD很骨感"的阶段。希望这篇把定义差异、流程架构、交付模式这几个关键维度讲清楚之后，能帮你少走一点弯路。如果有机会，下次面试里再遇到"你们用持续交付还是持续部署"，你可以试着把那个按钮背后的风险模型讲给面试官，这比背一遍定义有意思得多。