Case studies w branży IT mają problem z wiarygodnością: klient zwykle nie pozwala pokazać kodu ani historii commitów, więc zostają liczby podane na słowo. Mamy jeden projekt, przy którym nie musimy tego robić: własną stronę eskom.ai. Cała jej historia jest w repozytorium, każda liczba poniżej da się sprawdzić w CHANGELOG-u albo w dokumentach wdrożeniowych. Case study klienta zero, czyli nas samych.
Dlaczego akurat to
Strona eskom.ai jest wytwarzana tym samym procesem, który opisaliśmy w artykule „Jak ESKOM AI wytwarza oprogramowanie": agenci AI pod nadzorem inżyniera, testy automatyczne na każdym etapie. Tamten tekst opisuje proces. Ten pokazuje, co ten proces zostawia po sobie w konkretnym, sprawdzalnym projekcie: 27 wersji językowych, ponad 8 500 stron, panel administracyjny, backend z integracjami zewnętrznymi.
Wdrożenie na produkcję: zawsze ta sama sekwencja
Sekwencja wdrożenia jest udokumentowana i się nie zmienia: backup i tag przed zmianą, pull, build, testy dymne, testy funkcjonalne, bramka decyzyjna GO/NO-GO, dopiero potem przełączenie ruchu. Pierwszy wniosek o zmianę produkcyjną z marca 2026 (CR-001) rozpisywał tę sekwencję na około 18 minut od backupu do decyzji GO/NO-GO. To był plan, nie stoper. Plan wycofania jest gotowy przed rozpoczęciem, nie pisany w panice, gdyby coś poszło źle.
Uczciwa historia: luka, którą sami znaleźliśmy
Najłatwiej byłoby napisać, że mamy testy end-to-end w 32 plikach (stan na 13 sierpnia 2026) i skończyć na tym. To prawda, ale niecała. Przez pewien czas te testy istniały w repozytorium i nie były uruchamiane przez CI. Konfiguracja pipeline'u miała zero odwołań do e2e, mimo że kod testów czekał gotowy. Innymi słowy: mieliśmy zabezpieczenie, które nikogo nie zabezpieczało, bo nikt go nie włączał przy każdej zmianie.
Znaleźliśmy to sami, w ramach rutynowego przeglądu, nie po incydencie. Naprawa: pierwszy uruchamiany podzbiór testów e2e w CI, zweryfikowany linia po linii przed włączeniem, z planem rozszerzenia na pozostałe. Piszemy o tym wprost, bo to lepiej pokazuje, jak wygląda nasz proces kontroli jakości niż sama końcowa liczba. Łapanie własnych luk, zanim zrobi to ktoś inny, jest częścią tego samego procesu testowego co pisanie nowych testów.
Co jeszcze pilnuje jakości na co dzień
Skanowanie sekretów: bramka assert_gitleaks_coverage.sh z 11 testami, wszystkie zielone. Pilnuje, żeby żaden klucz API ani hasło nie trafiły do repozytorium.
Zgodność treści z RODO sprawdza osobna, automatyczna bramka. Rozrosła się z 15 do 19 testów w miarę wykrywania nowych przypadków.
Świeżość danych w panelu administracyjnym, pojedynczy przykład z wielu: test lighthouseFreshness.test.ts ma 20 osobnych asercji sprawdzających, że wyniki audytów wydajności pokazywane administratorom nie są przestarzałe.
Wydajność: wynik Lighthouse 100/100/100/100 (wydajność, dostępność, najlepsze praktyki, SEO) jako cel przyjęty i osiągnięty po etapie hardeningu bezpieczeństwa.
Co to pokazuje, a czego nie
Te liczby nie dowodzą, że nigdy nic się nie psuje — psuje się, jak w każdym żywym projekcie. Dowodzą czegoś węższego i bardziej sprawdzalnego: że proces wytwarzania, który oferujemy klientom, jest tym samym procesem, którym testujemy i wdrażamy własną stronę, na oczach każdego, kto zajrzy do repozytorium. Nie ma osobnej, lepszej wersji procesu zarezerwowanej dla klientów płacących za projekt. Jest jedna, używana też u nas.
FAQ
Czy te liczby są aktualne, czy to zrzut z jednego dnia?
To zrzut z konkretnego momentu rozwoju projektu (stan repozytorium i CHANGELOG-a na 13 sierpnia 2026). Projekt rozwija się dalej, więc niektóre liczby dziś są już wyższe. Nie aktualizujemy tego tekstu przy każdej zmianie. Jeśli potrzebują Państwo aktualnego stanu konkretnego obszaru, pytamy i sprawdzamy na żywo.
Dlaczego pokazujecie własną lukę zamiast tylko sukcesów?
Bo to jest bardziej wiarygodne niż sama lista liczb. Każdy może napisać „mamy testy e2e”. Mniej firm pisze wprost, że przez jakiś czas te testy nie były uruchamiane, i pokazuje, jak to naprawiono. To druga połowa tego samego procesu, który opisujemy klientom: testy plus przegląd tego, czy testy faktycznie działają.
Czy mój projekt dostanie ten sam poziom testów?
Zakres testów dobieramy do skali i ryzyka konkretnego projektu. Mniejsza integracja nie potrzebuje identycznego zestawu bramek co publiczna strona firmy. Zasada jest ta sama: żadna zmiana nie trafia na produkcję bez przejścia testów adekwatnych do tego, co może pójść źle.
Zobaczmy, jak to wygląda dla Państwa projektu
Jeśli interesuje Państwa, jak wygląda proces testowania i wdrożeń w praktyce, najprościej to omówić na konkretnym przypadku. Umówmy bezpłatną konsultację przez formularz kontaktowy →