SprintFlint 现在在 Railway 上运行。 Rails Web 应用程序、后台工作人员、公共 MCP 服务、PostgreSQL、Redis、私有上传和每日备份位于一个 Railway 项目中，生产资源位于阿姆斯特丹。
我们于 10 月 1 日完成了应用程序切换，并于 10 月 2 日完成了剩余的存储、部署和退役检查。团队继续使用 sprintflint.com 以及相同的帐户、工单和集成。公共 MCP 端点保持在 mcp.sprintflint.com.
目标是更清晰地操作应用程序：将其服务、数据、文件存储、发布配置和恢复过程结合在一起。以下是移动的内容、我们检查的内容以及这对产品意味着什么。
一个项目，不同的工作
SprintFlint 已经从同一 Rails 代码库运行其 Web 应用程序和 MCP 服务器。我们保持了这种形状，并为每个职责提供了自己的 Railway 服务：
| 组件 | Railway 上的角色 |
|---|---|
| 网络 | 为 sprintflint.com 上的应用程序提供服务 |
| 工人 | 运行 Sidekiq 后台作业 |
| MCP | 为经过身份验证的公共 MCP 端点提供服务 |
| PostgreSQL | 持有账户、组织、项目、冲刺和工单 |
| 雷迪斯 | 支持后台作业和实时连接 |
| 对象存储 | 保存私有上传和单独的备份存储桶 |
| 备份 | 运行每日备份过程 |
将工作线程和 MCP 服务分开意味着每个服务都有一个明确的启动命令和一个我们可以检查的版本。他们共享应用程序的数据和配置。数据库迁移从 Web 服务的预部署步骤运行一次，因此工作线程和 MCP 服务不会同时尝试相同的迁移。
Cloudflare 继续处理域名注册、DNS 和现有的电子邮件相关记录。我们更新了应用程序主机名以指向 Railway 并检查了它们的 TLS 证书和 www 重定向。现有的电子邮件传送和错误报告集成（包括 Postmark 和 Sentry）仍然是 SprintFlint 的一部分。
成功的导入需要的不仅仅是正在运行的服务器
PostgreSQL 迁移从最终的 Heroku 备份开始。恢复后，我们将每个应用程序表的行计数和行指纹与源进行比较。指纹检查有助于确认内容以及总数是否匹配。
Redis 需要一种不同的方法。源的序列化 DUMP 格式无法恢复到我们的目标 Redis 版本中。我们改为传输逻辑值，然后检查键类型、值、列表顺序、排序集分数和绝对到期时间。这种区别很重要：Redis 连接可以是健康的，而它应该保留的队列或缓存状态是不完整的。
我们还保留了现有的应用程序签名秘密和加密凭证密钥。在验证过程中，经过身份验证的浏览器会话在 Railway 重新部署后仍保持登录状态，并且真实的 Google 登录信息已到达现有帐户。原始 API 和 MCP 身份验证令牌继续有效。
对于团队来说，有用的结果是连续性：他们现有的工作空间和工单历史记录与基础设施一起出现。
上传内容从 R2 移至私有 Railway 存储
数据库只是工单应用程序状态的一部分。屏幕截图和附件也需要在迁移后保留下来。
我们将上传对象从 Cloudflare R2 复制到私有 Railway 对象存储中，并检查每个复制文件的 SHA-256 校验和。开发、登台和测试也获得了自己单独的存储配置。 Rails 测试继续使用内存上传存储。
该应用程序保留其现有的上传集成，并更改了 Railway 的存储端点和凭据。我们通过签名的上传 URL、CORS 预检以及读回上传的文件来验证浏览器流程。检查运行时图像处理和 MIME 检测是否安装了所需的依赖项。
在停用 R2 之前，我们还检查了存储的数据库值以查找对旧 Cloudflare 存储 URL 的引用。验证传输和恢复副本后，源对象和 SprintFlint R2 存储桶将被删除。
每日备份，并进行完成检查
计划备份服务运行于 每天 03:00 世界标准时间。它将三种存档写入单独的私有 Railway 存储桶：
- PostgreSQL 自定义格式转储。
- Redis 密钥有效负载及其过期时间。
- 上传文件的 ZIP，包括原始对象密钥、内容类型、元数据和校验和。
每个存档都会从存储中读回，并根据其 SHA-256 校验和进行检查。只有在每个存档通过后，作业才会写入完成清单。这为我们提供了一种区分已完成快照和部分上传尝试的具体方法。
每日快照有 30 天保留。成功的新备份后会进行过期清理，失败的备份会退出并在服务日志中显示错误。最终迁移恢复快照与每日到期策略分开保存。
我们验证了手动和计划运行是否成功。我们还将 PostgreSQL 备份恢复到临时验证数据库中并检查了其表。读回存档并测试数据库恢复可以回答不同的问题；两者都是这一举措的一部分。
我们也检查了发布路径
Web、worker、MCP 和备份服务现在遵循存储库的 master 分支并等待 GitHub 检查后再自动部署。
这里有一个有用的设置课程。连接存储库源足以构建版本，但直到部署 Railway 帐户也链接到 GitHub 后，我们的自动部署触发器才变得可用。我们检查了实际的触发器和 CI 设置，然后通过连接的帐户进行合并，并观察了所有四种服务从等待检查到成功发布的进展情况。
我们保留了项目的发布批准保障措施。来自未链接到项目的自动化帐户的版本需要审核和批准。通过 GitHub 检查并查看最终的 Railway 部署是否成功是我们发布过程中的单独检查。
结束迁移的实时检查
在宣布迁移完成之前，我们验证了人们和集成实际使用的路径：
- 公共网站、经过身份验证的仪表板和 Google 登录。
- 数据库和 Redis 健康状况，以及真正无害的 Sidekiq 工作完成。
- 实时 WebSocket 连接和已确认的订阅。
- 经过身份验证的 MCP 初始化、工具发现和只读项目请求。
- 签名上传、浏览器 CORS 和文件读回。
- 实时应用程序的版本标识符与已部署的 GitHub 版本匹配。
- 备份存档校验和和临时 PostgreSQL 恢复。
经过这些检查后，我们淘汰了旧的 Heroku 应用程序及其数据库和 Redis 附加组件。 SprintFlint 的旧 R2 铲斗也已退役。 Cloudflare 的域名、DNS 和电子邮件设置保持不变。
该产品仍然为团队提供了相同的地方来计划冲刺、管理工单和跟踪进度。底层的变化是一种更加连贯的操作设置：一个项目中的命名服务、从经过审查的提交到正在运行的版本的经过验证的路线、经过校验和验证的备份存档以及经过测试的 PostgreSQL 恢复。