SprintFlint działa teraz na Railway. Aplikacja internetowa Rails, proces działający w tle, publiczna usługa MCP, PostgreSQL, Redis, prywatne przesyłanie i codzienne kopie zapasowe są dostępne w jednym projekcie Railway z zasobami produkcyjnymi w Amsterdamie.
Zakończyliśmy przenoszenie aplikacji 1 października, a pozostałe kontrole przechowywania, wdrażania i wycofywania – 2 października. Zespoły nadal korzystają sprintflint.com i te same konta, zadania i integracje. Publiczny punkt końcowy MCP pozostaje w lokalizacji mcp.sprintflint.com.
Celem było bardziej przejrzyste miejsce do obsługi aplikacji: jej usług, danych, przechowywania plików, konfiguracji wersji i procesu odzyskiwania. Oto, co zostało przeniesione, co sprawdziliśmy i co to oznacza dla produktu.
Jeden projekt, osobne zadania
SprintFlint uruchomił już swoją aplikację internetową i serwer MCP z tej samej bazy kodu Rails. Zachowaliśmy ten kształt i każdemu z osobna przypisaliśmy własną usługę Railway:
| Komponent | Rola w Railway |
|---|---|
| Sieć | Obsługuje aplikację na sprintflint.com |
| Pracownik | Uruchamia zadania w tle Sidekiq |
| MCP | Obsługuje uwierzytelniony publiczny punkt końcowy MCP |
| PostgreSQL | Przechowuje konta, organizacje, projekty, sprinty i zadania |
| Redisa | Obsługuje zadania w tle i połączenia w czasie rzeczywistym |
| Przechowywanie obiektów | Przechowuje prywatne przesłane pliki i oddzielny zasobnik kopii zapasowych |
| Kopie zapasowe | Uruchamia proces codziennego tworzenia kopii zapasowych |
Oddzielenie procesu roboczego i usługi MCP oznacza, że każdy z nich ma jawną komendę startu i wersję, którą możemy sprawdzić. Udostępniają dane i konfigurację aplikacji. Migracje baz danych są uruchamiane jednorazowo, począwszy od etapu przed wdrożeniem usługi internetowej, więc proces roboczy i usługa MCP nie podejmują jednocześnie prób tej samej migracji.
Cloudflare w dalszym ciągu obsługuje rejestrację domen, DNS i istniejącą dokumentację związaną z pocztą elektroniczną. Zaktualizowaliśmy nazwy hostów aplikacji, aby wskazywały Railway i sprawdziliśmy ich certyfikaty TLS oraz www przekierować. Istniejące integracje dostarczania wiadomości e-mail i raportowania błędów, w tym Postmark i Sentry, pozostają częścią SprintFlint.
Pomyślny import wymagał czegoś więcej niż tylko działającego serwera
Przenoszenie PostgreSQL rozpoczęło się od ostatecznej kopii zapasowej Heroku. Po przywróceniu porównaliśmy liczbę wierszy każdej tabeli aplikacji i ich odciski palców ze źródłem. Sprawdzenie odcisków palców pomogło potwierdzić zgodność zawartości i sumę.
Redis potrzebował innego podejścia. Nie udało się przywrócić serializowanego formatu DUMP źródła do docelowej wersji Redis. Zamiast tego przenieśliśmy wartości logiczne, a następnie sprawdziliśmy typy kluczy, wartości, kolejność na liście, posortowane wyniki i bezwzględne czasy wygaśnięcia. To rozróżnienie miało znaczenie: połączenie Redis może działać prawidłowo, podczas gdy kolejka lub stan pamięci podręcznej, który miał zachować, jest niekompletny.
Zachowaliśmy także tajność istniejącego podpisywania aplikacji i zaszyfrowany klucz poświadczeń. Podczas weryfikacji uwierzytelniona sesja przeglądarki pozostała zalogowana po ponownym wdrożeniu Railway, a do istniejącego konta dotarł prawdziwy login Google. Oryginalne tokeny uwierzytelniające API i MCP nadal działały.
Dla zespołów użytecznym rezultatem jest ciągłość: ich istniejący obszar roboczy i historia zgłoszeń zetknęły się z infrastrukturą.
Przesyłane pliki zostały przeniesione z R2 do prywatnej pamięci Railway
Baza danych jest tylko częścią stanu aplikacji biletowej. Zrzuty ekranu i załączniki również muszą przetrwać przeprowadzkę.
Skopiowaliśmy przesłane obiekty z Cloudflare R2 do prywatnej pamięci obiektowej Railway i sprawdziliśmy sumę kontrolną SHA-256 każdego skopiowanego pliku. Rozwój, przemieszczanie i testowanie również otrzymały własną, oddzielną konfigurację pamięci. Testy Railsów w dalszym ciągu wykorzystują pamięć do przesyłania w pamięci.
Aplikacja zachowuje istniejącą integrację przesyłania, a punkt końcowy magazynu i dane uwierzytelniające zostały zmienione dla Railway. Sprawdziliśmy przepływ przeglądarki poprzez podpisany adres URL przesyłania, wstępną inspekcję CORS i ponowne odczytanie przesłanego pliku. Sprawdzono przetwarzanie obrazu w czasie wykonywania i wykrywanie MIME z zainstalowanymi wymaganymi zależnościami.
Przed wycofaniem wersji R2 sprawdziliśmy także przechowywane wartości bazy danych pod kątem odniesień do starych adresów URL pamięci Cloudflare. Obiekty źródłowe i zasobniki SprintFlint R2 zostały usunięte po zweryfikowaniu transferów i kopii odzyskiwania.
Codzienne kopie zapasowe z kontrolą ukończenia
Zaplanowana usługa tworzenia kopii zapasowych działa o godz 03:00 UTC każdego dnia. Zapisuje trzy rodzaje archiwów w oddzielnym prywatnym zasobniku Railway:
- Zrzut w niestandardowym formacie PostgreSQL.
- Kluczowe ładunki Redis wraz z czasami wygaśnięcia.
- ZIP przesłanych plików, w tym oryginalne klucze obiektów, typy treści, metadane i sumy kontrolne.
Każde archiwum jest odczytywane z pamięci i sprawdzane pod kątem sumy kontrolnej SHA-256. Dopiero po przejściu każdego archiwum zadanie zapisuje manifest ukończenia. Dzięki temu możemy w konkretny sposób odróżnić ukończoną migawkę od próby przesłania częściowo.
Codzienne migawki mają 30-dniowe przechowywanie. Czyszczenie po wygaśnięciu następuje po pomyślnym utworzeniu nowej kopii zapasowej, a kopia zapasowa, która się nie powiodła, kończy działanie z błędem widocznym w dziennikach usług. Ostateczna migawka odzyskiwania po migracji jest przechowywana oddzielnie od zasad dziennego wygaśnięcia.
Sprawdziliśmy pomyślne uruchomienia ręczne i zaplanowane. Przywróciliśmy także kopię zapasową PostgreSQL do tymczasowej bazy danych weryfikacyjnych i sprawdziliśmy jej tabele. Odczytywanie archiwum i testowanie przywracania bazy danych odpowiada na różne pytania; obaj byli częścią tego posunięcia.
Sprawdziliśmy także ścieżkę wydania
Usługi internetowe, robocze, MCP i kopie zapasowe są teraz zgodne z repozytorium master gałęzi i poczekaj na sprawdzenie GitHub przed automatycznym wdrożeniem.
Tutaj była przydatna lekcja konfiguracji. Podłączenie źródła repozytorium wystarczyło do zbudowania wydania, ale nasze wyzwalacze automatycznego wdrażania nie stały się użyteczne, dopóki konto wdrażające Railway nie zostało połączone z GitHub. Sprawdziliśmy rzeczywiste wyzwalacze i ustawienia CI, a następnie połączyliśmy je za pośrednictwem połączonego konta i obserwowaliśmy postęp wszystkich czterech usług od oczekiwania na sprawdzenie do pomyślnego wydania.
Zachowaliśmy zabezpieczenia zatwierdzania wydania projektu. Zwolnienia z konta usługi Automation, które nie jest połączone z projektem, wymagają przeglądu i zatwierdzenia. Przejście kontroli GitHub i pomyślne wdrożenie Railway to oddzielne kontrole w naszym procesie wydawania wersji.
Kontrole na żywo, które zakończyły migrację
Zanim zakończyliśmy przeprowadzkę, zweryfikowaliśmy ścieżki, z których faktycznie korzystają ludzie i integracje:
- Witryna publiczna, uwierzytelniony pulpit nawigacyjny i logowanie Google.
- Kondycja bazy danych i Redis oraz faktyczne ukończenie nieszkodliwego zadania Sidekiq.
- Aktywne połączenie WebSocket i potwierdzona subskrypcja.
- Uwierzytelniona inicjalizacja MCP, wykrywanie narzędzi i żądanie projektu tylko do odczytu.
- Podpisane przesyłanie, CORS przeglądarki i odczyt plików.
- Identyfikator wersji aktywnej aplikacji zgodny z wdrożoną wersją GitHub.
- Sumy kontrolne archiwum kopii zapasowych i tymczasowe przywracanie PostgreSQL.
Po tych kontrolach wycofaliśmy stare aplikacje Heroku wraz z bazami danych i dodatkami Redis. Stare łyżki R2 SprintFlint również zostały wycofane. Ustawienia domeny, DNS i poczty e-mail Cloudflare pozostają niezmienione.
Produkt nadal zapewnia zespołom to samo miejsce do planowania sprintów, zarządzania zgłoszeniami i śledzenia postępów. Zmiana poniżej to bardziej spójna konfiguracja operacyjna: nazwane usługi w jednym projekcie, zweryfikowana trasa od sprawdzonego zatwierdzenia do działającej wersji, archiwa kopii zapasowych zweryfikowane sumą kontrolną i przetestowane przywracanie PostgreSQL.