Деплой сайту: як викласти в інтернет без збоїв

Що таке деплой простими словами

Ти зробив сайт. На компі він працює ідеально: гарний, швидкий, усе клікається. Одна біда. Його не бачить жодна жива душа, крім тебе. Щоб сайт побачив світ, проєкт треба викласти в інтернет. Ось цей переїзд і називається деплой Деплой (deploy) - публікація проєкту на сервері в інтернеті, щоб ним могли користуватися справжні люди, а не тільки ти на своєму компі. .

Порівняй із переїздом у нову квартиру. Спосіб перший: виносиш зі старої взагалі всі меблі, потім пів дня тягаєш нові - і весь цей час тобі немає навіть де присісти. Спосіб другий: завозиш нові меблі, розставляєш, перевіряєш, що все стоїть рівно, і лише потім прибираєш старі. Жодної секунди без дивана.

Гарний деплой - це завжди другий спосіб. Користувач не повинен помітити, що ти взагалі щось чіпав. Сайт працював - і працює далі, просто став кращим.

Навіщо вайбкодеру розбиратися в публікації сайту

Ти вайбкодер. Код за тебе пише агент. Але кнопку «опублікувати» у фіналі натискаєш ти. І за впалий сайт відповідати теж тобі. Коли ти розумієш, як влаштований деплой, ти:

• викочуєш оновлення так, що відвідувачі нічого не помічають;
• не світиш свої паролі та ключі на весь інтернет (найчастіша й найдорожча помилка новачка);
• умієш відкотитися назад за секунди, а не пишеш агенту в паніці «поверни як було!!!»;
• розумієш, що ховається за страшними словами rollback, health check, staging - і можеш спокійно попросити агента все це налаштувати.

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

Чотири опори спокійного деплою

1. Як викочувати оновлення без падінь

Крихітний сайт на одному сервері? Тоді все просто: нова версія замінює стару, і привіт. Але варто проєкту підрости - і зʼявляються хитрі способи оновлюватися так, щоб сайт ні на секунду не ліг. Ось три головні, від простого до надійного.

• Rolling Rolling deployment - оновлення по черзі: сервери перемикаються на нову версію один за одним, а не всі разом. Сайт увесь час працює. (по черзі). У тебе кілька копій сайту. Оновлюєш їх не разом, а по одній: поки одна переїжджає на нову версію, решта тримають відвідувачів. Ніхто не залишається без сайту.
• Blue-green Blue-green deployment - два однакові майданчики: на одному працює стара версія, поруч готується нова. У потрібний момент трафік миттєво перемикають на нову. (два майданчики). Дві однакові копії: «синя» працює прямо зараз, «зелена» стоїть напоготові з новою версією. Перевірив зелену - клацнув рубильником, і весь трафік пішов туди. Щось не так? Клацнув назад - миттєвий відкат.
• Canary Canary deployment - нову версію спершу показують маленькій частині відвідувачів (наприклад 5%). Якщо в них усе добре - поступово відкривають решті. (канарка). Нову версію спершу бачать лише 5% відвідувачів. Їм добре - відкриваєш половині, потім усім. Назва - від шахтарських канарок: якщо щось не так, ти дізнаєшся про це на маленькій групі, а не на всіх одразу.

2. Де зберігати секрети: змінні оточення, не код

Це найважливіше правило уроку. У проєкту є секрети Секрети - паролі, ключі до баз даних, токени платіжних сервісів та інші дані, за якими можна зайти у твій проєкт. Їх не можна показувати нікому. : пароль від бази даних, ключ до платіжки, токен бота. Якщо вони написані прямо в коді, то варто коду поїхати в інтернет (а він поїде - наприклад, на GitHub), секрети поїдуть разом із ним і стануть видимі кому завгодно.

Правильно - зберігати їх у змінних оточення Змінні оточення (environment variables) - налаштування, які задаються окремо від коду, прямо на сервері. Код бере їх звідти, але в самому коді їх немає. . Це як ключі від квартири: вони не намальовані фарбою на дверях, а лежать у тебе в кишені. Код знає: «ключ десь є, візьму в потрібний момент» - але самого ключа в коді немає.

3. Health-check: службова сторінка «ти живий?»

Health-check Health-check - проста адреса на сайті (наприклад /health), яка відповідає «все ок». По ній сервер автоматично перевіряє, чи живий проєкт. - це крихітна службова сторінка, наприклад за адресою /health, яка просто відповідає «у мене все гаразд». Сам ти на неї ніколи не зайдеш. Вона для машин, не для людей.

А навіщо вона взагалі? Сервер раз на пів хвилини смикає цю сторінку і питає: «живий?». Відповідає «так» - чудово, ідемо далі. Мовчить або лається - сервер розуміє, що проєкт завис, і може сам його перезапустити чи перестати пускати на нього людей. Це як пульс у пацієнта: монітор пищить рівно - усі спокійні; сигнал зник - прибігла медсестра.

4. План відкату: кнопка «поверни як було»

Навіть у профі трапляється: викотив оновлення, а воно зламало сайт. Різниця між профі та новачком рівно одна: у профі є кнопка «назад». Це і є відкат Відкат (rollback) - швидке повернення до попередньої робочої версії проєкту, якщо нова виявилася зламаною. (rollback).

На нормальних майданчиках відкат - це буквально одна кнопка чи одна команда: «повернути попередню версію». Стара робоча збірка завжди лежить збереженою. Тому правильний хід думок під час деплою - не «аби злетіло», а «якщо не злетить - як я поверну все за 10 секунд?».

Гарний деплой проти поганого: порівняння

Staging Staging - тестова копія сайту, точна як бойова, але для користувачів закрита. На ній перевіряють оновлення перед публікацією. у цьому списку - окремий герой. Це копія твого сайту, на якій ти спершу все перевіряєш, і лише потім котиш на бойову. Дешево, нудно і рятує вагон нервів.

Приклад із життя: як витікає токен бота

Ти зробив агентом сайт-візитку з формою запису. Форма шле заявки тобі в Telegram через бота - для цього потрібен токен бота. Агент нашвидкуруч вписав токен прямо в код, ти зрадів, що все працює, і запушив проєкт на публічний GitHub. До вечора твій бот розсилає спам незнайомим людям, а сайт із кожним оновленням на пару хвилин втрачає форму, бо котиш ти прямо на бойову версію. Весело, так?

Що пішло не так:

1. Токен жив у коді і витік у відкритий репозиторій - боти підібрали його за хвилини.
2. Не було health-check і staging - оновлення перевірялися прямо на живому сайті.
3. Не було плану відкату - коли форма зламалася, повернути робочу версію не було чим.

А ось як зробив би тямущий вайбкодер. Просто грамотно поставив би задачу агенту.

Допоможи підготувати мій проєкт до публікації в інтернеті. Зроби крок за кроком:

Знайди в коді всі секрети - токени, паролі, ключі. Винеси їх у змінні оточення і створи файл-приклад env з порожніми значеннями. Переконайся, що справжні секрети НЕ потрапляють у репозиторій, додай їх у gitignore.
Додай простий health-check за адресою slash health, який відповідає статусом ок.
Поясни простими словами, як на моєму майданчику (я використовую Vercel) відкотитися на попередню версію, якщо нова зламається.
Перш ніж сказати, що все готово, пройдись по короткому чек-листу готовності до публікації і покажи мені його галочками.
Кожен крок показуй окремо і чекай на моє ок, перш ніж іти далі.

Чек-лист готовності до публікації: 60 секунд перед кнопкою

Перш ніж натиснути «опублікувати», пробіжи очима. Це спрощена версія професійного чек-листа зі скіла deployment-patterns:

1. Тести пройшли? Якщо агент робив тести - вони зелені?
2. Секретів у коді немає? Жодного пароля, ключа чи токена прямо у файлах.
3. Health-check відповідає? Зайди на /health - там «ок»?
4. Знаєш, як відкотитися? Не «розберуся, як що», а прямо зараз знаєш команду чи кнопку.
5. Перевірив на staging? Оновлення спершу пожило на тестовій копії, а не одразу на бойовій.
6. Час обрано з розумом? Не вечір пʼятниці й не за пʼять хвилин до важливої зустрічі.

Піксельна памʼятка

Часті помилки новачка під час деплою

• Зашити секрети в код. Вони витечуть разом із проєктом. Тільки змінні оточення, без винятків.
• Котити одразу на бойову. Спершу staging, потім світ. Інакше ти тестуєш на живих людях.
• Не мати плану відкату. «Якщо зламається - розберуся» - це не план. План - це кнопка «назад», яку ти знаєш заздалегідь.
• Ігнорувати health-check. Без нього про падіння ти дізнаєшся останнім - від злих користувачів.
• Деплоїти в пʼятницю ввечері. Стара інженерна мудрість: зламається рівно тоді, коли лагодити вже нікому.
• Міняти базу даних «назавжди» поспіхом. Видалив дані новою версією - відкат коду їх уже не поверне.