浅念
8cea7dee20
- SiteForge Enterprise V8.10.0-dev.1 upstream source (210 tests) - Fix: v8_workflows._mapped_input now reads both 类型/分类 columns so WXR imports keep post/product types instead of collapsing to page - Docs: trade-pro theme port spec (R3) and implementation plan Co-Authored-By: Claude Code <noreply@anthropic.com>
4.2 KiB
SiteForge V7 — Web + Docker 部署与正式发布
1. 配置
首先下载源码到可信环境，进入项目目录。Windows PowerShell 首次生成 .env（不会覆盖已存在密码）：
docker run --rm -v "${PWD}:/project" -w /project python:3.12-slim python scripts/init_config.py
切勿把 .env、管理员密码、发布签名密钥或源站数据库导出提交到代码库。数据库密码必须为 URL 安全字符或在连接字符串中正确编码。
2. 单机验证
docker compose up -d --build
docker compose ps
docker compose logs -f siteforge worker
浏览器打开 http://localhost:8787/，登录后进入 /factory-studio（建站）、/operations（CMS 导入、人工复核、构建、审批、发布）、/theme-gallery（主题预览）。
3. PostgreSQL + Redis 的企业测试组合
docker compose -f compose.enterprise.yaml up -d --build
docker compose -f compose.enterprise.yaml ps
docker compose -f compose.enterprise.yaml logs -f siteforge worker postgres redis
这是新数据库部署，不要把 V6 的 SQLite 数据卷直接绑定给 V7 的 PostgreSQL 版本。先备份，再制定一次性数据导入和对账计划。postgres-smoke CI Job 具有独立临时 PostgreSQL 数据库的基础烟雾测试；当前交付环境无法运行该 Job 或本地 Docker/PostgreSQL。
Redis 当前只作为通知通道，数据库是任务事实来源，Redis 不提供 Exactly-Once 保障。
4. 接入 Art Design Pro 官方工程
联网取得官方项目（开源地址：https://github.com/Daymychen/art-design-pro），按照官方文档所需 Node.js / pnpm 版本安装：
python scripts/install_into_art_design_pro.py /path/to/art-design-pro
python scripts/install_into_art_design_pro.py /path/to/art-design-pro --apply
cd /path/to/art-design-pro
pnpm install --frozen-lockfile
pnpm build
注册菜单：网站项目、主题库、可视化编辑、CMS 迁移、企业运行中心、审批与发布。需要同域代理 /api、/ui、/editor、/preview、/login 等到 SiteForge，且保留服务端 Session + CSRF。正式交付前要验证前端角色菜单与服务端 RBAC 一致。
本压缩包不包含官方 Art Design Pro 整体源代码；当前 Docker 默认仍运行 SiteForge 内置 Web 后台。
5. 单独部署 Release Agent
推荐在目标服务器中部署独立 Agent，只授予一个发布目录的写入权限，并在 HTTPS 反向代理和网络白名单后面运行。
docker compose -f compose.release-agent.yaml up -d --build
目标机器 .env 配置 SITEFORGE_DEPLOY_SECRET（至少 32 字符），控制端配置 SITEFORGE_DEPLOY_STAGING_URL 和 SITEFORGE_DEPLOY_STAGING_SECRET，或 PRODUCTION 对应值。
Agent 在容器里使用 /srv/releases/<site-id>/releases/<hash>/ 保存不可变版本，并通过 current 指针切换。外部网站域名应由 Nginx/Caddy 指向该只读版本目录或代理 Agent 的 /public/<site-id>/...；需要由运维为每个站点配置域名，当前不是自动配置 DNS/CDN 的产品。
发布接口不是公网通用文件上传：必须经过构建完成、迁移与 HTML 质量检查、独立审批，并使用 HTTPS HMAC 请求签名，签名绑定 HTTP 方法和精确路径，存在 5 分钟的时间戳有效窗口。务必开启 TLS、源 IP 限制和审计日志。
6. CI 与运行验收
python -m pip install -r requirements-dev.lock
python -m pytest -q
python scripts/verify_release.py
for file in app/static/*.js; do node --check "$file"; done
完整 GitHub Actions：.github/workflows/ci.yml。包含 Python 3.12/3.13 测试、静态 JavaScript、Docker 镜像及 PostgreSQL 冒烟配置；但必须在你的仓库中真正跑通流水线，确认依赖、容器构建、数据库行为才可标为通过。
7. 升级时的数据保护
不要 docker compose down -v。先备份 SQLite/PostgreSQL、主题、媒体、构建产物及发布历史，再在隔离测试环境进行恢复和预演；确认旧网站 URL/SEO 清单无差异后再切换正式流量。不同 Compose project 的同名卷默认并不共享，升级流程不得靠“覆盖 ZIP”代替数据迁移。