先定义部署包需要完成什么
部署包应包含目标环境运行或构建所需的输入，而不是整个工作目录的快照。项目中可能存在源码、原始素材、依赖、运行数据、备份和本地凭据，它们的用途与保留位置不同。打包前先说明部署方式：目标机器重新构建，还是接收已构建产物。两种方式需要的文件不同，不能沿用同一份随手压缩的归档。
本文以源码包交给服务器构建为主要示例，使用虚构目录和文件名。需要的输入包括源码、锁文件、构建配置及明确引用的内容资源，生产配置和业务数据则由服务器独立保存。已有输出是否交付，要按部署方式决定。包体积小并不能证明安全，体积大也不一定表示错误，关键是每个成员都有明确用途。
Git 忽略规则不等于部署规则
忽略规则主要影响未跟踪文件的处理，并不会自动把已经跟踪的敏感文件从历史或其他归档工具中删除。普通压缩命令也不一定读取这些规则。项目存在一个忽略文件，不能据此推定部署包排除了密钥。应为实际打包工具配置明确的排除规则，并在归档生成后读取成员列表，验证规则是否按预期生效。
如果采用从版本控制导出的方式，还要检查哪些文件已经进入跟踪状态，以及构建是否依赖未跟踪的内容。依赖忽略状态来发现秘密只能提供部分信号。发现密钥曾被跟踪或上传时，应按实际暴露范围处理凭据，而不是只增加一条忽略规则。部署打包的验证需要面对最终归档，不能停留在配置文件看起来正确。
用受控暂存目录整理输入
可以把允许交付的目录复制到一个独立暂存位置，再从暂存位置创建归档。暂存目录必须位于明确的临时根下，并采用本次任务专属名称。复制时排除目录联接与其他未确认链接，避免把项目外的数据带进包中。最后清理暂存目录也要再次检查绝对路径边界，不能因它被称作临时目录就跳过范围核验。
暂存过程应产生文件清单，包括相对路径、字节数和校验值。清单帮助在传输后验证内容是否一致，也能发现路径中混入运行数据。文件仍在被修改时计算哈希和归档，可能得到不同快照，因此先停止相关生成任务或固定源码版本。归档自己的输出应放在源目录之外，避免打包过程把正在生成的包再包含进去。
密钥与配置采用明确的排除名单
环境文件、私钥、证书容器、凭据导出和本地认证配置应明确排除。名称规则可以覆盖常见文件，但不能发现所有改名后的秘密。还应检查项目的配置惯例，例如某个调试脚本是否把连接地址硬编码在正文中。源码包中可以保留不含真实凭据的配置示例，帮助目标环境配置，但它必须与真实配置区别清楚。
对脚本和文档做敏感模式检查时，只报告文件与命中类别，避免把秘密原文打印到日志。扫描结果是辅助证据，不能证明绝对没有秘密。进一步核对本次新加入的文件、配置来源和归档清单，能缩小遗漏。服务器读取真实配置时使用已受保护的独立路径，不应为了让包开箱可用而把生产环境文件加入暂存目录。
缓存与运行数据要分别排除
依赖目录、构建中间文件、编辑器缓存和测试输出通常不属于源码交付输入，可以从锁文件或命令重新生成。上传目录、数据库文件、备份和应用日志则属于运行数据，排除的理由是它们由另一套生命周期管理。把两者都称作缓存容易误导后续清理：不打包运行数据，不意味着这些数据可以从本机或服务器删除。
素材生成项目还需要区分原始图、生成图和实际被页面引用的资源。如果目标机器不运行素材生成步骤，那么最终资源必须交付，而原始素材可留在创作环境。若清单只排除所有图片，部署后的页面就会出现缺图。应从应用引用和构建脚本确定输入关系，不能只按文件体积设置一个粗糙的排除规则。
排除语法需要在真实工具中验证
不同工具的模式匹配、相对路径和目录递归规则可能不同。GNU tar 的排除模式要按照它的文档及参数顺序使用，Windows 复制工具则有自己的目录与文件参数。不要把一套忽略文件不加转换交给另一工具，并假定含义一致。先构造一个包含应保留与应排除对象的临时样例，核对最终成员列表。
对于链接，既要检查复制阶段是否跟随，也要检查归档阶段是否保存链接对象或目标内容。保存一个指向外部位置的链接，可能在目标机器解包后形成新的风险，即使包中没有包含外部数据。最简单的源码交付约定可以拒绝未登记链接，只允许普通文件和目录。确实需要链接时，将目标边界和目标环境行为写进验证步骤。
校验传输完整性与来源不同
文件哈希能够发现传输后内容与预期不一致，但哈希清单如果和归档一起被替换，并不能单独证明来源可信。传输应采用已经核验的通道，必要时使用签名或受保护的发布记录。目标机器同时检查归档校验值、清单格式和每个成员的哈希，可以帮助定位损坏。不要把一个匹配的哈希描述成已经完成所有安全核验。
清单路径采用规范的相对形式，拒绝绝对路径、父目录跳转和重复成员。解包时也需要验证链接与目标目录边界，不能先把不可信归档解到应用根目录，再检查里面有什么。将解包位置设为独立新目录，确认成员结构后再进入构建。已有运行数据和保护配置不应处于归档能够覆盖的范围。
内容更新应有独立部署入口
如果本次只更新文章和封面，部署入口应明确调用本批导入，避免顺带执行旧初始化内容、作品种子或历史排期导入。包里保留旧脚本是为了兼容维护，并不表示本次都要运行。部署模式可以共用构建与健康检查，但数据写入阶段应按任务范围选择。这样验收时才能清楚说明本次影响了哪些文章。
上线前创建加密备份，并记录备份覆盖的数据库、媒体和配置范围。包清单与备份清单承担不同职责，不能互相替代。部署失败后要明确是回退程序、恢复数据，还是两者都需要。内容导入若采用幂等批次标识，重复执行应验证已有清单而不是重新创建或重新计算日期，避免一次传输重试引发重复发布。
目标环境构建后再验证交付完整
源码包通过成员检查后，在目标兼容环境安装依赖并构建，确认没有依赖某个被遗漏的本地文件。检查正文、封面和动态接口，比只确认构建命令退出成功更完整。目标平台的原生依赖也要匹配，不能把 Windows 依赖目录当作 Linux 可运行输入。锁文件固定依赖关系，但并不会消除平台差异。
健康检查通过后再启用定时任务或切换外部入口，并保存应用版本与内容批次标识。实际验收中，检查资源链接返回正确媒体类型，确认保护配置没有出现在静态路径下。未通过时保留本次清单与日志，恢复旧版本。不要把重新上传同一个未经检查的包当作通用修复，先依据缺失成员或构建错误确定原因。
定期整理规则与例外
排除规则会随着项目增加新工具而过时，新生成目录或下载素材可能突然进入包中。每次新增工具时，说明其输入、输出和缓存位置，更新部署清单。例外资源需要附带原因，例如某组生成封面必须随内容交付，而高分辨率源图只留在本地。规则的维护重点是用途关系，不能无限堆积文件扩展名排除直到构建缺失输入。
可以设置归档成员数量与体积的变化提醒，但变化本身不应自动判定失败。一次合理新增内容可能带来大量资源，应该对照批次清单解释。清理旧暂存包时按本次任务目录边界操作，保留必要验收记录。部署记录采用相对路径和校验值即可，避免把个人工作目录、登录账号或秘密配置内容写入可公开报告。
先列成员再执行服务器更新
下面示例展示 GNU tar 的源码包排除思路，归档位于源目录之外，完成后列出成员并计算校验值。规则只覆盖示例项目惯例，实际还需要加入项目专属运行目录和凭据位置。成员检查应拒绝禁止路径，敏感扫描则检查允许文件中的意外内容。两项检查通过后再上传，不能只看压缩命令没有报错。
若在 Windows 上先复制暂存目录，应使用对应工具排除目录联接，并在打包前检查暂存树中没有未登记的重解析点。无论采用哪种工具，最终验收对象都是实际归档及其清单。把这些结果与部署记录一起保存，后续恢复或调查时才能知道服务器接收了哪些输入，以及它们与本地验收版本是否一致。
实现片段
# example-blog 为已确认的源码目录；输出放在其外部。
tar --exclude='./node_modules' --exclude='./.nuxt' --exclude='./.output' \
--exclude='./runtime' --exclude='./reports' --exclude='./.git' \
--exclude='.env' --exclude='.env.*' --exclude='*.pem' --exclude='*.key' \
--exclude='*.pfx' --exclude='*.p12' --exclude='id_rsa' --exclude='id_ed25519' \
--exclude='*.log' --exclude='*.enc' \
-czf /tmp/example-blog-source.tar.gz -C /work/example-blog .
tar -tzf /tmp/example-blog-source.tar.gz
sha256sum /tmp/example-blog-source.tar.gz
# 上传前核验成员名单、禁止路径与允许文件中的敏感信息。
评论 · 0