介绍
有用的发布必须就是实际通过检查的版本。如果包里包含另一个镜像，或预发布环境运行着旧版本，那么报告写着“通过”也不够。
这个累积构建的 DeskLite 基线已应用前面学过的源代码、凭据、依赖、容器、日志和关卡控制。你将关联当前源代码提交、实际检查过的镜像、生成的报告、包字节和本地运行的预发布版本。新增操作只有提供的发布工作流程、tar 打包和校验和验证。
检查正常工作的累积基线
在本步骤中，你将识别即将发布的源代码版本和正常工作基线。
cd /home/labex/project/ticket-release
git status
预期工作区干净。git rev-parse HEAD 打印当前提交的完整标识符；HEAD 表示当前检出的版本：
git rev-parse HEAD
标识符因会话而异。稍后，它必须与发布清单和运行中应用的版本一致。
cat Dockerfile
找到明确列出的业务文件复制、离线依赖安装和 USER nobody。缓存 Python 基础镜像和 wheel 均已准备好。镜像构建期间的软件包构建操作，与最终应用的非 root 运行身份是两回事。
.venv/bin/python -m pip show requests
预期为 2.32.4。同样的固定版本依赖将安装到候选镜像中。
bash /srv/ticket-release-client/sender.sh
预期返回 HTTP 200 和原始工单。该专用客户端已经读取受保护的新令牌文件；旧令牌已撤销。不要将任何一个值复制到发布元数据中。
运行实际关卡及其负向对照
在本步骤中，你将在打包前确认候选版本和关卡均正常工作。
bash gate.sh
预置阶段包装脚本运行真实机密信息/历史、依赖和源代码检查，将已提交应用构建为 Docker 镜像，并启动这个实际候选版本。功能测试检查源代码版本、Requests 2.32.4、真实非 root UID 65534、原始工单，以及旧/缺失/错误令牌的拒绝行为。
关卡尚不发布最终包。只有检查和测试对同一源代码及镜像的结果一致时，它才记录已接受的候选版本。
现在测试可信负向对照：
course-release gate-test
辅助程序使用同一个关卡，先运行真实固定规则凭据发现，再运行实际的缺失输入扫描器错误。预期二者均在构建/测试前被阻止，状态分别为 1 和 2。之后它恢复正常控制模式，并保持运行中的预发布服务不变。
检查仍只覆盖课程固定的练习令牌/SQL 规则和两条选定依赖公告；它们不是完整的生产审查。
生成与已检查镜像绑定的元数据
在本步骤中，你将根据实际接受的结果生成发布证据，而非手动输入通过声明。
course-release manifest
辅助程序导出实际检查过的 Docker 镜像，并在 release 下创建三个文件：image.tar、checks.json 和 manifest.json。它们是工程交付输入，不是单独的学员调查报告。
cat release/manifest.json
source_commit 必须等于 git rev-parse HEAD。image_id 标识准确的构建镜像，而非可移动的标签。checks_sha256 绑定实际脱敏检查报告；image_sha256 绑定导出的镜像字节。run_id 将记录关联到这次实际接受的检查运行。
cat release/checks.json
预期包含状态 0、各项检查状态、工具版本和相同源代码提交。这里不应包含凭据值。清单自动生成；不要编辑字段来声称另一个产物通过了检查。
打包并检查发布字节
在本步骤中，你将创建真实归档及其校验和。
tar 将文件组合成归档。-c 创建归档，-f 指定输出文件名，-C release 选择读取内容的目录。最后的 . 表示该目录内的全部内容：
tar -cf release.tar -C release .
归档位于输入目录之外，因此不会包含自身。-t 列出已有归档内容，-f 指定归档名：
tar -tf release.tar
预期看到三个生成文件（可能带有 ./ 前缀），以及一个目录条目。
SHA-256 根据文件字节计算摘要。sha256sum 打印摘要和文件名。熟悉的 > 重定向保存该结果：
sha256sum release.tar > release.tar.sha256
-c 读取保存的校验和记录，并比较实际文件：
sha256sum -c release.tar.sha256
预期为 release.tar: OK。这证明字节与记录的摘要一致。单独的校验和不能证明谁发布了文件，也不能证明检查有效。
验证报告与产物的绑定
在本步骤中，你将检查超出包自身所报告校验和的内容。
course-release verify release.tar
发布辅助程序读取实际归档，拒绝意外/重复成员，将清单与真实检查过的导出产物比较，检查原始报告，并对包内镜像字节计算哈希。它还要求当前源代码提交一致。
预期得到绑定源代码、报告、镜像和完整包摘要的 PASS。这会在课程本地发布流程中为这些准确的包字节登记批准。编辑 checks.json 声称通过，或为更改后的镜像重算校验和，都不会产生匹配的已接受检查运行。
这是具有受保护本地记录的教学流程。学员拥有 sudo 访问权限，意味着该 VM 不是生产信任边界。我们测试的是提供的发布过程，并不声称实现了发布者签名或外部授权机构。
部署准确的包并检查运行状态
在本步骤中，你将部署已批准的字节，并比较实际运行行为与生成记录。
course-release deploy release.tar
辅助程序再次验证包，加载其中的镜像，并使用该准确镜像 ID 启动本地预发布服务。仅暴露本地服务端口和必需的只读签发工具注册表；私密凭据不会被写入镜像。
course-release state
状态包含相同源代码/镜像标识符和完整包摘要。现在检查应用自身：
curl http://127.0.0.1:8080/health
预期得到相同的 source_commit、Requests 2.32.4 和 UID 65534。
bash /srv/ticket-release-client/sender.sh
预期返回 HTTP 200 和原始工单。检查未认证访问：
curl -i http://127.0.0.1:8080/tickets
预期返回 401。候选关卡也测试了旧令牌和错误令牌。仅有匹配的清单不能证明这些真实运行行为。
拒绝字节被更改的包
在本步骤中，你将在不改变运行服务的情况下，测试完整性约束。
cp 复制文件。保存有效包的逐字节备份：
cp release.tar release-original.tar
printf 打印这个已知标记。>> 追加到文件，而 > 会替换文件。只向本练习的包追加几个字节：
printf 'changed' >> release.tar
sha256sum -c release.tar.sha256
预期出现 release.tar: FAILED 并以非零状态退出。即使 tar 读取器忽略尾部数据，完整包字节也已改变。
course-release deploy release.tar
预期出现 RELEASE BLOCKED，因为这些准确字节未获批准。该非零结果是有意的。用户新写的校验和不能取代工作流的源代码/报告/镜像绑定，也不能取代对原始包的批准。
curl http://127.0.0.1:8080/health
先前批准的版本继续运行。下一步将在最终验证前恢复有效包。
恢复并确认最终交付
在本步骤中，你将让原始验证过的包和正常工作的预发布服务保持完整。
cp release-original.tar release.tar
sha256sum -c release.tar.sha256
预期再次得到 release.tar: OK。
course-release verify release.tar
course-release state
恢复后的包与真实检查过的源代码/镜像，以及已运行的预发布服务匹配。课程检查独立测试关卡失败对照，拒绝改变后的字节，检查实际镜像层中的目标凭据，并验证实际的正向/拒绝行为。
现在你拥有发布归档、校验和、生成的清单和真实报告，以及相匹配的运行版本。无需手写调查材料。生产交付还需要发布者身份、外部授权和更广安全覆盖等控制；本课程不声称本地校验和能够证明这些性质。
总结
你关联了实际检查过的源代码提交、测试过的非 root 镜像、原始生成报告、发布包字节和本地运行的预发布版本。正向和拒绝行为保持正确，而修改后的字节被拒绝。校验和支持完整性验证；该本地流程不声称提供发布者签名或外部生产授权。
