Polityka Zarządzania Zmianami

ISMS Copilot utrzymuje formalną politykę zarządzania zmianami, aby zapewnić, że wszystkie zmiany w naszych systemach produkcyjnych są przeglądane, testowane i wdrażane w sposób bezpieczny. Nasz proces równoważy wymagania bezpieczeństwa i zgodności z potrzebą szybkiego wprowadzania iteracji.

Nasza polityka zarządzania zmianami jest zintegrowana bezpośrednio z naszym przepływem pracy w GitHub oraz potokiem CI/CD w celu automatycznego egzekwowania zasad.

Rodzaje zmian

Kategoryzujemy zmiany na trzy typy w oparciu o ryzyko i wpływ:

Zmiany standardowe — Zmiany o niskim ryzyku, wcześniej zatwierdzone, takie jak aktualizacje dokumentacji, łatki zależności oraz rutynowe aktualizacje konfiguracji. Mogą być automatycznie scalane po przejściu automatycznych kontroli.
Zmiany normalne — Dodawanie funkcji, modyfikacje schematu bazy danych, zmiany API oraz aktualizacje bezpieczeństwa. Wymagają pełnego procesu przeglądu z co najmniej jednym zatwierdzeniem przed wdrożeniem.
Zmiany awaryjne — Krytyczne luki w zabezpieczeniach, przerwy w działaniu usług lub problemy z integralnością danych. Podlegają przyspieszonemu procesowi zatwierdzania, przy jednoczesnym zachowaniu ścieżki audytu i przeglądu po wdrożeniu.

Proces zatwierdzania zmian

Nasz standardowy proces zmian przebiega według następujących kroków:

Utworzenie zgłoszenia w GitHub — Zgłoszenie zmiany udokumentowane wraz z uzasadnieniem i oceną wpływu
Gałąź i Pull Request — Zmiany w kodzie rozwijane w gałęzi funkcji z opisowym PR
Automatyczne testowanie — Potok CI uruchamia automatyczne testy, w tym testy jednostkowe, testy integracyjne oraz skanowanie bezpieczeństwa
Przegląd koleżeński — Co najmniej jeden członek zespołu dokonuje przeglądu kodu, architektury oraz implikacji bezpieczeństwa
Zatwierdzenie i scalenie — Zatwierdzone zmiany są scalane do gałęzi głównej
Automatyczne wdrożenie — Zmiany są automatycznie wdrażane do produkcji za pośrednictwem naszego potoku CI/CD (Supabase, Fly.io, Vercel)

Zmiany awaryjne podlegają przyspieszonej ścieżce, ale nadal wymagają zachowania ścieżki audytu oraz przeglądu po wdrożeniu w ciągu 24 godzin.

Testowanie i bramy jakości

Przed dotarciem jakiejkolwiek zmiany do produkcji, nasz zautomatyzowany potok CI wymusza:

Uruchomienie automatycznego zestawu testów
Walidację migracji bazy danych w środowisku CI Supabase
Statyczną analizę kodu i skanowanie bezpieczeństwa
Weryfikację budowania dla wszystkich celów wdrożenia

Procedury wycofywania i odzyskiwania

Nasza polityka zarządzania zmianami obejmuje procedury wycofywania w przypadku nieudanych wdrożeń. Utrzymujemy możliwość szybkiego cofnięcia zmian, zachowując integralność danych i dostępność systemu.

Wszystkie zmiany są śledzone w GitHub z pełną historią audytu, w tym zatwierdzającymi, znacznikami czasu oraz uzasadnieniem zmian.

Zarządzanie sekretami i konfiguracją

Zmiany dotyczące sekretów, kluczy API lub wrażliwej konfiguracji podlegają dodatkowym kontrolom bezpieczeństwa, wykraczającym poza standardowe procedury zmian, aby zapobiec ujawnieniu poświadczeń.