W czerwcu nasze generowane aplikacje działały w środowiskach podglądu. Mogłem oglądać ekran, kiedy pipeline go zmieniał. W trakcie prac było to przydatne. Klientów nie wpuściłbym jednak do tego samego środowiska.
Postanowiliśmy oddzielić produkcję od tej pętli edycji i dać projektom możliwość przekazania na GitHuba.
W pierwotnej notce o wydaniu opisałem część tych zmian zbyt pewnie. Ta wersja oddziela założenia projektowe od tego, co możemy zweryfikować 15 października 2026 r. Implementacja i dokumentacja obejmują ścieżki wdrażania i integracji z GitHubem. Samo to nie oznacza jednak, że sprawdziliśmy każde wdrożenie na żywo, zmianę domeny czy wycofanie zmian.
Granica produkcji
Podgląd przebudowuje się na bieżąco, kiedy pracujesz. Z założenia między tym zmiennym środowiskiem a aplikacją, z której korzystają ludzie, stoi świadome wydanie. Wdrożenie produkcyjne powinno serwować wersję wybraną przez Ciebie.
Host produkcyjny ma z założenia korzystać z wcześniej zbudowanych artefaktów, bez narzędzi edycji z podglądu. Konfiguracja produkcyjna i dane uwierzytelniające mają własny zakres. Użytkownicy końcowi aplikacji też potrzebują własnej konfiguracji tożsamości, oddzielonej od kont używanych przy programowaniu.
To, że ustawienie jest przechowywane osobno, nie dowodzi, że każda ścieżka w kodzie obsługuje je poprawnie. Zanim wyślesz klientowi link, sprawdź wartości produkcyjne, dozwolone przekierowania i reguły dostępu.
Przejrzyj podgląd, łącznie z uprawnieniami i stanami bez danych. Skonfiguruj środowisko produkcyjne, opublikuj aplikację, poczekaj na jej gotowość i przejdź najważniejsze procesy na wdrożonej wersji.
Aktualny poradnik publikacji opisuje te kroki i to, jak sprawdzić, czy Twój plan ma jeszcze wolne miejsce. Udaną operację w interfejsie traktuj jako jeden z kroków wydania, a potem przetestuj usługę, która z niego powstała.
Domena
Proces konfiguracji domeny łączy nazwę hosta aplikacji z domeną, którą zarządzasz. Potrzebujesz odpowiednich rekordów DNS i musisz zweryfikować połączenie.
Pierwotny artykuł sprowadzał to do dodania rekordu CNAME, po którym wszystko działa. Pomijał czekanie i sprawdzanie, których wymaga zmiana domeny.
Trzymaj się wartości wyświetlonych dla wdrożenia. Kiedy domena zacznie się rozwiązywać, sprawdź nazwę hosta, certyfikat i aplikację. Pod adresem publicznym jeszcze raz przetestuj przekierowania logowania. Działający adres podglądu niewiele Ci o tym powie.
Mamy zaimplementowane ścieżki konfiguracji domeny. Ten przepisany tekst nie dokumentuje jednak świeżego testu DNS ani TLS na żywym środowisku.
Przekazanie na GitHuba
Chcę, żeby projekt dało się sensownie rozwijać poza sesją, w której powstał. Repozytorium daje zmianom w kodzie miejsce, w którym można je przeglądać i utrzymywać.
Integracja z GitHubem ma ścieżki, którymi można podłączyć konto, opublikować kod i wymieniać zmiany z podłączonym repozytorium. Kod projektu i dokumenty pomocnicze możesz wtedy przeglądać w znajomych narzędziach.
Publikacja kodu na GitHubie i publikacja działającej aplikacji to osobne operacje. Repozytorium nie prowadzi bazy danych, nie konfiguruje Twoich sekretów i nie reaguje na incydent na produkcji.
Historia z założenia opiera się na jednej głównej gałęzi, zwykłych pushach i cofaniu zmian nowymi commitami typu revert. Unikamy udostępniania force-pusha jako zwykłej akcji na platformie.
Ogranicza to sytuacje, w których nasz własny proces przepisuje historię. Nie uzasadnia jednak obietnicy, że użytkownik nigdy nie straci kodu. Uprawnienia do repozytorium, zmiany wprowadzane z zewnątrz i procedury odtwarzania nadal się liczą.
W październiku niektóre elementy przeglądania historii i wycofywania zmian wciąż czekają na świeże kontrole operacyjne. Miej własny plan odtwarzania. Nie zakładaj, że przywracanie jest przetestowane, tylko dlatego, że widzisz przycisk albo ścieżkę w implementacji.
Dane uwierzytelniające i konfiguracja
Integracja z założenia przechowuje zaszyfrowane dane uwierzytelniające GitHuba osobno dla każdego projektu, poza dyskiem projektu aplikacji. Aplikacja nie powinna potrzebować osobistego tokenu dostępu w drzewie źródeł, żeby połączenie działało.
Sam sposób przechowywania nie dowodzi, że całe wdrożenie przeszło audyt bezpieczeństwa.
Żeby przenieść projekt gdzie indziej, nie wystarczy pobrać kodu. Musisz zapewnić konfigurację środowiska uruchomieniowego, usługi danych i ustawienia tożsamości, których oczekuje jego kod. Sprawdź te zależności, zanim wybierzesz sposób hostingu.
Dokumentacja o Gicie i GitHubie objaśnia pracę z kodem źródłowym. Artykuł o tożsamości wyjaśnia, dlaczego logowanie to tylko część granicy dostępu aplikacji.
Praca nad wydaniem
Na obietnice operacyjne wciąż potrzebuję dowodów: zakończonego wdrożenia, działającej domeny, odtwarzania przećwiczonego na prawdziwej usłudze. Przegląd kodu takich dowodów nie dostarczy.
Czerwcowa praca dała nam ścieżki do tych zadań. Spisanie kontroli, których jeszcze wymagają, daje mniej satysfakcji niż ogłoszenie, że problem jest rozwiązany. Za to bardziej się przydaje, zanim pierwszy klient zacznie na tym polegać.
Pierwsza publikacja: 16 czerwca 2026 r. Poprawiono 15 października 2026 r., żeby skorygować bezwarunkowe twierdzenia o wdrażaniu i odtwarzaniu oraz oddzielić zaimplementowane ścieżki od weryfikacji na żywo.