Lista kontrolna przekazania kodu źródłowego dla klientów i agencji

Co powinno osiągnąć przekazanie kodu źródłowego

Przekazanie kodu źródłowego to moment, w którym projekt przestaje być „coś, co agencja może uruchomić”, a staje się „coś, czym klient potrafi zarządzać”. Bez jasnego przekazania problemy pojawiają się szybko: aplikacja kompiluje się tylko na jednym laptopie, produkcja zależy od sekretu, którego nikt nie może znaleźć, albo mała poprawka zamienia się w dni zgadywania.

Celem każdej listy kontrolnej przekazania jest proste: po transferze klient potrafi zbudować, uruchomić i wdrożyć produkt bez konieczności stałej dostępności agencji. To nie znaczy „brak wsparcia nigdy”. Oznacza to, że podstawy są powtarzalne i udokumentowane, więc następna osoba może przejąć je z pewnością.

Zakres dostarczanych elementów powinien być jawny. Minimum dla kompletnego przekazania zazwyczaj obejmuje:

• Pełne repozytorium (w tym pliki wdrożeniowe i skrypty migracji)
• Dokumentację instalacji działającą na czystej maszynie
• Przekazanie dostępu (konta, uprawnienia i gdzie system jest hostowany)
• Runbook do rutynowych zadań (wdrożenia, rollback, kopie zapasowe, logi)
• Końcowy tag lub snapshot „znany-dobry”, do którego klient może się odwołać

Zakres jest równie ważny jak zawartość. Niektóre przekazania obejmują tylko jedno środowisko (np. produkcja). Inne obejmują dev, staging i produkcję z oddzielnymi ustawieniami i procesami. Jeśli nie nazwiesz, które środowiska są uwzględnione, ludzie założą różne rzeczy i tam powstają przestoje.

Praktyczny sposób zdefiniowania sukcesu to test weryfikacyjny: osoba, która nie budowała aplikacji, potrafi wyeksportować kod (na przykład z platformy takiej jak Koder.ai), podążyć za dokumentacją, ustawić zmienne środowiskowe, uruchomić migracje, zbudować i wdrożyć do uzgodnionego środowiska.

Ta checklista koncentruje się na gotowości technicznej: zmienne środowiskowe, rotacja sekretów, migracje bazy danych, skrypty wdrożeniowe i weryfikacja buildu. Nie obejmuje warunków prawnych, umów, klauzul IP ani sporów płatniczych. To też jest ważne, ale należy to ująć w osobnym porozumieniu.

Przed eksportem: ustal własność i termin

Czyste przekazanie zaczyna się przed jakimkolwiek eksportem. Jeśli uzgodnicie, kto co i kiedy przejmuje, unikniecie niespodzianek z ostatniej chwili, jak złamane wdrożenia, niezapłacone hostingi czy brakujący dostęp.

Ustal datę przekazania i krótki okres zamrożenia

Wybierz datę przekazania i zdefiniuj okno zamrożenia (często 24–72 godziny), w którym wprowadzane są tylko pilne poprawki. Dzięki temu wyeksportowany kod i działający system pozostaną w synchronizacji. Jeśli podczas zamrożenia potrzebny jest hotfix, zapisz dokładnie, co zostało zmienione i upewnij się, że znajduje się to w finalnym eksporcie.

Wyjaśnij własność kont i rozliczeń

Ustal, kto będzie właścicielem DNS, hostingu w chmurze i usług płatnych po przekazaniu. To nie tylko papierkowa sprawa. Jeśli płatności pozostaną na karcie agencji, usługi mogą zostać przerwane bez ostrzeżenia.

Szybki sposób, by to uściślić:

• Wymień właściciela konta dla DNS, hostingu i e-maili
• Potwierdź, kto pokrywa poszczególne rachunki od daty przekazania
• Zdecyduj, czy konta są przekazywane, czy tworzone na nowo przez klienta
• Zanotuj kontakt wsparcia dla każdego dostawcy

Zapisz to prostym językiem, aby obie strony mogły to śledzić.

Wymień środowiska i gdzie działają

Uzgodnij, jakie środowiska istnieją (local, staging, production) i gdzie każde z nich działa. Zaznacz, czy staging to oddzielny serwer, oddzielna baza danych, czy tylko flaga funkcji. Jeśli używałeś platformy takiej jak Koder.ai, potwierdź, co jest tam hostowane, a co ma działać w infrastrukturze klienta po eksporcie.

Zbierz dostęp wcześniej

Nie czekaj do ostatniego dnia z prośbą o dostęp. Upewnij się, że właściwe osoby mają dostęp do repo, CI, hostingu, bazy danych i dostawcy e-maili.

Uzgodnij też proces akceptacji końcowej i sposób podpisania przekazania. Na przykład: „Klient potrafi zbudować z czystej maszyny, uruchomić migracje, wdrożyć na staging i przejść test dymny. Następnie obie strony podpisują akceptację na piśmie.”

Podstawy repozytorium i dokumentacji do dołączenia

Dobra checklista przekazania zaczyna się od repo, które nowy zespół może otworzyć i zrozumieć w kilka minut. Potwierdź, co jest dołączone (kod aplikacji, szablony konfiguracji, skrypty) i co jest celowo wyłączone (prawdziwe sekrety, klucze prywatne, duże pliki generowane). Jeśli coś jest wyłączone, napisz, gdzie to jest i kto za to odpowiada.

Utrzymuj przewidywalną strukturę. Celuj w jasne foldery najwyższego poziomu, takie jak frontend/, backend/, mobile/, infra/, scripts/ i docs/. Jeśli projekt to monorepo, wytłumacz, jak elementy się ze sobą łączą i jak uruchomić każdy z nich.

README powinien być użyteczny dla osoby, która nie budowała projektu. Powinien obejmować wymagania wstępne i najszybszą ścieżkę do działającego środowiska deweloperskiego, bez domysłów.

Co udokumentować (minimum)

Dołącz krótki, ludzki fragment README, który odpowiada na:

• Co zawiera to repo i do czego służy (jeden akapit)
• Wymagania wstępne z dokładnymi wersjami (runtime, menedżer pakietów, Docker jeśli potrzebny)
• Jednolinijkowe kroki uruchomienia lokalnego (i co oznacza „sukces”)
• Jak uruchomić testy i zbudować artefakt produkcyjny
• Gdzie znaleźć kluczowe dokumenty: notatki architektoniczne, migracje, uwagi wdrożeniowe

Dodaj proste notatki architektoniczne prostym językiem: co komunikuje się z czym i dlaczego. Mały diagram jest opcjonalny, ale kilka zdań zwykle wystarczy. Przykład: „Frontend w React wywołuje API w Go. API czyta i zapisuje do PostgreSQL. Zadania tła działają jako osobny worker.”

Na koniec dołącz wersjonowany changelog lub notatki wydania dla builda przekazania. Może to być CHANGELOG.md lub krótki plik „handoff release notes”, który podaje dokładny commit/tag, co zostało wysłane i znane problemy.

Jeśli kod został wyeksportowany z platformy takiej jak Koder.ai, zanotuj wygenerowany typ projektu (web, server, mobile), oczekiwany toolchain (np. React, Go, PostgreSQL, Flutter) oraz obsługiwane wersje OS/narzędzi, których klient powinien używać do reprodukcji buildu.

Zmienne środowiskowe: inwentarz i dokumentacja

Zmienne środowiskowe często są powodem, dla którego „działająca aplikacja” przestaje działać zaraz po przekazaniu. Dobra checklista traktuje je jak część produktu, a nie dodatek.

Zacznij od stworzenia inwentarza, którego nowy zespół może użyć bez zgadywania. Trzymaj go prostym językiem i dołącz przykładowy format wartości (nie prawdziwe sekrety). Jeśli zmienna jest opcjonalna, napisz, co się stanie, gdy jej brak i jaka jest domyślna wartość.

Prosty sposób prezentacji inwentarza to:

• Nazwa zmiennej, co kontroluje i przykładowy format wartości
• Wymagana vs opcjonalna oraz zachowanie domyślne
• Gdzie jest ustawiana (CI, dashboard hostingu, lokalny plik .env)
• Które środowiska potrzebują różnych wartości (dev, staging, production)
• Kto jest właścicielem zmian (klient, agencja lub wspólne)

Wyraźnie wskaż różnice specyficzne dla środowisk. Na przykład staging może wskazywać na bazę testową i sandbox dostawcy płatności, podczas gdy produkcja używa usług live. Zanotuj też wartości, które muszą być zgodne w różnych systemach, jak callback URL, allowed origins czy identyfikatory pakietów mobilnych.

Udokumentuj, gdzie dziś każda wartość się znajduje. Wiele zespołów rozdziela wartości: lokalne .env dla dewelopmentu, zmienne CI dla buildów i ustawienia hostingu dla runtime. Jeśli eksportowałeś z Koder.ai, dołącz .env.example i krótko opisz, które zmienne trzeba wypełnić przed pierwszym buildem.

Na koniec udowodnij, że w repo nie ma ukrytych sekretów. Nie ograniczaj się do sprawdzenia obecnych plików. Przejrzyj historię commitów pod kątem przypadkowych kluczy, starych .env lub skopiowanych poświadczeń w przykładowych konfiguracjach.

Konkretne przykłady: frontend React + API w Go może potrzebować API_BASE_URL dla aplikacji web, oraz DATABASE_URL i JWT_SIGNING_KEY dla backendu. Jeśli staging używa innej domeny, napisz obie wartości i powiedz, gdzie je zmienić, aby nowy zespół nie wdrożył ustawień staging do produkcji.

Rotacja sekretów: przekazanie bezpieczne, a potem udowodnienie działania

Przekazanie nie jest kompletne, dopóki klient nie kontroluje każdego poświadczenia, których aplikacja potrzebuje. To oznacza rotację sekretów, a nie tylko ich współdzielenie. Jeśli agencja (lub były wykonawca) nadal ma działające klucze, pozostaje nieaudytowalny dostęp.

Zacznij od pełnego inwentarza. Nie ograniczaj się do haseł do bazy. Uwzględnij klucze API zewnętrznych dostawców, sekrety klienta OAuth, sekrety webhooków, klucze podpisujące JWT, poświadczenia SMTP, klucze dostępu do storage i wszelkie tymczasowe tokeny w CI.

Oto prosta checklista na dzień rotacji:

• Wypisz każdy sekret, co odblokowuje i gdzie jest obecnie ustawiony (lokalne pliki env, CI, dashboard hostingu, vault)
• Utwórz nowe poświadczenia w kontach klienta i przypisz właściciela dla każdego (osoba i skrzynka zespołowa)
• Zaktualizuj konfigurację aplikacji, aby używała nowych wartości, a następnie wdroż na staging/test najpierw
• Cofnij stare poświadczenia natychmiast po potwierdzeniu działania nowych
• Zapisz dokładne kroki rotacji, aby kolejna rotacja była nudna i szybka

Po rotacji upewnij się, że nic nie zepsuło się w praktyce. Wykonaj szybkie testy „prawdziwego użytkownika” zamiast tylko sprawdzania logów.

Skoncentruj się na przepływach zależnych od sekretów:

• Logowanie, rejestracja, reset hasła i odświeżanie tokenów
• Płatności, wysyłka e-maili i przesyłanie plików
• Webhooki (weryfikacja podpisu i obsługa retry)
• Zadania tła lub zaplanowane, które wywołują API zewnętrzne
• Akcje administracyjne trafiające do chronionych endpointów

Przykład: jeśli wyeksportowałeś projekt z Koder.ai i aplikacja używa dostawcy płatności oraz dostawcy e-mail, obróć oba klucze, wdroż, a następnie wykonaj małą transakcję testową i wyślij testowy e-mail. Dopiero po ich powodzeniu odwołaj klucze agencji.

Na koniec udokumentuj, gdzie sekrety będą przechowywane dalej (vault, zmienne CI lub ustawienia hostingu), kto może je zmieniać i jak cofnąć zmianę, jeśli rotacja spowoduje błąd.

Migracje bazy danych i obsługa danych

Przekazanie może wyglądać na „gotowe”, podczas gdy to baza danych zepsuje wszystko jako pierwsza. Traktuj migracje i dane jako produkt sam w sobie: wersjonowany, powtarzalny i przetestowany.

Zacznij od zapisania aktualnej wersji bazy danych i miejsca, gdzie migracje znajdują się w repo. Bądź konkretny: ścieżka folderu, wzorzec nazewnictwa i najnowszy identyfikator migracji (lub znacznik czasu). Jeśli używasz PostgreSQL (często z backendem w Go), zanotuj też wymagane rozszerzenia.

Co udokumentować (aby ktoś mógł to uruchomić)

Dołącz krótki runbook, który odpowiada na pytania:

• Która komenda uruchamia migracje i w jakiej kolejności wykonywać czynności (utwórz bazę, zastosuj migracje, potem seedy)
• Jak to się różni w zależności od środowiska (local, staging, production), włączając ewentualne flagi „safe mode”
• Czy migracje są automatyczne przy wdrożeniu, czy trzeba je uruchomić ręcznie, i kto ma do tego uprawnienia
• Strategia seedowania danych: brak, tylko demo, czy minimalne wymagane rekordy (użytkownik admin, domyślne ustawienia)
• Plan rollbacku: co można odwrócić, a co nie (np. destrukcyjne usunięcie kolumn)

Rollbacky wymagają uczciwości. Niektóre zmiany da się cofnąć tylko przywracając backup. Wyraź to prostym językiem i połącz z krokiem backupu (snapshot przed wdrożeniem, weryfikacja procesu przywracania).

Przed ukończeniem przekazania uruchom migracje na kopii danych produkcyjnych, jeśli to możliwe. To wychwytuje wolne zapytania, brakujące indeksy i problemy typu „działa na pustych danych”. Realistycznym testem jest eksport kodu, ustawienie zmiennych środowiskowych, przywrócenie zanonimizowanego zrzutu, a następnie zastosowanie migracji od zera. To pojedyncze ćwiczenie weryfikuje dużą część checklisty.

Jeśli aplikacja została zbudowana na platformie takiej jak Koder.ai i potem wyeksportowana, sprawdź, czy pliki migracji i jakiekolwiek skrypty seed są dołączone do eksportu i nadal poprawnie odwoływane przez proces startu backendu.

Build i CI: uczynij to powtarzalnym

Przekazanie jest kompletne tylko wtedy, gdy ktoś inny potrafi odbudować aplikację od zera na czystej maszynie. Twoja checklista powinna zawierać dokładne polecenia build, wymagane wersje i oczekiwane wyjście (np. „web bundle w /dist”, „binarka API”, „lokalizacja APK Flutter”).

Zapisz narzędzia i menedżery pakietów, których faktycznie używasz, a nie to, co myślisz, że używasz. Dla typowego stacku to może być Node.js (npm lub pnpm) dla Reacta, toolchain Go dla serwera, narzędzia klienta PostgreSQL dla lokalnej konfiguracji i SDK Flutter dla mobilnych.

Spraw, aby instalacje zależności były przewidywalne. Potwierdź, że lockfile są zatwierdzone (package-lock.json, pnpm-lock.yaml, go.sum, pubspec.lock) i wykonaj świeżą instalację na nowym komputerze lub czystym kontenerze, aby udowodnić, że działa.

Zarejestruj, co robi CI krok po kroku, aby można to było skopiować do innego providera CI, jeśli zajdzie potrzeba:

• Instalacja zależności (z lockfile)
• Uruchomienie testów i lintów
• Build outputs (web bundle, binarka serwera, build mobilny)
• Produkcja artefaktów (zip, obraz Docker, pakiet wydania)
• Przechowywanie logów i metadanych builda (wersja, commit, data)

Oddziel konfigurację build-time od runtime. Konfiguracja w czasie buildu zmienia to, co jest kompilowane (np. API base URL wbudowany w web bundle). Konfiguracja runtime jest wstrzykiwana przy starcie aplikacji (np. adresy DB, klucze API i flagi funkcji). Mieszanie ich powoduje często sytuacje „działa w CI” ale zawodzi po wdrożeniu.

Podaj prosty przepis weryfikacji lokalnej. Nawet krótki zestaw komend wystarczy:

# Web
pnpm install
pnpm test
pnpm build

# API
go test ./...
go build ./cmd/server

# Mobile
flutter pub get
flutter test
flutter build apk

Jeśli eksportujesz z platformy takiej jak Koder.ai, dołącz wygenerowane pliki CI lub presety buildów używane podczas wdrożenia, aby klient mógł odtworzyć ten sam proces poza platformą.

Skrypty wdrożeniowe i proces wydania

Dobra checklista przekazania nie kończy się na „oto repo”. Wyjaśnia też, jak kod trafia do działającej usługi i kto naciska przycisk.

Zacznij od zapisania, jak dziś wyglądają wdrożenia: w pełni ręczne (ktoś uruchamia polecenia na serwerze), napędzane przez CI (pipeline buduje i wdraża) lub przez platformę hostowaną. Dołącz, gdzie konfiguracje żyją i jakie środowiska istnieją (dev, staging, production).

Uczyń kroki wydania powtarzalnymi. Jeśli proces zależy od pamięci jednej osoby i 12 poleceń, przerób to na skrypty i zanotuj wymagane uprawnienia.

Co dołączyć do pakietu wdrożeniowego

Daj klientowi wystarczająco, aby wdrożyć w dniu pierwszym:

• Komendy build i run (z dokładnymi wersjami Node, Go, Flutter itp.)
• Skrypty wdrożeniowe (skrypty shell, cele Makefile lub konfiguracje pipeline)
• Wymagane dostępy: role konta chmurowego, rejestr kontenerów, DNS, admin bazy danych
• Notatki konfiguracji środowiska: gdzie ustawiane są env var i jak różnią się między środowiskami
• Nazewnictwo wydań: tagi/release i jak identyfikować, co jest uruchomione

Uzgodnij oczekiwania dotyczące przestojów. Jeśli wymagane jest „zero downtime”, wyjaśnij, co to oznacza w praktyce (blue-green, rolling deploy, okno tylko do odczytu na migracje). Jeśli przestój jest akceptowalny, zdefiniuj jasne okno.

Statyczne zasoby i cache to częste punkty awarii. Zanotuj, jak buduje się i serwuje assety, kiedy czyścić cache i czy jest zaangażowany CDN.

Rollback, który dasz radę wykonać

Rollback powinien być krótkim, przetestowanym przepisem powiązanym z tagiem lub ID wydania. Na przykład: wdroż poprzedni tag, przywróć poprzedni snapshot bazy danych jeśli trzeba i unieważnij cache.

Jeśli aplikacja powstała na Koder.ai i potem została wyeksportowana, wspomnij o ostatniej znanej dobrej migawce i dokładnej wersji eksportu, aby klient mógł szybko dopasować kod do działającego wydania.

Krok po kroku: weryfikacja buildu po eksporcie

Weryfikacja to moment, w którym dowiadujesz się, czy przekazanie jest realne. Cel jest prosty: nowa osoba potrafi wziąć wyeksportowany kod, skonfigurować go i uruchomić tę samą aplikację bez zgadywania.

Zanim zaczniesz, zapisz, jak wygląda „poprawnie”: wersja uruchomionej aplikacji, aktualny commit/tag (jeśli jest) i jeden lub dwa kluczowe ekrany albo odpowiedzi API do porównania. Jeśli eksport pochodzi z platformy takiej jak Koder.ai, zanotuj snapshot lub znacznik czasu eksportu, aby udowodnić, że testowałeś najnowszy stan.

1. Potwierdź, że eksport pasuje do produkcji: sprawdź historię commitów, notatki wydania lub metadane builda. Porównaj widoczny numer wersji lub małe zachowanie (np. konkretne ustawienie UI) z działającą aplikacją.
2. Skonfiguruj zmienne środowiskowe i sekrety: utwórz docelową konfigurację środowiska (local i staging). Użyj dostarczonego inwentarza zmiennych i upewnij się, że nic nie jest zakodowane na stałe w repo.
3. Zainstaluj zależności i uruchom testy: wykonaj czystą instalację (bez cache folderów node_modules/vendor). Uruchom testy jednostkowe i linty dokładnie tak, jak w dokumentacji.
4. Uruchom migracje i start lokalnie: postaw bazę, zastosuj migracje w kolejności i uruchom aplikację. Potwierdź, że aplikacja potrafi czytać/zapisywać podstawowe dane i że nie ma oczekujących migracji.
5. Wdroż na staging, przeprowadź test dymny, potem promuj: wdrażaj używając tych samych skryptów/pipeline, które planujesz użyć na produkcji. Promuj dopiero, gdy staging spełnia oczekiwania.

Dla testów dymnych trzymaj się krótkiego zestawu związanego z ryzykiem:

• Logowanie/wylogowanie (lub utworzenie testowego użytkownika)
• Jeden kluczowy workflow end-to-end (utwórz-edytuj-zapisz)
• Jeden email/webhook/wywołanie płatności jeśli dotyczy
• Podstawowa obsługa błędów (złe dane, brak rekordu)
• Logi nie pokazują powtarzających się crashy ani błędów związanych z sekretami

Jeśli coś zawodzi, zapisz dokładne polecenie, wyjście błędu i użyte zmienne środowiskowe. Te szczegóły oszczędzają godziny przy zmianie właściciela.

Typowe błędy przy przekazaniu i jak ich unikać

Najszybszy sposób, by przekazanie zamienić w pożar, to założyć, że „kod wystarczy”. Dobra checklista koncentruje się na małych, nudnych detalach, które decydują, czy klient potrafi naprawdę uruchamiać i zmieniać aplikację bez was.

Błędy, które powodują największe problemy

Większość problemów wpisuje się w kilka powtarzających się wzorców:

• Sekrety nie są rotowane, więc stare hasła agencji, klucze API lub tokeny chmurowe nadal działają po przekazaniu.
• Zmienne środowiskowe są niekompletne, bo niektóre wartości żyją tylko w CI lub dashboardzie hostingu, a nie w repo.
• Jednorazowe zmiany produkcyjne są zapomniane, jak szybki hotfix, ręczna edycja DB lub przełącznik konfiguracji ustawiony bezpośrednio na serwerze.
• Migracje działają lokalnie, ale zawodzą w produkcji z powodu brakujących uprawnień, rozszerzeń lub własności schematu.
• Brak planu rollback i brak oznaczonego wydania (lub notatki), do którego można wrócić, gdy pierwsze wdrożenie pójdzie nie tak.

Jak im zapobiec (bez wydłużania czasu o tygodnie)

Zrób z rotacji i sprzątania dostępu zadanie zaplanowane, a nie „jak znajdziemy czas”. Ustal datę, kiedy konta agencji są usuwane, klucze regenerowane, i klient potwierdza, że potrafi wdrożyć tylko na swoich poświadczeniach.

Dla zmiennych środowiskowych zrób prosty inwentarz z trzech miejsc: repo, system CI i UI hostingu. Następnie zweryfikuj to, wykonując czysty build na świeżej maszynie lub w kontenerze.

Dla migracji testuj z tą samą rolą bazy danych, której użyje produkcyjny deployment. Jeśli produkcja wymaga podwyższonych kroków (np. włączenia rozszerzenia), zapisz je i jasno określ odpowiedzialność.

Realistyczny przykład: po eksporcie projektu z Koder.ai klient pomyślnie wdraża, ale zadania tła zawodzą, bo jeden URL kolejki był ustawiony tylko w dashboardzie hostingu. Prosty audyt zmiennych środowiskowych by to wychwycił. Połącz to z oznaczonym wydaniem i udokumentowanym rollbackem (np. „wdroż tag v1.8.2 i przywróć ostatni snapshot”) i zespół uniknie przestojów.

Ostateczna checklista, prosty przykład i kolejne kroki

Jeśli zachowasz tylko jedną stronę z tej checklisty, niech to będzie ta. Cel jest prosty: czysta kopia powinna uruchamiać się na nowej maszynie, z nowymi sekretami i z bazą, która może iść do przodu bezpiecznie.

Szybkie kontrole (wykonaj z świeżego klona)

Wykonaj te kontrole na laptopie, który nigdy nie widział projektu (lub w czystym kontenerze/VM). To najszybszy sposób wykrycia brakujących plików, ukrytych założeń i starych poświadczeń.

• Build od zera: zainstaluj zależności, uruchom testy (jeśli są) i wygeneruj build wydania bez ręcznych poprawek.
• Konfiguracja działa: ustaw udokumentowane zmienne środowiskowe i potwierdź, że aplikacja uruchamia się z czystym plikiem konfiguracyjnym lub setupem env.
• Sekrety są rotowane: zweryfikuj, że aplikacja działa na nowych kluczach, potem odwołaj stare i potwierdź, że nic nie przestaje działać.
• Migracje przechodzą czysto: zacznij od pustej bazy, uruchom migracje, potem start aplikacji i wykonaj podstawowy workflow.
• Ścieżka wdrożenia jest realna: uruchom skrypt wdrożeniowy lub workflow CI raz i potwierdź, że daje takie samo wyjście.

Prosty przykład przekazania

Agencja przekazuje frontend React, API w Go i bazę PostgreSQL. Zespół klienta klonuje repo, kopiuje dostarczone .env.example do realnych zmiennych, tworzy nowe poświadczenia do bazy, dostawcy e-mail i zewnętrznych API. Uruchamia go test (lub uzgodnione polecenie testowe), buduje aplikację React, aplikuje migracje do świeżej instancji Postgresa i uruchamia obie usługi. Na koniec wdraża używając opisanego skryptu i potwierdza, że ten sam commit da się odbudować później.

Kolejne kroki

Utrzymaj przekazanie krótkie i z właścicielem. 30–60 minut przeglądu zwykle przebije długi dokument.

• Umów spotkanie przeglądowe i nagraj ustalenia (kto odpowiada za deployy, sekrety i zmiany bazy)
• Przydziel jednego właściciela dostępu produkcyjnego i jednego backupu
• Uzgodnij końcowy commit hash akceptacyjny i oznacz go tagiem
• Jeśli budowałeś w Koder.ai, wyeksportuj kod, a potem użyj migawek i rollbacku podczas pierwszego wdrożenia wykonanego przez klienta, aby zredukować ryzyko.