Oferta
Jakość i zgodność w pipeline
Wymagania prawne, SEO, dostępnościowe i bezpieczeństwa zamieniamy w automatyczne bramki w CI/CD, które przerywają build, zamiast starzeć się w dokumencie.
Wymóg zapisany w dokumencie ktoś przeczyta raz, zapamięta na tydzień i zapomni. Wymóg zapisany w pipeline przerywa build za każdym razem, gdy przestaje być spełniony. Na tej różnicy stoi pierwszy filar naszej oferty.
Bierzemy wymagania klienta - prawne, SEO, dostępnościowe, bezpieczeństwa - i zamieniamy je w asercje, które sprawdzają wygenerowaną stronę, a nie intencję zapisaną w polityce. Asercja przechodzi albo nie przechodzi. Nie ma trzeciej opcji i nie ma czekania na kolejny audyt, żeby się o tym dowiedzieć.
Przewaga, którą sprzedajemy, jest metodyczna, nie tematyczna. Nie chodzi o listę technologii ani o certyfikat na ścianie, tylko o sposób pracy: każdy wymóg dostaje test, każdy test wchodzi do CI, każda kolejna zmiana w kodzie przechodzi przez te same bramki co dzień wcześniej.
Tę metodę stosujemy najpierw na sobie. search-quality-kit to nasz własny pakiet, publiczny na npm: około 60 plików źródłowych w TypeScript, około 10 tysięcy linii kodu, 30 plików testów. Audytuje techniczne fundamenty strony - między innymi crawlability, metadane, dane strukturalne i podstawową dostępność - i pracuje w pipeline CI trzech serwisów, które prowadzimy, w tym tego, na którym właśnie czytasz tę stronę oraz CyberKatalog.pl. Do tej pory nie pojawił się w naszej ofercie ani razu.
Drugi przykład pochodzi z tego samego repozytorium. Nowy wymóg zgody na osadzenia z art. 399 Prawa komunikacji elektronicznej zamieniliśmy w jedną asercję w skrypcie check-build-output.mjs: sprawdza ona, że strona /kontakt/ nie zawiera adresu google.com/maps/embed, zanim użytkownik wyrazi zgodę. Komunikat błędu mówi wprost, o co chodzi: "Contact page must not embed Google Maps before consent; the map is gated behind the embeds category". Jeśli ktoś kiedyś przywróci mapę bez zgody, ten sam build, który dziś przechodzi, przestanie przechodzić.
Ten filar obejmuje między innymi wymogi prawne (na przykład zgody i retencję danych), SEO, dostępność i bezpieczeństwo samego procesu wytwarzania. Nie obejmuje audytu zewnętrznego ani przygotowania do certyfikacji jako osobnej usługi - wymóg wbudowujemy w kod, który i tak piszemy, zamiast dokładać dokument obok niego.
Wykorzystane technologie
- Bramki jakości w CI/CD (GitHub Actions)
- Asercje na wygenerowanym build (HTML, JSON-LD, mapa witryny), nie na dokumencie
- search-quality-kit - własny pakiet npm do audytu technicznych fundamentów strony
- Node.js i TypeScript do własnych skryptów walidujących
- Wymóg wersjonowany razem z kodem w Git, nie w osobnym dokumencie
- Testy jako specyfikacja wymogu, nie tylko zabezpieczenie przed regresją
Co z tego wynika
- Wymóg raz zapisany w kodzie obowiązuje przy każdym kolejnym wdrożeniu, nie tylko w dniu audytu
- Regresja zatrzymuje build, zanim trafi na produkcję, zamiast czekać, aż ktoś ją zauważy ręcznie
- Wymóg i wdrożenie nie rozjeżdżają się w czasie, bo żyją w tym samym repozytorium
- Błąd wymogu wygląda tak samo jak błąd testu jednostkowego - widać go w tym samym logu CI
Przykłady zastosowań
- Bramka pilnująca zgody na osadzenia (mapy, wideo, piksele reklamowe), zanim użytkownik ją wyrazi
- Bramka sprawdzająca obecność wymaganych metadanych, danych strukturalnych i adresów kanonicznych w każdej wygenerowanej stronie
- Bramka pilnująca, że strony objęte klauzulą informacyjną nie trafiają do mapy witryny przeznaczonej do indeksowania
- Bramka sprawdzająca podstawowe progi dostępności w zbudowanej wersji strony, zanim trafi na produkcję