Šodien, 20. jūlijā, Deno izslēdz Deploy Classic — veco mitināšanas platformu adresē dash.deno.com — un līdzi tai arī subhosting v1 API adresē apidocs.deno.com. Projekti, kas šorīt vēl darbojas Classic, dienas laikā apstājas. Neviens no tiem nepārceļas uz jauno platformu pats no sevis.
Deno komanda migrācijas ceļvedī to formulē tieši: Classic projekti adresē dash.deno.com netiek automātiski pārcelti. Kurš gribēja saglabāt savu izvietojumu, tam bija jāizveido jauna organizācija un jauna lietotne adresē console.deno.com, no jauna jāpieslēdz GitHub repozitorijs un ar roku jāievada katrs vides mainīgais. Migrācija tātad nozīmē manuālu iestatīšanu katram projektam atsevišķi.
deployctl aiziet, vietā stājas deno deploy
Kopā ar Classic pazūd arī deployctl — komandrindas rīks, ko daudzi bija ielikuši savos CI/CD konveijeros. To aizstāj apakškomanda deno deploy, iebūvēta tieši Deno izpildvidē. Praksē tas nozīmē, ka katrs GitHub Actions vai citas automatizācijas solis, kas izsauca deployctl deploy, pēc šodienas neatradīs šo rīku un izgāzīsies.
Jaunā platforma pēc noklusējuma sagaida, ka būvēšana notiek tās pašas vidē, nevis tavā mašīnā ar augšupielādi pēc tam. Tas maina veidu, kā tiek uzstādīti vides mainīgie: vienas globālas kopas vietā tagad ir trīs atsevišķas — produkcijai, izstrādei un būvēšanai.
Kas salūzt kodā
Daļa problēmu ir klusas, un tieši tas padara tās nepatīkamas. Ja tavs serveris joprojām izmanto veco serve() funkciju no deno.land/std, jaunajā platformā tā vairs nestrādā — izvietojums neizdodas klusi, jau iesildīšanās brīdī, bez skaidra paziņojuma. Risinājums ir pāriet uz Deno.serve().
Skarbāks trieciens skar rindas. Deno rindas — Deno.Kv.enqueue() un Deno.Kv.listenQueue() — jaunajā Deno Deploy vienkārši nav atbalstītas, un aizvietotāja Deno ekosistēmā nav. Kurš uz tām balstīja fona uzdevumus, tam jāpāriet uz ārēju servisu, piemēram, Upstash QStash, Redis kopā ar BullMQ vai AWS SQS.
KV datubāzes jaunajā platformā pastāv, taču arī tās nepārceļas pašas. Deno dokumentācija norāda vienkāršu, bet nepatīkami manuālu ceļu:
Sazinieties ar support@deno.com, lai saņemtu palīdzību KV datubāzes migrācijā.
Vienīgais, kas paliek nemainīgs, ir cron uzdevumi — tie strādā tāpat kā agrāk, bez izmaiņām kodā.
Divi reģioni sešu vietā
Vēl viena atšķirība, ko pamanīs lietotāji ārpus Eiropas un ASV. Classic darbojās no sešiem reģioniem, jaunā platforma pašlaik strādā no diviem — ASV un Eiropas. Āzijas un Klusā okeāna reģiona lietotājiem tas nozīmē lielāku aizkavi, kamēr Deno paplašinās pārklājumu. Papildu reģionus var pievienot pašmitinot, taču noklusējuma platformā to nav.
Migrācijas gaitā ne viss noris gludi. GitHub izsekošanas sistēmā Deno lietotāji ir atklājuši vairākas problēmas — no pazudušām funkcijām līdz neparedzētam atmiņas patēriņam. Pašu domēnu pārnešana prasa trīs soļus: pievienot domēnu jaunajā panelī, iestatīt _acme-challenge CNAME ierakstu un atjaunināt DNS, atstājot līdz 48 stundām izplatīšanai, pirms domēnu noņem no Classic.
Ko dod jaunā platforma
Migrācijai ir arī ieguvumi. Jaunā Deno Deploy atbalsta pilnu Deno 2.0 saskarni, tostarp FFI, apakšprocesus un rakstīšanu failu sistēmā — lietas, kuru Classic izolētajā vidē nebija. Uzlabota ir arī npm savietojamība, iebūvēts OpenTelemetry telemetrijai un OIDC balstīti mākoņa savienojumi.
Tomēr laika ziņā pāreja bija saspringta. Deno 2.9, kas iznāca 25. jūnijā, ienesa pirmo klases migrāciju no npm, pnpm, yarn un Bun, taču pati Deploy migrācija ar KV un rindām paliek roku darbs. Komandām, kuras šodien no rīta vēl neko nebija pārcēlušas, projekti jau ir bezsaistē, un atjaunošana prasīs to pašu manuālo iestatīšanu, tikai steigā.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.