Node.js 24.19.0 чи 26.6.0: як вибрати версію для свого сервісу

Одна гілка для одного сервісу

Зміна одного рядка у Dockerfile здається простою, доки не виявиться, що локальне середовище, CI і контейнер у production використовують різні версії Node.js. Тоді тести можуть пройти не на тій версії, яка обслуговуватиме реальні запити.

Спершу визначте дозволену гілку сервісу. Для 24.x ціль у цьому сценарії — Node.js 24.19.0; для сервісу, уже затвердженого на 26.x, — 26.6.0. Не переходьте з основної версії 24 на 26 в межах цього оновлення: це окрема міграція з власною перевіркою сумісності.

Не потрібно вчити напам’ять обидва списки змін. Простежте версію одного сервісу від репозиторію та CI до зібраного образу й запущеного екземпляра.

Офіційні сторінки позначають 24.19.0 як LTS — випуск із довгостроковою підтримкою, а 26.6.0 як Current — випуск поточної гілки. Ці позначки не роблять версії взаємозамінними: вибір має відповідати затвердженій гілці конкретного сервісу.

Перевірте, яку версію використовує сервіс

Почніть із зібраного образу: запустіть у ньому node --version. У production використовуйте лише схвалений командою спосіб діагностики запущеного екземпляра. Далі перевірте:

• рядок FROM у Dockerfile;
• налаштування Node.js у системі CI;
• поле engines у package.json;
• файли .nvmrc, .node-version та конфігурацію менеджера версій;
• базові образи й шаблони розгортання.

Поле engines може описувати підтримуваний діапазон, але саме по собі не вибирає точну версію Node.js. Файл із зафіксованими версіями пакетів теж не фіксує Node.js. Тому перевірте інструмент, який фактично встановлює або вибирає Node.js у кожному середовищі. Якщо оновити тільки Dockerfile, а CI залишити на старій версії, розбіжність збережеться.

Перетворіть примітки до релізу на перевірки

Читайте офіційну сторінку цільового релізу у своїй гілці. Для 24.19.0 і 26.6.0 це окремі сторінки, тому не переносьте запис з однієї гілки до плану іншої. Якщо оновлення пропускає попередні випуски в межах гілки, перевірте також офіційні примітки до цих випусків.

Для кожного релевантного запису визначте перевірку з чітким результатом: чи запускається процес, чи встановлюються залежності, чи проходить коротка перевірка основної функції сервісу та чи коректно завершується процес.

Якщо застосунок має нативний модуль, установіть або зберіть його в цільовому образі відповідно до документації цього модуля та перевірте завантаження. Не вважайте сам збіг номера гілки доказом сумісності.

Зафіксуйте версію перед складанням

Фіксація версії має охоплювати Dockerfile, CI та локальні файли, які команда справді використовує. Не замінюйте ціль на latest або широкий тег лише тому, що так коротше. Якщо система вимагає відтворюваних образів, використовуйте також незмінний ідентифікатор образу відповідно до її правил.

Зберіть новий артефакт і знову виконайте node --version. Це перевіряє результат складання, а не лише запис у конфігурації. Після цього виконайте визначені перевірки запуску, залежностей, основної функції та завершення процесу.

Перевірте малу частину трафіку

Почніть канаркове розгортання з одного екземпляра або малої частки трафіку. Порівнюйте його з базовим рівнем — звичайними показниками поточної версії — за зіставного навантаження й тривалості спостереження. Перевіряйте частоту помилок, затримку відповідей, споживання пам’яті та кількість перезапусків.

Продовжуйте розгортання, якщо перевірки запуску, завершення роботи й основної функції успішні, а показники залишаються в заздалегідь погоджених межах. Виконайте відкат, якщо бачите повторювані збої, цикл перезапусків або стале погіршення важливої метрики.

Універсальної безпечної частки трафіку чи порога для метрик немає: їх визначають за звичайною поведінкою конкретного сервісу. Попередній образ, конфігурація та перевірений спосіб відкату мають бути готові до початку канаркового розгортання.

Де доречна допомога ШІ

Інструменту ШІ можна надати публічні примітки до релізу, цільову гілку, знеособлений список залежностей, потрібних під час виконання, і перелік доступних тестів. Попросіть підготувати чернетку списку «зміна — можливий ризик — тест» та окремо позначити припущення.

Не передавайте ключі, приватні журнали, внутрішні адреси або дані клієнтів. Модель не бачить реальний трафік, приховані залежності чи параметри складання. Кожен висновок перевіряйте за офіційними примітками та власними тестами на зібраному образі.

Коли оновлення завершене

Після успішного розгортання знову перевірте версії в CI, образі та запущеному екземплярі. Зафіксуйте результат node --version, посилання на реліз, перевірені метрики та версію для відкату.

Оновлення завершене, коли в усіх активних конфігураціях указано цільову версію, а запущений екземпляр фактично її використовує.

Джерела

• https://nodejs.org/en/blog/release/v24.19.0
• https://nodejs.org/en/blog/release/v26.6.0