Wersjonowanie

Wersjonowanie Design Systemu jest ważnym elementem utrzymania spójności i porządku w projekcie, zwłaszcza gdy z systemu korzysta wiele zespołów i projektów. Właściwe zarządzanie wersjami pomaga śledzić zmiany, zapewnia kompatybilność oraz ułatwia wdrażanie poprawek i nowych funkcji.

Kilka najważniejszych zasad:

Semantyczne wersjonowanie ( semver)

Stosuj zasady semantycznego wersjonowania (major.minor.patch):
- Major (główna wersja): wprowadza zmiany, które mogą być niekompatybilne wstecz (wprowadzanie breaking changes).
- Minor (wersja pomocnicza): dodaje nowe funkcje, które są wstecznie kompatybilne.
- Patch: wprowadza poprawki błędów i optymalizacje, które nie zmieniają funkcjonalności.
Zarządzanie zależnościami

Upewnij się, że każdy projekt korzystający z Design System ma dobrze zdefiniowane wersje zależności w plikach takich jak package.json, co pozwoli uniknąć nieprzewidzianych problemów z kompatybilnością.
Stabilne API komponentów

Staraj się zachować stabilność API komponentów w kolejnych wersjach. Jeśli konieczne są zmiany w komponentach, staraj się dodawać nowe funkcjonalności w sposób, który nie wpływa na dotychczasowe użycie.
Komunikacja zmian

Każda nowa wersja powinna być dokładnie opisana w release notes, aby wszyscy użytkownicy systemu mogli zrozumieć, jakie zmiany zostały wprowadzone, czy są jakieś potencjalne problemy z kompatybilnością oraz co zostało naprawione.
Usuwanie funkcjonalności

Jeśli planujesz usunąć jakieś funkcje lub komponenty, zawsze oznaczaj je jako przestarzałe (deprecated) w poprzedniej wersji, zanim usuniesz je w przyszłej wersji major. Daje to zespołom czas na adaptację i unikanie nagłych problemów.
Automatyzacja wersjonowania

Stosuj narzędzia do automatycznego zarządzania wersjami, takie jak semantic-release lub release-it, które na podstawie commitów i zmian w kodzie mogą automatycznie tworzyć nowe wersje, generować odpowiednie tagi i dokumentację.
Testowanie zgodności

Każda nowa wersja Design Systemu powinna być dokładnie przetestowana pod kątem kompatybilności z istniejącymi aplikacjami. Warto wdrożyć mechanizmy automatycznego testowania, które będą sprawdzały, czy zmiany nie powodują problemów z istniejącym kodem.
Dokumentacja zmian

Oprócz release notes warto prowadzić szczegółową dokumentację zmian (np. CHANGELOG.md), w której opisane są wszystkie nowe funkcje, zmiany w API, usunięte funkcje, poprawki błędów oraz inne istotne informacje.
Tagowanie w systemie kontroli wersji

Każda wersja Design Systemu powinna być oznaczona odpowiednim tagiem w systemie kontroli wersji (Np. v1.2.3 dla wydania 1.2.3), co ułatwi śledzenie zmian, przywracanie poprzednich wersji oraz zarządzanie wersjami w zautomatyzowanych procesach.

🔗 Dodatkowe materiały:

Masz pytania lub uwagi?

Przejdź na Discord