У чэрвені нашы згенераваныя застасункі працавалі ў асяроддзях папярэдняга прагляду. Я мог разглядаць экран, пакуль канвеер яго мяняў. Падчас распрацоўкі гэта было карысна. Але пускаць кліентаў у тое ж асяроддзе я не стаў бы.
Мы ўзяліся аддзяліць вытворчую версію ад гэтага цыкла рэдагавання і наладзіць перадачу праектаў у GitHub.
У першапачатковай нататцы да рэлізу частку гэтага я апісаў занадта ўпэўнена. Гэтая рэдакцыя аддзяляе задуму ад таго, што мы можам праверыць на 15 кастрычніка 2026 г. Рэалізацыя і дакументацыя ўключаюць шляхі для разгортвання і для GitHub. Але гэта само па сабе не пацвярджае кожнае выкатванне на жывую сістэму, змену дамена ці адкат.
Мяжа вытворчага асяроддзя
Папярэдні прагляд перазбіраецца, пакуль ты працуеш. Паводле задумы паміж гэтым зменлівым асяроддзем і застасункам, якім карыстаюцца людзі, стаіць свядомы выпуск. Вытворчае разгортванне павінна аддаваць менавіта тую версію, якую выбраў ты.
Вытворчы хост задуманы так, каб працаваць з загадзя сабранымі артэфактамі і без інструментаў рэдагавання з папярэдняга прагляду. Налады і ўліковыя даныя вытворчай версіі маюць уласную вобласць дзеяння. Канчатковым карыстальнікам застасунку таксама патрэбныя свае налады ідэнтыфікацыі, асобныя ад уліковых запісаў, якімі карысталіся падчас распрацоўкі.
Тое, што налада захоўваецца асобна, яшчэ не даказвае, што кожны шлях выканання кода апрацоўвае яе правільна. Перш чым адпраўляць кліенту спасылку, правер вытворчыя значэнні, дазволеныя адрасы перанакіравання і правілы доступу.
Агледзь застасунак у папярэднім праглядзе, у тым ліку дазволы і станы без даных. Наладзь вытворчае асяроддзе, апублікуй, дачакайся гатоўнасці і запусці важныя працоўныя працэсы на разгорнутым застасунку.
Цяперашняе кіраўніцтва па публікацыі апісвае гэтыя крокі і тое, як праверыць, ці хапае месца ў тваім плане. Лічы паспяховую аперацыю ў інтэрфейсе адным з крокаў выпуску, а потым тэстуй сэрвіс, які атрымаўся.
Дамен
Працоўны працэс для дамена звязвае імя хоста застасунку з даменам, які ты кантралюеш. Табе патрэбныя адпаведныя запісы DNS, і падключэнне трэба пацвердзіць.
Першапачатковы артыкул зводзіў гэта да схемы «дадаў CNAME — і ўсё працуе». Так з тэксту выпалі чаканне і праверкі, якіх патрабуе змена дамена.
Карыстайся значэннямі, паказанымі для разгортвання. Калі змены DNS стануць бачнымі, правер імя хоста, сертыфікат і сам застасунак. Яшчэ раз правер перанакіраванні пры ўваходзе на публічным адрасе. Пра апошняе працоўны адрас папярэдняга прагляду кажа мала.
Для наладжвання дамена мы маем рэалізаваныя шляхі. Гэтая перапрацоўка тэксту — не справаздача пра свежы тэст DNS ці TLS на жывой сістэме.
Перадача ў GitHub
Я хачу, каб праект заставаўся карысным і па-за сеансам, у якім яго стварылі. Рэпазіторый дае зменам у зыходным кодзе месца, дзе іх можна правяраць і падтрымліваць.
Інтэграцыя з GitHub прадугледжвае, як падключыць уліковы запіс, апублікаваць зыходны код і абменьвацца зменамі з падключаным рэпазіторыем. Потым ты можаш вывучаць код праекта і дакументы да яго ў звыклых інструментах.
Публікацыя зыходнага кода ў GitHub і публікацыя застасунку, які працуе, — розныя аперацыі. Рэпазіторый не абслугоўвае базу даных, не наладжвае твае сакрэты і не рэагуе на інцыдэнты ў вытворчым асяроддзі.
Гісторыю мы задумалі так: адна асноўная галіна, звычайны push, а змены адмяняюцца новымі revert-камітамі. Мы стараемся не прапаноўваць force-push як звычайнае дзеянне платформы.
Так наш уласны працоўны працэс мае менш спосабаў перапісаць гісторыю. Але гэта не дае падстаў абяцаць, што карыстальнік ніколі не страціць код. Дазволы ў рэпазіторыі, знешнія праўкі і працэдуры аднаўлення па-ранейшаму маюць значэнне.
На кастрычнік частка функцый прагляду гісторыі і адкату яшчэ не прайшла свежых праверак у эксплуатацыі. Трымай уласны план аднаўлення. Не мяркуй па кнопцы ці шляху ў рэалізацыі, што аднаўленне пратэставанае.
Уліковыя даныя і налады
Паводле задумы інтэграцыя захоўвае зашыфраваныя ўліковыя даныя GitHub асобна для кожнага праекта, па-за дыскам праекта застасунку. Каб падключэнне працавала, застасунак не павінен патрабаваць персанальнага токена доступу ў дрэве зыходнага кода.
Такое рашэнне пра захоўванне не азначае, што ўсё разгортванне прайшло аўдыт бяспекі.
Каб перанесці праект у іншае месца, мала спампаваць зыходны код. Ты мусіш даць яму канфігурацыю асяроддзя выканання, сэрвісы даных і налады ідэнтыфікацыі, якіх чакае яго код. Перш чым выбраць варыянт хостынгу, вывучы гэтыя залежнасці.
Дакументацыя пра Git і GitHub тлумачыць працоўны працэс з зыходным кодам. А артыкул пра ідэнтыфікацыю — чаму ўваход толькі частка межаў доступу застасунку.
Праца над выпускам
Для эксплуатацыйных абяцанняў мне па-ранейшаму патрэбныя доказы: завершанае выкатванне, дамен, які працуе, аднаўленне, якое праверылі на рэальным сэрвісе. Праверка кода такіх доказаў не дасць.
Чэрвеньская праца дала нам шляхі для гэтых задач. Запісваць праверкі, якіх яны яшчэ патрабуюць, менш прыемна, чым абвяшчаць праблему вырашанай. Затое гэта карысней, пакуль першы кліент яшчэ не залежыць ад сістэмы.
Упершыню апублікавана 16 чэрвеня 2026 г. Перагледжана 15 кастрычніка 2026 г.: выпраўленыя катэгарычныя сцверджанні пра разгортванне і аднаўленне, а рэалізаваныя шляхі аддзеленыя ад праверкі на жывой сістэме.