<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>CI/CD - Naifan Li's Blog</title><link>https://blog.omagiclee.com/tags/ci/cd/</link><description>CI/CD - Naifan Li's Blog</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><lastBuildDate>Sun, 06 Sep 2026 00:07:00 +0800</lastBuildDate><atom:link href="https://blog.omagiclee.com/tags/ci/cd/index.xml" rel="self" type="application/rss+xml"/><item><title>数据平台 CI/CD 技术方案：从代码提交到服务、算子与数据发布</title><link>https://blog.omagiclee.com/posts/ai-data/data-platform/ci-cd/</link><pubDate>Sun, 06 Sep 2026 00:07:00 +0800</pubDate><guid>https://blog.omagiclee.com/posts/ai-data/data-platform/ci-cd/</guid><description><![CDATA[<p>一次视频切分算子升级，可能通过全部接口测试、正常完成部署，却把片段边界整体偏移一秒。服务没有报错，后续标签、向量与训练样本却已经受到影响。这是数据平台建设 CI/CD 时必须面对的问题：<strong>代码能够运行、系统能够升级、输出数据能够被使用，是三个不同的验收结论。</strong></p>
<p>本文承接 <a href="/posts/ai-data/data-platform/release-environments/" rel="">发布流程与环境管理</a>，把环境和发布原则细化为流水线、制品、测试与恢复协议。以系列文章中的 React + TypeScript + Vite、FastAPI 和独立 Worker 为背景；以下目录、脚本与发布协议均为建议设计，不代表 Data Flywheel 已经实现。工具文档核对日期为 2026-09-06。</p>]]></description></item><item><title>数据平台发布流程与环境管理：Dev、Staging、Prod 如何协作</title><link>https://blog.omagiclee.com/posts/ai-data/data-platform/release-environments/</link><pubDate>Sun, 06 Sep 2026 00:01:00 +0800</pubDate><guid>https://blog.omagiclee.com/posts/ai-data/data-platform/release-environments/</guid><description><![CDATA[<p>数据平台发布的不只是网页和 API，还可能包括采集连接器、计算任务、数据 Schema、模型权重、标签字典和向量索引。因此，“服务启动成功”远远不等于“发布成功”。一段正常执行的新代码，也可能静默生成错误数据。</p>
<p>环境管理的目标，是让每个版本经过有明确职责的验证，再以可追踪、可停止、可恢复的方式进入生产。下面是一套可按团队规模裁剪的实践方案。</p>
<p>结合 2026-09-06 阅读到的 Data Flywheel 代码，目前已有 SQLite 开发默认配置、Keycloak OIDC 与 PostgreSQL 接入代码，以及本地 Compose 基础设施配置。本文讨论的 Staging、制品晋级、灰度与恢复流程属于后续建设方案，不能将本地服务可启动视为生产发布体系已经完成。</p>]]></description></item><item><title>Git Commit 规范：提交语义、变更边界与合并校验</title><link>https://blog.omagiclee.com/posts/toolkits/github/commit-conventions/</link><pubDate>Sun, 06 Sep 2026 00:00:00 +0800</pubDate><guid>https://blog.omagiclee.com/posts/toolkits/github/commit-conventions/</guid><description>&lt;p>Commit 规范应同时明确提交语义、变更边界和兼容性影响，为代码评审、回归定位与版本发布提供依据。&lt;/p>
&lt;p>本文以 Conventional Commits 1.0.0 为格式基础，结合 Data Flywheel 项目讨论提出实施约定。标准要求与团队策略分别标明；项目策略为建议方案，示例不代表真实提交。&lt;/p></description></item></channel></rss>