第1章 部署基础概念与流程概览

说实话，我刚入行时觉得部署就是「把代码丢到服务器上跑起来」。后来吃过几次亏才明白——部署是整个软件交付里最容易被低估的环节。今天这一章，我先跟你聊聊基础的东西。

1.1 什么是部署？先理清几个核心概念

部署（Deployment）本质上是把你的软件产物从开发环境搬到目标运行环境的过程。但这里面藏着几个容易混淆的概念，我挨个说清楚。

• 部署单位：你可能听过「工件」（Artifact）。它可以是jar包、Docker镜像、静态文件、数据库脚本，甚至是配置项。我以前接手过一个项目，部署清单里漏了数据库迁移脚本，结果上线后表结构对不上……嗯，从那以后我强制要求每次部署必须附带完整的工件清单。
• 环境：开发、测试、预发布、生产——每个环境都有自己的“脾气”。我习惯在预发布环境做一次完整演练，生产环境才能稳。
• 配置：代码和环境解耦。把数据库连接串、密钥这些单独管理，别写死在yaml里。曾经有同事把测试库密码不小心带到生产配置里，还好及时发现。
• 部署策略：蓝绿部署、滚动更新、金丝雀发布……不是每种业务都适合全量替换。这个后面会细讲。

概念	一句话解释	我的经验提醒
工件（Artifact）	可部署的产物包	版本号必须写清楚，不然回滚时找不到对应包
环境（Environment）	运行软件的基础设施	预发布环境要和生产保持“同构”，我踩过跨版本JDK的坑
配置（Configuration）	运行时参数	用配置中心或者环境变量，别硬编码
部署策略	上线方式	业务高峰期别用滚动更新，容易雪上加霜

1.2 部署的基本流程：一个完整的闭环

很多人以为部署就是把代码传上去启动服务。其实一个完整的部署流程至少包含五个阶段。我画了个流程图，你先看个整体印象。

1.3 每一阶段我在做什么

计划阶段
说白了就是决定这次发什么、怎么发、什么时候发。我习惯先确认变更清单，再评估风险——如果涉及数据库表结构变更，计划里一定要加数据兼容性检查。

准备阶段
打包、打标签、推送镜像、更新配置。这里很容易踩的坑是：多人同时发版时版本重叠。我曾经就因为忘记给镜像打唯一标签，导致两个团队错拉对方镜像，整个测试环境乱套。后来我强制团队在CI流程里自动生成带commit hash的标签。

执行部署
根据选定的策略进行更新。自动化脚本是关键，但别完全信任脚本——先在预发布跑一遍。我见到过脚本里写死路径导致生产目录被覆盖的惨案。

验证
不只是看进程有没有启动。需要做健康检查、接口冒烟、数据库连接检查，甚至业务场景级的验证。有一次我们换了缓存中间件，接口返回正常但业务数据错了——功能测试没覆盖特殊case。从那以后，我在验证清单里加了一条：「至少跑一条全业务流程的自动化用例」。

观察 / 回滚
部署完不代表结束。观察5-10分钟，看错误率、响应时间、日志。如果指标异常，迅速回滚。回滚方案必须在部署前就准备好，别等出问题再想。

1.4 部署验证：你以为启动了就是成功？

我一般把部署验证分成三层：

1. 基础设施层：网络通不通？端口通不通？磁盘空间够不够？记得有一次部署时磁盘只剩200M，服务启动就撑爆了。现在我会在部署脚本里前置检查磁盘阈值。
2. 应用层：进程是否运行？健康接口是否返回200？依赖的服务（数据库、消息队列）是否可达？
3. 业务层：关键业务流程能不能跑通？用户登录、下单、支付这些核心路径必须验证。我习惯在测试环境用自动化用例覆盖一遍，生产环境用少量真实流量（比如金丝雀）做验证。

1.5 避坑指南

1.6 本章小结

部署不只是复制文件。它是一个包含计划、准备、执行、验证、监控/回滚的闭环流程。理解这些基础概念，你才能在实际工作中减少事故。后面我会逐步展开每个环节的实战技巧和工具用法——但先把根扎牢。