Prod Deploy

生产环境发布部署自动化技能。用于 SM 交友网站 (zmq-club.com) 的一键发布流程，包括：数据库备份、结构对比、前端构建、代码部署、迁移执行、服务重启、生产验证。Use when 沛哥要求发布生产、部署代码、上线新功能、或执行发布 SOP。

Security Scan

The skill appears to be a deployment helper but contains hardcoded production root credentials, undeclared dependencies, and a truncated/possibly non-working script — these inconsistencies are risky and require manual review before use.

Purpose & Capability

The declared purpose (one-click production deploy) matches the actions (SSH, backup, copy files, run migrations). However the skill embeds production root credentials (IP, username, plaintext password) directly in SKILL.md and in scripts/deploy.py instead of using declared/managed secrets. It also imports paramiko but the package/dependency is not declared. Embedding a production root password in files is disproportionate and poor practice even if deployment legitimately needs access.

Instruction Scope

Runtime instructions and scripts instruct the agent to connect as root to a specific IP, run pg_dump, upload site files, run migrations, and restart services — all expected for deployment. But the docs/scripts include explicit credentials and reference many local paths under /home/administrator/.openclaw/workspace-main (reading/writing backups and memory files). The SKILL.md and scripts contain the credentials in plaintext and direct writes to workspace memory; this broad access and exposure of secrets is a scope risk. Also the deploy.py shown is truncated at the end and likely syntactically broken, so the claimed 'one-click' capability may be non-functional.

Install Mechanism

There is no install spec. The included script imports paramiko (and expects npm/pm2/tools) but the skill declares no required binaries or dependencies. That mismatch (code needing libraries that are not declared or installed) is incoherent and will cause runtime failures or require the agent to install additional packages without explicit instructions.

Credentials

The skill declares no required environment variables or primary credential, yet both SKILL.md and scripts embed a production SSH password and other sensitive server details. This is disproportionate: either the skill should declare and require a secret (and not store it in repo files), or it shouldn't contain production credentials at all. The presence of a plaintext root password in multiple files is a serious secret-exposure issue.

Persistence & Privilege

always:false (OK). The skill writes release notes to workspace/memory and performs operations on the host it has credentials for; that behavior is expected for a deployer. However, because the skill contains embedded production credentials and the platform allows autonomous invocation by default, the blast radius is higher — an agent or skill bug could use those credentials unexpectedly. The script does not attempt to modify other skills or global agent config.

What to consider before installing

Do not run or install this skill in a production environment as-is. Specific actions to take before considering use: - Treat the exposed IP/username/password in SKILL.md and scripts as compromised: rotate the SSH password/keys on the server immediately if these files were shared or uploaded. - Do not supply production credentials directly in skill files; replace hardcoded credentials with secrets managed by a vault or environment variables and document required env vars in the skill manifest. - Verify and fix the deploy.py file — it appears truncated/malformed (the __main__ block is incomplete) and paramiko is used but not declared as a dependency. - Review the code line-by-line to ensure it does only the intended deployment actions (no hidden network calls or exfiltration). Run in a staging environment first. - Prefer SSH key auth, least-privilege accounts (not root), and an audited CI/CD pipeline instead of running one-click scripts from an agent with embedded credentials. - If you cannot verify the origin of this skill (source/homepage unknown), avoid granting it access to production credentials or allowing autonomous invocation until a trusted audit is completed.

生产环境发布部署技能

快速开始

触发场景：

• "发布到生产"
• "部署代码"
• "上线新功能"
• "执行发布流程"

核心流程（10 步）：

1. 本地测试 → 2. DB 结构对比 → 3. 前端构建 → 4. 回归测试 → 5. 备份生产 → 6. 部署代码 → 7. 执行迁移 → 8. 重启服务 → 9. 生产验证 → 10. 记录发布

服务器配置

生产服务器：157.245.56.178
用户名：root
密码：7758258Liu
端口：22
部署路径：/var/www/sm-dating-website/
前端构建：/home/administrator/.openclaw/workspace-main/projects/sm-dating-website/frontend/dist
后端路径：/home/administrator/.openclaw/workspace-main/projects/sm-dating-website/backend

发布前检查清单

执行发布前必须确认：

• 本地测试通过（npm test / pytest）
• 数据库结构对比无冲突（scripts/db_diff_check.py）
• 前端构建成功（npm run build）
• 回归测试通过率 >90%
• 已通知相关人员（如需要）

一键发布

使用自动化脚本执行完整发布流程：

cd /home/administrator/.openclaw/workspace-main
python3 skills/prod-deploy/scripts/deploy.py

脚本自动执行：

1. 连接生产服务器
2. 备份当前代码和数据库
3. 上传前端构建文件
4. 上传后端代码
5. 执行数据库迁移（knex migrate:latest）
6. 重启 PM2 服务
7. 验证服务健康状态
8. 输出发布报告

分步执行

1. 数据库备份

ssh root@157.245.56.178 "pg_dump smdating > /tmp/smdating_backup_$(date +%Y%m%d_%H%M%S).dump"

2. 数据库结构对比

python3 scripts/db_diff_check.py

3. 前端构建

cd projects/sm-dating-website/frontend
npm run build

4. 部署前端

python3 scripts/deploy_frontend.py

5. 部署后端

# 使用 SCP 上传后端代码
scp -r projects/sm-dating-website/backend/* root@157.245.56.178:/var/www/sm-dating-website/backend/

6. 执行数据库迁移

ssh root@157.245.56.178 "cd /var/www/sm-dating-website/backend && npm run migrate"

7. 重启服务

ssh root@157.245.56.178 "pm2 restart all"

8. 生产验证

python3 scripts/check_prod_frontend.py
curl -I https://zmq-club.com
curl https://zmq-club.com/api/health

回滚流程

如果发布失败，立即执行回滚：

# 1. 恢复数据库
ssh root@157.245.56.178 "pg_restore -d smdating /tmp/smdating_backup_YYYYMMDD_HHMMSS.dump"

# 2. 恢复代码（从 Git）
ssh root@157.245.56.178 "cd /var/www/sm-dating-website && git reset --hard HEAD~1"

# 3. 重启服务
ssh root@157.245.56.178 "pm2 restart all"

相关脚本

• scripts/deploy.py - 一键发布主脚本（本技能）
• scripts/deploy_frontend.py - 前端部署（项目脚本）
• scripts/db_diff_check.py - 数据库结构对比
• scripts/check_prod_frontend.py - 生产环境检查
• backend/knexfile.js - Knex 迁移配置

参考文档

• references/RELEASE-SOP.md - 完整发布 SOP
• references/QUICK-REFERENCE.md - 快速参考

注意事项

⚠️ 发布窗口： 避免在高峰期（20:00-23:00）发布 ⚠️ 备份优先： 任何操作前先备份 ⚠️ 迁移顺序： 先执行 DB 迁移，再重启服务 ⚠️ 验证必须： 发布后必须执行健康检查 ⚠️ 记录发布： 在 memory/YYYY-MM-DD.md 中记录发布内容和时间

常见问题

Q: 数据库迁移失败？ A: 检查 knexfile.js 配置，确认生产数据库连接正常，查看 migrations 文件是否有语法错误。

Q: 前端构建失败？ A: 检查 node_modules 是否完整，尝试 npm ci 重新安装依赖。

Q: PM2 服务启动失败？ A: 查看 pm2 logs 输出，检查 .env 配置文件是否正确，确认端口未被占用。

Q: 回滚后数据丢失？ A: 确认备份文件完整，使用 pg_restore --list 查看备份内容再恢复。