Usługi / Ecommerce
Sklepy i platformyInfrastruktura sklepu, którą da się rozwijać
Projektujemy infrastrukturę pod Magento, PrestaShop, WordPress i WooCommerce. Katalog, koszyk i płatności mają środowiska, pipeline i krawędź. Rozwój sklepu idzie razem z opieką day-2, pikami sezonu i kopią, którą da się odtworzyć.
Jak to składa się w całość
Platforma, stack, pipeline, krawędź
Sam hosting sklepu nie wystarcza. Składamy platformę, środowiska, rozwój katalogu i krawędź tak, żeby Magento, PrestaShop albo WordPress dało się utrzymać i rozwijać.
- Nie wchodzimy w merchandising. Trzymamy infrastrukturę i delivery pod sklepem.
- Pik sezonu, boty na koszyku i restore są częścią zakresu, nie dodatkiem po starcie.
Katalog i zamówienia na stacku, który da się utrzymać
Magento trzyma katalog, ceny, zamówienia i integracje. My trzymamy to, na czym to stoi: PHP, baza, Redis, Elasticsearch, CDN i pipeline. Dashboard pokazuje sprzedaż. Operacja pokazuje, czy deploy i pik nie złożą sklepu.
Stack
PHP, MariaDB albo MySQL, Redis, search, media. Wersje i limity zapisane, nie w lore zespołu.
Katalog
Indeks, cache full page, media na CDN. Zmiana atrybutu nie kładzie listingów w godzinę szczytu.
Checkout
Sesja, płatność, webhook. Timeout i retry mają właściciela.
Deploy
Build, static content, indexer w oknie. Rollback do znanego artefaktu.
Back office i środowiska, które da się powtórzyć
PrestaShop jest czytelny dla sklepu i agencji. Słabnie, gdy każdy serwer jest ręczny, a moduł idzie na produkcję bez stagingu. Składamy środowiska, cache, krawędź i backup tak, żeby back office został narzędziem sprzedaży, nie jedyną konsolą opsu.
Środowiska
Dev, staging, produkcja z tym samym opisem. Moduł najpierw na kopii, potem na sklepie.
Wydajność
Cache, obrazki, baza. Front nie czeka na cron ani na import XML w południe.
Moduły
Inwentarz, aktualizacje, konflikt. Zmiana płatności ma okno i plan cofnięcia.
Krawędź
CDN, WAF, boty na checkout i wyszukiwarce, origin poza publicznym internetem.
Sklep w CMS, z twardą warstwą pod spodem
WordPress i WooCommerce są częstym wyborem katalogu i treści. Produkt, stan magazynu i zamówienie muszą przeżyć plugin, pik i kopię. Trzymamy PHP, bazę, object cache, media i aktualizacje tak, żeby sklep nie stał na jednym hostingu bez śladu.
Katalog
Produkty, stany, ceny, import. Indeks i cache po zmianie, nie po zgłoszeniu klienta.
Plugin
Inwentarz rozszerzeń, staging przed aktualizacją, sekrety poza wp-config w repo.
Płatności
Webhook, idempotencja, log. Bramka nie ginie w mailu od wtyczki.
Hardening
Aktualizacje, limity logowania, WAF, oddzielony admin, backup z testem restore.
CI, krawędź i test, zanim przyjdzie sezon
Rozwój sklepu to nie sam motyw. GitLab buduje i testuje zmianę katalogu albo checkoutu. Cloudflare trzyma boty i WAF przed originem. k6 sprawdza koszyk, zanim przyjdzie pik. To ten sam zakres co DevOps, ułożony pod Magento, PrestaShop albo WordPress.
Pipeline
Test, skan, artefakt, deploy. Merge nie omija stagingu.
Krawędź
DNS, TLS, WAF, bot score. Origin bez publicznego adresu.
Pik
Scenariusz koszyka i listingów w k6. Wąskie gardło bazy albo cache widać przed sezonem.
Opieka
Dyżur, okno zmiany, skan i restore. Rozwój nie kończy się na publikacji motywu.
Operacja
Od mapy sklepu do opieki i piku
Najpierw platforma i integracje. Potem środowiska i krawędź. Na końcu pipeline, dyżur i test sezonu.
- Mapa Platforma, katalog, płatności, wąskie gardła.
- Stack Środowiska, cache, krawędź, backup.
- Rozwój Pipeline, staging, bramki jakości.
- Opieka Dyżur, pik, skan, restore.
Rozmowa
Omówimy platformę, infrastrukturę i rozwój sklepu
Na tej podstawie przygotujemy zakres dla Magento, PrestaShop albo WordPress.
Skontaktuj się