O mypresta.rocks Informacja

Nasza infrastruktura: 100% open source stack deweloperski

Jak mypresta.rocks tworzy i dostarcza moduły PrestaShop: infrastruktura w UE, realistyczne środowiska testowe i wydania sprawdzane przez ludzi.

Stos technologiczny, na którym naprawdę pracujemy, i powody, dla których wybraliśmy każdy element

To jest infrastruktura, która buduje, testuje i wydaje każdy moduł z naszego katalogu. Spisujemy ją, ponieważ pytanie, które najczęściej zadają nam agencje, sprowadza się zwykle do jakiejś wersji następującego: „Czy jesteście prawdziwym zespołem prowadzącym prawdziwą infrastrukturę, czy może trójką freelancerów na Discordzie?". Słuszne pytanie. Oto odpowiedź z lotu ptaka.

Wszystko w naszym potoku wytwarzania jest open source albo legalnie darmowe. To nie pozycjonowanie marki, lecz decyzja zakupowa, którą podjęliśmy lata temu i do której rewizji nie mieliśmy powodu. Żadnego pirackiego oprogramowania, żadnych złamanych licencji, żadnego zamkniętego dostawcy, którego nie dałoby się zastąpić w ciągu weekendu. Praktyczna korzyść jest taka, że nic w naszym potoku nie zależy od licencji, którą moglibyśmy utracić, ani od usługi SaaS, która mogłaby nas odciąć.

Serwer

Pracujemy na sprzęcie zlokalizowanym w UE, który jest naszą własnością. Korzysta on z pamięci masowej zabezpieczonej sumami kontrolnymi, z pamięcią operacyjną korygującą błędy i regularnymi kontrolami integralności. Host należy do nas; wszystko inne to kontener działający na nim.

To podejście do pamięci masowej wybraliśmy z jednego konkretnego powodu: każdy blok jest zabezpieczony sumą kontrolną, a każdy zbiór danych można zatrzymać w migawce w ciągu milisekund. Migawki są na tyle tanie, że tworzymy je przed każdym testem aktualizacji PrestaShop. Kiedy migracja do wersji 9.0 rozbije bazę danych (a tak się zdarzało), przywracamy zbiór danych, a kontener uruchamia się w stan sprzed awarii w kilka sekund. Nawyk tworzenia migawek sprawia, że nieudana migracja kosztuje nas minuty, a nie dzień.

Dlaczego nie duża chmura publiczna

Porównywalna konfiguracja w dużej chmurze publicznej, pamięć operacyjna, przestrzeń dyskowa, przepustowość, którą zużywają nasze kontenery deweloperskie i przejściowe, ruch wychodzący przy przerzucaniu archiwów ZIP i danych demonstracyjnych, kosztowałaby w utrzymaniu zauważalnie więcej każdego miesiąca. Posiadanie sprzętu na własność utrzymuje infrastrukturę o stałym koszcie z przewidywalnymi rachunkami, a nie jako zmienną, która zaskakuje nas, gdy demonstracja dla klienta uruchamia dziesiątki równoległych przeglądarek.

Drugim powodem jest jurysdykcja danych. Nasza infrastruktura znajduje się fizycznie w UE i pod naszą kontrolą. Brak ekspozycji na amerykańską ustawę Cloud Act, brak cichej konfiguracji eksportu logów, którą zapomnieliśmy wyłączyć, brak dopłaty za każde żądanie do wiadomości wsparcia, które wysyłamy. Dla małego sklepu z UE, który współpracuje z unijnymi sprzedawcami, jest to prostszy model, a oznacza to, że rozmowa wsparcia dotycząca Państwa sklepu, wraz z wszelkimi logami, które nam Państwo przesyłają, pozostaje na sprzęcie będącym naszą własnością.

Dedykowane kontenery, wersjonowane obrazy, każda wersja, którą wciąż wspieramy

W dowolnym momencie utrzymujemy w ruchu obciążony zestaw środowisk opartych na kontenerach. Każde z nich to kompletna instalacja PrestaShop z własną bazą danych, własnym użytkownikiem administracyjnym i własnym katalogiem modułów. Utrzymujemy równoległe środowiska dla:

  • PrestaShop 1.6.x: stare, owszem, lecz wciąż istnieją sklepy, które na nim działają, i one nadal kupują nasze moduły.
  • PrestaShop od 1.7.6 do 1.7.8: długi ogon „zaktualizujemy w przyszłym roku".
  • PrestaShop 8.1 i 8.2: bieżąca produkcja dla większości nowych sklepów.
  • PrestaShop 9.0 i 9.1: naszpikowana Symfony przyszłość, w którą wkładamy w tym roku większość prac nad przenoszeniem.
  • Warianty wielosklepowe dla każdej z powyższych. Tryb wielosklepowy psuje moduły na swój szczególny sposób i nie wydamy niczego bez jego przetestowania.

Każda instancja PrestaShop otrzymuje wersję MySQL/MariaDB, której dane wydanie oczekuje, zamiast jednej uniwersalnej bazy danych dla wszystkich. Współdzielona warstwa pamięci podręcznej obsługuje buforowanie sesji i obiektów w całym zestawie, odwzorowując sposób, w jaki produkcyjny hostingodawca faktycznie to konfiguruje.

To właśnie ta konfiguracja wyłapuje błędy, które w przeciwnym razie odkryto by na produkcji. Kiedy klient zgłasza błąd krytyczny na starszej kombinacji PrestaShop i bazy danych z wymuszonym buforowaniem Smarty, mamy dokładnie tę kombinację uruchomioną jeszcze przed obiadem, zamiast jedynie pojedynczej „najnowszej" instalacji, która po cichu ukrywa usterki właściwe dla danej wersji.

Hostowane samodzielnie, nie SaaS

Wszystko, co rozsądnie możemy hostować samodzielnie, hostujemy sami. Na sprzęcie zlokalizowanym w UE, który jest naszą własnością, oznacza to między innymi:

  • Samodzielnie hostowany serwer Git: każde repozytorium modułu znajduje się na sprzęcie będącym naszą własnością, dzięki czemu kanoniczne źródło każdego wydania, które Państwo otrzymują, pozostaje w rękach osób, które je piszą.
  • Samodzielnie hostowany stos pocztowy z DKIM, SPF i DMARC. Państwa odpowiedzi wsparcia nie przechodzą przez zewnętrzny przekaźnik SMTP, który je skanuje.
  • Wewnętrzny system dokumentacji dla naszej bazy wiedzy i procedur operacyjnych, w którym jednorazowa poprawka staje się powtarzalną procedurą, dzięki czemu kolejna osoba trafia na tę samą odpowiedź, zamiast odkrywać ją na nowo.
  • Zaszyfrowany sejf na sekrety dla poświadczeń, których potrzebuje nasze wewnętrzne oprzyrządowanie.
  • Monitorowanie kondycji usług, abyśmy dowiadywali się o awarii kontenera, zanim dowie się o niej klient.
  • Odwrotne proxy z automatycznym SSL na każdej wewnętrznej nazwie hosta.
  • Wewnętrzny DNS, dzięki któremu nowe środowiska deweloperskie pojawiają się w naszej prywatnej sieci za pomocą pojedynczego wpisu.

Samodzielne hostowanie to więcej pracy niż przeciągnięcie karty kredytowej u dostawcy SaaS i mamy świadomość tego kompromisu. Robimy to, ponieważ alternatywą jest pół tuzina awarii dostawców, których nie możemy naprawić, rozsianych po stosie, którego nie kontrolujemy. Kiedy coś szwankuje o 23.00, sami to restartujemy; nie zakładamy zgłoszenia do wsparcia i nie czekamy.

Jak buduje się i recenzuje wydania

Życie modułu nie kończy się w chwili zakupu, więc nie kończy się też infrastruktura, która za nim stoi. Wydanie, które trafia do Państwa zaplecza, jest budowane z tego samego samodzielnie hostowanego źródła Git, w oparciu o które prowadzimy prace. Wdrożenie jest celowo działaniem recenzowanym przez człowieka: nasze zautomatyzowane zadania i asystenci kodowania AI nie publikują wydań z własnej inicjatywy. Zmianę przegląda człowiek, zanim stanie się ona wydaniem. Ten krok recenzji jest bramką, która utrzymuje eksperymentalną zmianę lub zmyślone wywołanie metody z dala od wersji, którą Państwo instalują. Dostęp do naszych systemów wewnętrznych znajduje się za prywatnym, uwierzytelnionym dostępem sieciowym, a nie za otwartym portem.

Stacja robocza dewelopera

Nasza główna maszyna deweloperska działa w nowoczesnym, regularnie aktualizowanym środowisku Linux, otrzymujemy najnowsze PHP, najnowszy Node, najnowsze wszystko, bez czekania, aż jakaś dystrybucja to pobłogosławi. Ma to znaczenie, gdy PrestaShop 9 pojawia się na PHP 8.2+ i musimy zacząć go testować w tym samym tygodniu, w którym ukazują się informacje o wydaniu.

Dlaczego Linux po stronie deweloperskiej

Ponieważ produkcja to Linux. Systemy plików rozróżniające wielkość liter, uprawnienia POSIX, prawdziwe dowiązania symboliczne, cały zestaw. Odziedziczyliśmy zbyt wiele modułów po deweloperach z Windows lub macOS, które działały idealnie na maszynie autora, a natychmiast się psuły na prawdziwym współdzielonym serwerze hostingowym z Linuksem, ponieważ Module.php i module.php to dwa różne pliki na jednym systemie, a jeden i ten sam plik na drugim. Tworzenie oprogramowania na tej samej rodzinie systemów operacyjnych co wdrożenie usuwa całą kategorię błędów z procesu pracy, zanim zdążą trafić do wydania.

Pracujemy w edytorze open source bez telemetrii dostawcy. Codzienne środowisko uruchomieniowe to oparte na kontenerach środowiska na serwerze, kontenery bezrootowe lokalnie oraz pełne lokalne maszyny wirtualne, gdy ich potrzebujemy, zwykle po to, by odtworzyć środowisko cPanel lub Plesk klienta na tyle wiernie, aby zreprodukować błąd właściwy dla danego hostingu.

Asystenci kodowania AI

Nowszy dodatek: asystenci kodowania AI jako część codziennego procesu pracy, przydatni tam, gdzie drugie spojrzenie przyspiesza pracę. Działają na tych samych repozytoriach i tych samych środowiskach opartych na kontenerach co ludzie. Żaden z nich nie ma poświadczeń, by wdrażać na produkcję, to pozostaje działaniem człowieka. Zajmują się długim ogonem zadań „przenieś ten kontroler do PS 9", „sprawdź pod kątem brakujących tokenów CSRF", „przetłumacz treści modułu na niderlandzki". Stosowani z rozwagą, wzmacniacz siły. Stosowani nieostrożnie, wstrzykują zmyślone wywołania metod do bazy kodu, dlatego utrzymujemy krok recenzji przez człowieka, zanim cokolwiek dotrze do archiwum ZIP wydania.

Projektowanie i grafika

Praca nad modułami to nie tylko PHP. Każde wydanie zawiera ikony, banery, zrzuty ekranu sklepu, a czasem niestandardową czcionkę ikonową. Wszystko wytworzone narzędziami open source, z zerowymi wydatkami na Adobe rocznie.

Dlaczego ma to znaczenie, gdy kupują Państwo u nas moduł

Testujemy na tym, czego Państwo używają

Państwa sklep działa na Linuksie, serwerze WWW, bazie danych MySQL/MariaDB, PHP i warstwie pamięci podręcznej. Nasze środowisko deweloperskie działa na tym samym stosie, nie na przybliżeniu Windows-z-WAMP, które zachowuje się inaczej w subtelny i bolesny sposób. Kiedy oznaczamy moduł jako „przetestowany na danej wersji PrestaShop i bazy danych z włączoną pamięcią podręczną", dzieje się tak dlatego, że dosłownie mamy ten kontener uruchomiony, a nie dlatego, że przeczytaliśmy stronę z wymaganiami PrestaShop.

Potrafimy odtworzyć problemy na wersji, której Państwo używają

Ponieważ każda wspierana wersja PrestaShop pozostaje tu uruchomiona, nie debugujemy w oparciu o pojedynczą „najnowszą" instalację, która po cichu ukrywa usterki właściwe dla danej wersji. Nawyk tworzenia migawek oznacza, że możemy odtworzyć regresję na dokładnie tej wersji, na której się pojawiła, zamiast zgadywać.

Mniejsze koszty ogólne, brak dopłaty za licencje

Zerowe wydatki na cykliczne rachunki za oprogramowanie zamknięte, które ponosi typowa pracownia deweloperska. To koszt cykliczny, którego nie musimy odzyskiwać w cenach modułów.

Ten sam model co sam PrestaShop

PrestaShop jest open source. Wybrali go Państwo z tego powodu. My wybraliśmy naszą infrastrukturę z tego samego powodu. Kupując u nas moduł, kupują go Państwo od zespołu, który od początku do końca żyje wewnątrz modelu open source, a nie od takiego, który sprzedaje moduły dla otwartej platformy, prowadząc jednocześnie własną działalność na zamkniętych narzędziach, bez których nie zdołałby przetrwać.

Jak do tego doszliśmy

Ta konfiguracja nie powstała na tablicy. Każdy jej element zastąpił poprzedni, który zawiódł w zapadający w pamięć sposób.

Osobne kontenery istnieją, ponieważ zmęczyły nas zgłoszenia „u mnie działa", których nie potrafiliśmy odtworzyć. Migawki pamięci masowej istnieją, ponieważ kiedyś straciliśmy większość dnia na spartaczoną migrację z 1.7 do 8 i uznaliśmy, że jeden raz wystarczy. Samodzielnie hostowany stos pocztowy istnieje, ponieważ duży dostawca poczty internetowej zaczął oznaczać nasze odpowiedzi wsparcia jako spam na tyle często, że klienci sądzili, iż ich ignorujemy. Wewnętrzny resolver DNS zastąpił ręcznie edytowany plik /etc/hosts, który psuł się za każdym razem, gdy ktoś dodawał nową deweloperską subdomenę. Wewnętrzna wiki zastąpiła stos plików Markdown w repozytorium, którego nikt nie czytał.

Nic z tego nie jest teoretyczne. Każda zmiana rozwiązała problem, który kosztował nas realny czas. To jedyny powód, dla którego się utrzymała, i ten sam powód, dla którego sprawdza się pod modułami, których Państwo używają.

Dalsza lektura

Do góry