Zamknięcie Deno Deploy: co trzeba sprawdzić przed migracją

Zamknięcie Deno Deploy stawia startup przed dwiema decyzjami: gdzie uruchamiać aplikację i kto będzie utrzymywać jej środowisko wykonawcze. Deno zapowiedziało jeszcze sześć miesięcy działania Deploy oraz rok comiesięcznych wydań środowiska wykonawczego z poprawkami błędów i zabezpieczeń. Te dwa okresy określa komunikat Deno z 9 października. Zanim przeniesiesz ruch produkcyjny, sprawdź, czy nowe rozwiązanie zachowuje działanie, na którym polegają klienci.

Działająca strona główna na Workers to dobry pierwszy wynik. Nie dowodzi jednak, że sesja pozostaje prywatna, równoczesne zapisy dają poprawny rezultat ani że można wycofać nieudane przełączenie. To właśnie te testy powinny rozstrzygać, czy aplikacja jest gotowa do migracji.

Ten zestaw kryteriów odbioru jest przeznaczony dla osób kierujących zespołami rozwijającymi aplikacje, które już zależą od Deno. Poniższe przykłady to propozycje testów. Nie są wynikami migracji klientów ani obietnicą, że każda aplikacja może przejść tę samą drogę.

Który termin Deno dotyczy twojej aplikacji?

Termin zamknięcia hostingu dotyczy Deno Deploy, a termin zakończenia utrzymania dotyczy środowiska wykonawczego Deno. Zanim zaplanujesz prace, ustal, od czego faktycznie zależy aplikacja działająca na produkcji.

W komunikacie z 9 października Deno informuje, że cały zespół dołącza do Cloudflare. Deploy będzie działać przez sześć miesięcy, a potem zostanie zamknięte. Środowisko wykonawcze będzie przez kolejny rok otrzymywać comiesięczne poprawki błędów i zabezpieczeń. Później zespół zakończy jego rozwój; kod pozostanie otwarty. JSR będzie nadal działać, a jego infrastruktura przeniesie się do Cloudflare. Klientom korzystającym z płatnych usług i przechodzącym na Workers zaoferowano pomoc w migracji.

Te deklaracje nie określają dokładnej daty i godziny zamknięcia, umownego zakresu pomocy dla danego klienta ani zespołu, który później przejmie utrzymanie środowiska wykonawczego. Potwierdź te szczegóły bezpośrednio u dostawcy, planując przełączenie.

Aplikacja może używać środowiska wykonawczego bez Deploy. Pipeline budowania uruchamiający deno task zależy od Deno inaczej niż API obsługujące żądania na Deploy. Inny dostawca może też korzystać ze środowiska zgodnego z Deno: tak Supabase opisuje swoje Edge Functions, wraz z własną bramą i integracjami platformy. Nie oznacza to, że Supabase jest klientem Deploy ani że obowiązuje go termin zamknięcia Deploy.

Dla każdej ścieżki obsługi żądania produkcyjnego zapisz, jaki host je obsługuje i w jakim środowisku wykonuje kod. Następnie ustal, czy od Deploy zależą też dane lub zaplanowane zadania. To krótka analiza zależności konkretnej aplikacji. Sam plik konfiguracyjny Deno w repozytorium nie daje odpowiedzi.

Również dokumentacja może sugerować niewłaściwy termin. Dotychczasowy przewodnik migracji Deno opisuje przejście z Deploy Classic do Deno Deploy. Nie prowadzi na Workers. Opis Deploy nadal zawiera historyczną informację o zamknięciu Classic. Obie strony dotyczą wcześniejszej zmiany, a nie pełnej instrukcji migracji po komunikacie z października 2026 roku.

Jeśli dotyczą cię oba terminy, zakończ odbiór nowego hostingu przed zamknięciem dotychczasowego. Osobno podejmij decyzję o utrzymaniu środowiska wykonawczego, także gdy plik wykonywalny Deno zostanie w procesie budowania lub zadaniach wewnętrznych po przeniesieniu publicznej usługi.

Wybierz rozwiązanie, które zachowa potrzebne działanie

Właściwe rozwiązanie przejdzie testy odbioru aplikacji i będzie możliwe do utrzymania przez twój zespół. Komunikat o przejęciu nie rozstrzyga tego wyboru.

Poniższa tabela pomaga wybrać, co sprawdzić najpierw. Jej wymagania są zaleceniami inżynierskimi. Zobowiązania dostawców pozostają takie, jak w ich komunikatach.

Komunikat Cloudflare opisuje przyszłe prace nad połączeniem celld i workerd oraz wsparciem samodzielnego hostingu. Wskazuje też obecne ograniczenie implementacji Durable Objects w workerd do jednej instancji i braki w narzędziach wokół niej. Te ograniczenia wyznaczają zakres wniosków, które można wyciągnąć z zapowiedzianego kierunku.

Zespół rozważający własną infrastrukturę musi osobno ustalić, kto będzie odpowiadać za jej działanie. Omawiamy to w artykule o obsadzie i odpowiedzialności przy samodzielnym hostingu. Tutaj najpierw trzeba sprawdzić, czy wybrane rozwiązanie przejdzie testy aplikacji.

Sprawdź wykonanie kodu, uwierzytelnianie i zadania w tle

Test migracji musi uruchomić zachowanie, które może zawieść w nowym środowisku. Udana kompilacja i zgodne kody odpowiedzi HTTP to tylko część dowodów.

Zacznij od niewielkiego zestawu testowego w środowisku staging, który wyśle te same reprezentatywne żądania do obecnej aplikacji i jej proponowanego zamiennika. Użyj syntetycznych rekordów i osobnych danych uwierzytelniających. Ustal stan początkowy, żeby porównania miały sens. Zapisz też celowe różnice, takie jak nazwa hosta czy generowane identyfikatory.

Dokumentacja zgodności Deno z Node i npm dotyczy uruchamiania aplikacji Node w Deno. Nie dowodzi, że kod używający API Deno zadziała bez zmian gdzie indziej. Z kolei dokumentacja zgodności Workers z Node.js rozróżnia zaimplementowane API, częściowe wsparcie i atrapy bez działającej implementacji. Import może się udać, a późniejsze wywołanie zakończyć błędem.

Uwzględnij wprost rzadko uruchamiany kod: eksport raportów, przetwarzanie załączników, callback uwierzytelniania czy zadanie odczytujące system plików lub uruchamiające podproces. Sprawdzaj tylko funkcje używane przez aplikację. Wykonaj rzeczywistą operację zależności, zamiast sprawdzać jedynie, czy ładuje się moduł. W dokumentacji testu zapisz konfigurację docelową i datę zgodności, żeby wynik można było odtworzyć w tym samym środowisku.

Dla HTTP porównaj treść odpowiedzi, nagłówki, przekierowania i ciasteczka, jeśli należą do uzgodnionego zachowania. Uwzględnij błędne dane wejściowe, wygasłe sesje i żądania bez uprawnień.

W usłudze izolującej dane kont utwórz dwa syntetyczne konta z podobnymi rekordami i spróbuj uzyskać dostęp do danych drugiego konta. Test musi zakończyć się niepowodzeniem, jeśli odpowiedź zawiera oczekiwany rekord, ale ujawnia też dane innego konta.

Jeśli aplikacja planuje zadania lub umieszcza je w kolejce, sprawdź je osobno. Na przykład przyjmij żądanie, przerwij proces roboczy przed zakończeniem i ponów dostarczenie zadania. Sprawdź stan końcowy oraz efekt zewnętrzny, korzystając z odbiorcy testowego zamiast skrzynki prawdziwego klienta. Upewnij się też, że osoba reagująca na awarię zobaczy błąd. Poprawna odpowiedź na żądanie nie dowodzi, że późniejsze zadanie się wykonało.

Zapisuj wyniki tak, żeby inny inżynier mógł je zakwestionować: stan początkowy, działanie, wynik oczekiwany, wynik zaobserwowany i odpowiedni ślad wykonania. Jeśli aplikacja nie ma danej funkcji, oznacz kryterium jako „nie dotyczy” i podaj powód. Kilka testów powiązanych z rzeczywistymi awariami daje więcej dowodów niż ogromna checklista z niewyjaśnionymi zielonymi znacznikami.

Deno KV i Workers KV wymagają różnych testów odbioru

Podobne nazwy magazynów danych nie oznaczają takich samych transakcji ani odczytów. Jeśli poprawność stanu zależy od Deno KV, opisz tę zależność przed wyborem zamiennika.

Dokumentacja transakcji Deno KV opisuje optymistyczne sterowanie współbieżnością. Odczyty zwracają znaczniki wersji (versionstamps). Operacja atomowa może wraz ze zmianami sprawdzić pary klucz–znacznik wersji. Zatwierdzenie powiedzie się tylko wtedy, gdy sprawdzane wersje nadal się zgadzają. Aplikacje używające tych kontroli muszą obsłużyć konflikt i zdecydować, czy ponowić próbę.

Dokumentacja Workers KV opisuje magazyn o spójności ostatecznej: zmiany mogą pojawić się w innych lokalizacjach po 60 sekundach lub później. Ostrzega przed zakładaniem natychmiastowej widoczności, nawet w miejscu zapisu. Wskazuje też, że KV nie jest idealnym rozwiązaniem dla operacji atomowych ani transakcyjnych odczytów i zapisów. Czytelników potrzebujących silniejszych gwarancji spójności kieruje do Durable Objects.

To konkretna granica zgodności, a nie ocena całej platformy Workers. Cache i ograniczenie unikalności mogą wymagać różnych magazynów danych nawet w jednej aplikacji. Wybór innego komponentu danych Cloudflare też wymaga testów jego rzeczywistych gwarancji i twojej implementacji. Sama nazwa nie zapewnia brakującego zachowania.

Załóżmy, że aplikacja Deno sprawdza, czy klucz zaproszenia nie istnieje, a następnie atomowo tworzy zaproszenie i rekord służący do jego wyszukania. Prosta przeróbka z odczytem i osobnymi zapisami może przejść wszystkie testy sekwencyjne.

Zamiast tego wyślij dwa równoczesne żądania dla tego samego zaproszenia. Oczekiwanym rezultatem może być jedno przyjęte zaproszenie, jeden konflikt i spójny rekord wyszukiwania. Określ wynik na podstawie obecnych zasad działania, zanim napiszesz zamiennik.

Drugi scenariusz sprawdza widoczność zmian. Utwórz syntetyczny rekord uprawnień, odbierz uprawnienie i natychmiast spróbuj wykonać chronioną operację z innej lokalizacji geograficznej. Określ, czy odebranie uprawnienia musi działać od razu, czy produkt dopuszcza opóźnienie. O wyniku odbioru decyduje spełnienie tego wymagania bezpieczeństwa, a nie samo udane wywołanie API magazynu danych.

Żeby sprawdzić wygasanie, utwórz rekord o krótkim czasie ważności i sprawdź dostęp tuż przed jego końcem i po nim. Uwzględnij sytuację, w której cache zapamiętał brak rekordu, jeśli ważna jest jego widoczność po utworzeniu. Przy uporządkowanych listach odtwórz wystarczająco dużo syntetycznych kluczy, żeby sprawdzić założenia aplikacji dotyczące paginacji i kolejności.

Jeśli znaczniki wersji służą jako kursory lub metadane aplikacji, ustal, jak te odwołania będą działać po konwersji. Nie zastępuj ich bez uzgodnienia znacznikami czasu z nowego środowiska.

Wykryj pozornie pozytywne wyniki przed przełączeniem

Pozornie pozytywny wynik oznacza, że test przeszedł, choć ominął warunek, który miał sprawdzić. Projekt testów wymaga równie uważnego review jak kod nowego rozwiązania.

Lokalny emulator może sprawdzić logikę bez sprawdzania rozproszenia systemu produkcyjnego. Żądania z jednej maszyny mogą nie ujawnić problemu z widocznością w innej lokalizacji. Żądania sekwencyjne nie potwierdzą bezpieczeństwa przy równoczesnym wykonaniu. Pusta baza nie ujawni błędu konwersji starych rekordów. Dodaj konkretny brakujący warunek, zamiast wielokrotnie uruchamiać ten sam powierzchowny test.

Szukaj też błędów, które kod przechwytuje i ukrywa. Błąd zależności może zostać zamieniony na pusty wynik. Endpoint zwraca 200, ale w eksporcie brakuje wierszy. Sprawdź zawartość wyniku i oczekiwane zachowanie po błędzie. W testach ponawiania licz końcowe efekty, nie tylko przyjęte żądania.

Ostrożnie odtwarzaj ruch produkcyjny. Oczyszczone żądania kieruj do odizolowanych danych, a odbiorców e-maili, płatności i webhooków zastąp odbiorcami testowymi. Powtórzenie produkcyjnego zapisu może wywołać drugi efekt zewnętrzny. Z góry ustal, które porównania można wykonać bez zapisu, a które wymagają kontrolowanego scenariusza na staging.

Odbiór obejmuje też obsługę awarii. Wywołaj rozpoznawalny błąd na staging i poproś kogoś o diagnozę przy użyciu logów oraz alertów nowego środowiska. Sprawdź, czy dane uwierzytelniające należą do właściwego środowiska i czy instrukcja przywracania działa dla osoby, która ma reagować. Nawet poprawnie działającą aplikację trudno przywrócić pod presją, jeśli nie ma dostępu do śladów awarii.

Sprawdź rollback po zapisach i uzgodnieniu danych

Rollback jest zakończony dopiero wtedy, gdy stara aplikacja może wznowić pracę z poprawnym stanem. Przekierowanie ruchu z powrotem nie usuwa zapisów przyjętych przez nowe środowisko.

Deno opisuje kopie zapasowe KV w magazynie zgodnym z S3 kontrolowanym przez klienta i korzystanie z nich przez narzędzie denokv. To możliwość eksportu i odzyskiwania danych, którą warto sprawdzić. Nie konwertuje jednak automatycznie danych do Workers KV, D1 ani innego magazynu.

Odtwórz reprezentatywną kopię w izolacji. Porównaj istotne rekordy, wygasanie i relacje, nie tylko liczbę obiektów. Zapisz, do którego momentu sięga kopia, i ustal, jakie zapisy przyjęto później. Czytelna kopia z brakującymi ostatnimi transakcjami nie wystarczy do planowanego rollbacku.

Następnie przećwicz awarię po przyjęciu nowych zapisów przez testowane rozwiązanie. Wstrzymaj dalsze zapisy lub zapewnij nad nimi inną kontrolę. Zbierz przyjęte zmiany i uzgodnij je z systemem, który ponownie stanie się źródłem prawidłowego stanu.

Określ obsługę duplikatów, sprzecznych zmian, usunięć i przerwanych zadań. Użyj identyfikatorów aplikacji i jawnych reguł uzgadniania. „Skopiuj wszystko z powrotem” nie odpowiada na te pytania.

W małej usłudze zaplanowana przerwa w zapisach może uprościć zadanie. Usługa, która nie może ich wstrzymać, potrzebuje przetestowanego przechwytywania zmian lub replikacji. Równoczesny zapis do dwóch systemów dodaje własne scenariusze awarii: jeden zapis może się udać, a drugi zawieść. Przećwicz ten przypadek, zanim uznasz podwójny zapis za zabezpieczenie odzyskiwania.

Przy podejmowaniu decyzji o przełączeniu określ też granicę prostego rollbacku. Przed pierwszymi zapisami w nowym środowisku przekierowanie ruchu z powrotem może być łatwe. Później wymaga procedury uzgadniania danych i dowodów, że działa. Jeśli zespół nie umie przywrócić poprawnego stanu w ramach przyjętych wymagań odzyskiwania, aplikacja nie jest gotowa do przełączenia.

Skorzystaj z Kit, jeśli migracja ujawni brak kompetencji w zespole

Rekrutuj dopiero wtedy, gdy testy odbioru pokażą konkretną lukę w kompetencjach inżynierskich. Sam termin zamknięcia usługi nie dowodzi, że startup potrzebuje pracownika na stałe.

Może brakować kogoś do jednorazowej konwersji bazy, doświadczenia ze zgodnością środowisk wykonawczych albo osoby odpowiedzialnej za stałe utrzymanie. Najpierw określ potrzebny rezultat i czas współpracy.

Krótkie zadanie podczas rozmowy może polegać na wyjaśnieniu nieudanego zapisu warunkowego, zbadaniu zgodności faktycznie wykonywanego kodu albo omówieniu rollbacku po utworzeniu jednego nowego rekordu. Użyj syntetycznych danych i ogranicz czas zadania. Za pracę przy migracji produkcyjnej trzeba zapłacić.

Dowody z migracji i decyzje o przełączeniu przechowuj w narzędziach zespołu inżynierskiego. Kit pomaga w procesie rekrutacji, jeśli zdecydujesz się ją rozpocząć: pozwala zarządzać kandydaturami i oceną zespołu. Nie migruje środowiska wykonawczego ani nie uzgadnia danych w bazie.

Teraz potrzebujesz zamiennika, który przed zamknięciem hostingu przejdzie testy działania, stanu i odzyskiwania. Jeśli testy pokażą, że potrzebujesz nowej osoby w zespole, zobacz Kit Hiring jako narzędzie do obsługi tej rekrutacji.