Co QA bierze na siebie po wdrożeniu

Ten wpis jest częścią serii Jakość w CI/CD. Jeśli pominąłeś poprzedni, przeczytaj Część 7 — Regresja oparta na ryzyku.

---

Wprowadzenie — pipeline był zielony, a użytkownik nie

Wdrożenie się skończyło. Dashboardy stoją. Ktoś pyta, czy QA już skończyło. Uczciwa odpowiedź to lista: które podróże udowodnisz na produkcji, kto patrzy na nie przez pierwszą godzinę i co dołożysz do suite, jeśli padną.

To nie jest dyżur na CPU. To ten kawałek produkcji, który nadal jest testem.

Podróże, które idą po wydaniu

Weź kubełek pull requestu z części 7. Wybierz trzy do pięciu podróży, które ruszają pieniądze, tożsamość albo dane, których użytkownik nie odtworzy. Odpalaj je jako syntetyki na produkcji, co kilka minut, na koncie i danych, które wolno wam tworzyć.

- name: Synthetic checkout
  run: npx playwright test --grep @synthetic
  env:
    BASE_URL: https://app.example.com
    SYNTHETIC_USER: ${{ secrets.SYNTHETIC_USER }}

Syntetyk na koncie prawdziwego klienta obudzi was przy zmianie jego hasła. Syntetyk, który składa zamówienie, musi iść przez zaślepkę płatności albo zamówienie, które da się unieważnić. Zapisz to ograniczenie obok joba.

Jeśli podróży w ogóle nie da się puścić na produkcji, powiedz to. Smoke na stagingu po zbudowaniu artefaktu jest planem awaryjnym. Nazywaj go stagingiem. Nie nazywaj go produkcją.

Pierwsza godzina

Przy wydaniu, które zmienia jedną z tych podróży, ktoś patrzy przez pierwszą godzinę. Może to być QA. Pytania są stałe:

• Czy syntetyk został zielony przez trzy interwały?
• Czy liczba błędów na tej trasie ruszyła się względem godziny wcześniej?
• Czy ruszył się support albo log nieudanych kas?

Potrzebujesz kogoś, kto umie przeczytać te trzy rzeczy. QA nie musi potwierdzać każdego alertu w budynku. Nazwy tras ustal z ludźmi od wykresów przed dniem wydania, nie w jego trakcie.

Zatrzymać albo jechać dalej

Regułę stopu zapisz jednym zdaniem. Przykład: „Jeśli syntetyczna kasa padnie dwa razy albo nieudane płatności na /pay się podwoją, wstrzymaj rollout”. Reguła „użyj osądu” sprawia, że złe wydanie jedzie dalej, podczas gdy ludzie dyskutują.

Wstrzymanie znaczy, że flaga gaśnie albo wraca poprzedni artefakt. QA nie wymyśla tego mechanizmu w dniu wydania. Część 6 tej serii już włożyła flagę i canary do pipeline. Ta część jest decyzją, żeby ich użyć.

Po godzinie

Jeśli wydanie skrzywdziło użytkowników, dodaj jeden test, który padłby przed wdrożeniem. Do kubełka pull requestu, jeśli jest szybki i stabilny. Na noc, jeśli nie jest. Punkt retro „więcej testów” nie jest tym testem.

Jeśli syntetyk padł, bo dane na produkcji mają inny kształt niż na stagingu, popraw dane syntetyka. Nie kasuj go, żeby kanał był cicho.

Podsumowanie

QA po wdrożeniu posiada kilka podróży, pierwszą godzinę ryzykownego wydania i test, który dochodzi, gdy ta godzina idzie źle. Reszta monitoringu produkcji zostaje przy ludziach, którzy mogą ruszyć host, kolejkę albo bazę.

Zadanie na ten tydzień: Nazwij trzy podróże produkcyjne. Oznacz jeden istniejący test @synthetic i skieruj go na bezpieczne konto. Zapisz jednozdaniową regułę stopu obok joba wdrożenia.

---

To kończy serię Jakość w CI/CD.