Той самий код, інша версія Node.js
Ви повторно збираєте той самий код і бачите Node.js 26.7.0 замість 26.6.0. Спочатку перевірте, яка версія потрапила до готового результату збірки — артефакту. Не робіть висновку, що хтось змінив код або налаштування.
Офіційні сторінки Node.js підтверджують, що 26.6.0 і 26.7.0 вийшли з інтервалом у два дні. Вони не доводять, що конкретний CI або контейнер оновився автоматично. Таку зміну може спричинити лише налаштування чи інструмент, який знову вибрав версію без точної фіксації.
Перевіряйте систему від найпростішого до складнішого: фактичну версію на кожному етапі, джерело вибору, новий артефакт і лише потім обмежене розгортання з готовим відкатом.
1. Перевірте фактичну версію
Почніть із локального середовища:
node --version
Додайте ту саму перевірку до CI — системи, яка автоматично збирає та тестує код. Виконуйте її після налаштування Node.js і перед основною збіркою.
Для довіреного контейнерного образу, у якому node доступний через PATH, можна перевірити версію без запуску звичайної команди застосунку:
docker run --rm --entrypoint node <image> --version
Якщо образ має іншу структуру, використайте задокументований для нього спосіб. Не підставляйте неперевірений сторонній образ.
У виробничому середовищі (production) перевіряйте саме розгорнутий застосунок: дозволеною діагностичною командою всередині його контейнера або записом версії під час запуску. Окремий діагностичний контейнер може мати інший Node.js і нічого не доводити про застосунок.
Збережіть разом результат node --version, ідентифікатор збірки, ідентифікатор коміту та digest образу, якщо використовуєте контейнери. Так ви порівнюватимете конкретні артефакти, а не лише код.
2. Знайдіть джерело вибору версії
Перевірте .nvmrc, .node-version, поле engines у package.json, конфігурацію CI та кожну інструкцію FROM у Dockerfile.
Поле engines зазвичай описує сумісні версії. Воно не гарантує встановлення конкретного Node.js, якщо інструмент встановлення не використовує це поле саме для вибору версії.
Шукайте посилання без точної версії, або «плаваючі» посилання: наприклад, 26, node:26 чи широкий діапазон. Їхня поведінка залежить від інструмента. До оновлення джерела таке посилання могло вибирати 26.6.0, а після оновлення — 26.7.0.
Кеш базового образу або завантаження інструмента може тимчасово приховувати різницю. Після промаху кешу, його очищення чи повторного отримання образу неточне посилання обчислюється знову.
Не перевіряйте лише один файл. Локальне середовище, CI та контейнер можуть мати незалежні правила вибору Node.js.
3. Задайте точну версію та перевірте артефакт
У файлі менеджера версій і конфігурації CI задайте точний випуск Node.js. Для контейнера версійний тег робить намір явним, але тег сам по собі не ідентифікує незмінний вміст. Якщо потрібна сувора повторюваність, зафіксуйте базовий образ за digest.
Оновлюйте ці значення окремою видимою зміною. Створіть новий артефакт, повторіть node --version і звірте digest із реєстром або метаданими розгортання.
Після модульних тестів виконайте короткі перевірки запуску та основних дій — smoke-тести. Перевірте запуск, стан сервісу й один ключовий сценарій. За потреби окремо перевірте базу даних, чергу, зовнішні API та пакети з компонентами, скомпільованими для конкретної платформи.
4. Починайте з малого й підготуйте відкат
Якщо платформа підтримує пробне розгортання, спрямуйте на новий артефакт малу частину трафіку або невелику групу екземплярів. Заздалегідь визначте умови зупинки: допустимі межі помилок, перезапусків, часу відповіді та збоїв критичної операції.
Збережіть попередній незмінний артефакт і перевірте, що платформа може знову його розгорнути. Повторна збірка старого коміту не є надійним відкатом: неточне посилання може знову вибрати новішу версію Node.js.
Якщо розгортання також змінює дані чи конфігурацію, окремо перевірте їхню сумісність із попереднім артефактом.
Де допоможе ШІ
Передайте ШІ лише очищені від секретів фрагменти Dockerfile, конфігурації CI, файлів версій і журналу конкретної збірки. Попросіть відокремити підтверджені джерела версії від припущень і назвати докази, яких бракує.
ШІ не бачить фактичний образ у реєстрі, стан кешу чи production без наданих даних. Перевіряйте його висновки через node --version, digest у реєстрі або метаданих розгортання та журнал саме тієї збірки. Не передавайте секрети, повні змінні середовища чи внутрішні адреси.
Що запам’ятати
Сам факт появи Node.js 26.7.0 не робить перехід обов’язковим. Спочатку встановіть фактичну версію, зробіть її вибір явним, перевірте новий артефакт і лише потім розгортайте його з підготовленим відкатом.
Джерела
Короткий чеклист
- виконати node --version у кожному середовищі
- знайти всі файли, налаштування й образи, що задають версію Node.js
- задати точну версію Node.js, а для контейнера за потреби зафіксувати digest
- створити новий артефакт і виконати короткі перевірки запуску та основних дій
- визначити умови зупинки пробного розгортання й перевірити відкат попереднього артефакту
Знайти джерело неочікуваної зміни Node.js
Допоможи з’ясувати, звідки цей проєкт отримує версію Node.js і чи може вона змінитися без правки коду. Вхідні дані: - очікувана версія Node.js: [версія] - результати node --version для локального середовища, CI, контейнера та виробничого середовища: [результати] - очищені від секретів фрагменти Dockerfile, конфігурації CI, .nvmrc, .node-version і package.json: [фрагменти] - digest базового та готового образів із реєстру або метаданих розгортання: [дані] - рядки журналу конкретної збірки про базовий образ, кеш і встановлення Node.js: [рядки] Не проси токени, паролі, внутрішні адреси, повні журнали чи повні змінні середовища. Не вважай припущення доведеними. Не вигадуй команди для невідомої платформи. Поверни результат у такому форматі: 1. Підтверджені джерела версії з назвою файла, параметром або рядком журналу. 2. Можливі посилання без точної версії, чітко позначені як припущення. 3. Перевірки фактичної версії та digest. Для кожної команди вкажи, де її виконувати, її передумови й можливі побічні ефекти. 4. Послідовність дій: зафіксувати версію, створити новий артефакт, виконати короткі перевірки, провести пробне розгортання та перевірити відкат. 5. Дані, яких бракує для висновку.