У червні наші згенеровані застосунки працювали в середовищах попереднього перегляду. Я міг роздивлятися екран, поки конвеєр його змінював. Під час розробки це було корисно. Але пускати клієнтів у те саме середовище я б не став.
Ми взялися відокремити виробниче середовище від цього циклу редагування й налагодити передачу проєктів через GitHub.
У першій примітці до релізу я описав дещо з цього надто впевнено. Ця редакція відділяє задум від того, що ми можемо перевірити станом на 15 жовтня 2026 року. У реалізації та документації є шляхи для розгортання й роботи з GitHub. Самі по собі вони ще не підтверджують кожне реальне викочування, зміну домену чи відкат.
Межа виробничого середовища
Попередній перегляд перезбирається, поки ти працюєш. Задум передбачає свідомий реліз між цим мінливим середовищем і застосунком, яким користуються люди. Розгортання у виробничому середовищі має віддавати ту версію, яку ти вибереш.
Хост виробничого середовища задуманий так, щоб працювати із заздалегідь зібраними артефактами, без інструментів редагування з попереднього перегляду. Конфігурація й облікові дані виробничого середовища мають власну область дії. Кінцевим користувачам застосунку теж потрібна своя конфігурація ідентифікації, окрема від облікових записів, якими користувалися під час розробки.
Те, що налаштування зберігається окремо, ще не доводить, що код скрізь правильно його обробляє. Перш ніж надсилати клієнтові посилання, перевір значення для виробничого середовища, дозволені перенаправлення й правила доступу.
Оглянь застосунок у попередньому перегляді, зокрема дозволи й стани без даних. Налаштуй виробниче середовище, опублікуй, дочекайся статусу готовності й прожени важливі робочі процеси на розгорнутому застосунку.
Актуальний посібник із публікації описує ці кроки й перевірку того, чи вистачає на це можливостей твого плану. Успішну операцію в інтерфейсі вважай одним із кроків релізу, а потім протестуй отриманий сервіс.
Домен
Процес підключення домену повʼязує імʼя хоста застосунку з доменом, яким ти керуєш. Тобі знадобляться відповідні DNS-записи, а підключення доведеться підтвердити.
Перша версія статті зводила все до одного запису CNAME, після якого все працює. За дужками лишилися очікування й перевірки, без яких зміна домену не обходиться.
Використовуй значення, показані для розгортання. Коли зміни DNS стануть видимими, перевір імʼя хоста, сертифікат і сам застосунок. На публічній адресі ще раз протестуй перенаправлення під час входу. Робоча URL-адреса попереднього перегляду мало що скаже тобі про цю останню частину.
У коді є шляхи для налаштування домену. Проте в цій переписаній версії немає результатів свіжої перевірки DNS чи TLS наживо.
Передача через GitHub
Я хочу, щоб проєкт лишався корисним і поза сесією, яка його створила. Репозиторій дає змінам у вихідному коді місце, де їх можна рецензувати й підтримувати.
В інтеграції з GitHub є шляхи, якими можна підключити обліковий запис, опублікувати код і обмінюватися змінами з підключеним репозиторієм. Після цього код проєкту та супровідні документи можна переглядати у звичних інструментах.
Публікація коду на GitHub і публікація робочого застосунку — різні операції. Репозиторій не обслуговує базу даних, не налаштовує твої секрети й не реагує на інцидент у виробничому середовищі.
Історію задумано так: одна основна гілка, звичайні пуші, а щоб скасувати зміни, поверх додають коміти revert. Ми намагаємося не пропонувати force-push як звичайну дію платформи.
Так меншає способів, якими наш власний робочий процес переписує історію. Але це не дає підстав обіцяти, що користувач ніколи не втратить код. Дозволи в репозиторії, зовнішні правки й процедури відновлення все одно мають значення.
Станом на жовтень частині функцій перегляду історії й відкату ще бракує свіжих експлуатаційних перевірок. Подбай про власний план відновлення. Не вважай відновлення протестованим лише тому, що є кнопка чи шлях у реалізації.
Облікові дані й конфігурація
За задумом інтеграція зберігає зашифровані облікові дані GitHub окремо для кожного проєкту, поза диском проєкту застосунку. Щоб підключення працювало, застосункові не повинен знадобитися персональний токен доступу в дереві вихідного коду.
Таке рішення щодо зберігання ще не означає, що все розгортання пройшло аудит безпеки.
Щоб перенести проєкт деінде, мало просто завантажити вихідний код. Тобі доведеться забезпечити конфігурацію середовища виконання, сервіси даних і налаштування ідентифікації, на які розраховує його код. Перш ніж вибирати, де і як хостити проєкт, перевір ці залежності.
Документація про Git і GitHub пояснює, як працювати з вихідним кодом. А чому вхід — лише частина межі доступу застосунку, розповідає стаття про ідентифікацію.
Робота над релізом
Для експлуатаційних обіцянок мені все ще потрібні докази: завершене викочування, робочий домен, відновлення, перевірене на справжньому сервісі. Ревʼю коду таких доказів не дасть.
Червнева робота дала нам шляхи для цих завдань. Записати перевірки, яких вони ще потребують, не так приємно, як оголосити проблему розвʼязаною. Зате корисніше, поки від цього ще не залежить перший клієнт.
Уперше опубліковано 16 червня 2026 року. Переглянуто 15 жовтня 2026 року, щоб виправити категоричні твердження про розгортання й відновлення та відрізнити реалізовані шляхи від перевірки наживо.