Wydania

Tuist korzysta z systemu ciągłego wydawania, który automatycznie publikuje nowe wersje za każdym razem, gdy znaczące zmiany zostaną scalone z główną gałęzią. Takie podejście zapewnia, że ulepszenia szybko docierają do użytkowników bez ręcznej interwencji opiekunów.

Przegląd#

Stale wydajemy trzy główne komponenty:

Tuist CLI - Narzędzie wiersza poleceń
Serwer Tuist - Usługi zaplecza
Tuist App - Aplikacje macOS i iOS (aplikacja iOS jest stale wdrażana tylko w TestFlight, zobacz więcej tutaj.

Każdy komponent ma swój własny potok wydań, który działa automatycznie przy każdym wypchnięciu do głównej gałęzi.

Jak to działa#

1. Konwencje zobowiązań#

Używamy Conventional Commits do strukturyzowania naszych komunikatów commit. Pozwala to naszym narzędziom zrozumieć naturę zmian, określić skoki wersji i wygenerować odpowiednie dzienniki zmian.

Format: typ(zakres): opis

Rodzaje zobowiązań i ich wpływ#

Typ	Opis	Wersja Impact	Przykłady
`wyczyn`	Nowa funkcja lub możliwość	Drobna zmiana wersji (x.Y.z)	`feat(cli): dodanie wsparcia dla Swift 6`
`poprawka`	Poprawka błędu	Uderzenie wersji poprawki (x.y.Z)	`fix(app): usunięcie awarii podczas otwierania projektów`
`dokumenty`	Zmiany w dokumentacji	Brak wydania	`dokumenty: instrukcja instalacji aktualizacji`
`styl`	Zmiany w stylu kodu	Brak wydania	`style: formatowanie kodu za pomocą swiftformat`
`refaktoryzacja`	Refaktoryzacja kodu	Brak wydania	`refactor(server): uproszczenie logiki autoryzacji`
`perf`	Ulepszenia wydajności	Ulepszenie wersji łatki	`perf(cli): optymalizacja rozdzielczości zależności`
`test`	Dodatki/zmiany testowe	Brak wydania	`test: dodanie testów jednostkowych dla pamięci podręcznej`
`chore`	Zadania konserwacyjne	Brak wydania	`chore: aktualizacja zależności`
`ci`	Zmiany CI/CD	Brak wydania	`ci: dodanie przepływu pracy dla wydań`

Przełomowe zmiany#

Zmiany przełomowe powodują zwiększenie wersji (X.0.0) i powinny być wskazane w treści zatwierdzenia:

plaintext

feat(cli): change default cache location

BREAKING CHANGE: The cache is now stored in ~/.tuist/cache instead of .tuist-cache.
Users will need to clear their old cache directory.

2. Wykrywanie zmian#

Każdy komponent używa git cliff do:

Analiza zatwierdzeń od ostatniego wydania
Filtrowanie zatwierdzeń według zakresu (cli, aplikacja, serwer)
Określenie, czy istnieją zmiany, które można zwolnić
Automatyczne generowanie dzienników zmian

3. Rurociąg zwalniający#

Po wykryciu zmian, które można zwolnić:

Obliczanie wersji: Potok określa następny numer wersji
Generowanie dziennika zmian: git cliff tworzy dziennik zmian z wiadomości o zatwierdzeniu
Proces kompilacji: Komponent jest budowany i testowany
Tworzenie wydania: Wydanie GitHub jest tworzone z artefaktami
Dystrybucja: Aktualizacje są przekazywane do menedżerów pakietów (np. Homebrew dla CLI).

4. Filtrowanie zakresu#

Każdy komponent jest wydawany tylko wtedy, gdy wprowadzi odpowiednie zmiany:

CLI: zatwierdzenia z zakresem (cli) lub bez zakresu
Aplikacja: Zatwierdzenia z zakresem (aplikacja)
Serwer: Zatwierdzenia z zakresem (serwer)

Pisanie dobrych wiadomości commit#

Ponieważ komunikaty o zatwierdzeniach mają bezpośredni wpływ na informacje o wydaniu, ważne jest, aby pisać jasne, opisowe komunikaty:

Do:#

Używaj czasu teraźniejszego: "dodaj funkcję", a nie "dodano funkcję".
Bądź zwięzły, ale opisowy
Uwzględnienie zakresu, gdy zmiany są specyficzne dla komponentów
Zagadnienia referencyjne, jeśli mają zastosowanie: fix(cli): rozwiązanie problemu z pamięcią podręczną kompilacji (#1234)

Nie rób tego:#

Używaj niejasnych komunikatów, takich jak "napraw błąd" lub "zaktualizuj kod".
Łączenie wielu niepowiązanych zmian w jednym zatwierdzeniu
Zapomnij dołączyć informacje o zmianach awaryjnych

Przełomowe zmiany#

W przypadku zmian przełomowych należy dołączyć BREAKING CHANGE: w treści zatwierdzenia:

plaintext

feat(cli): change cache directory structure

BREAKING CHANGE: Cache files are now stored in a new directory structure.
Users need to clear their cache after updating.

Przepływy pracy wydania#

Przepływy pracy wydania są zdefiniowane w:

.github/workflows/cli-release.yml - wydania CLI
.github/workflows/app-release.yml - Wydania aplikacji
.github/workflows/server-release.yml - Wydania serwera

Każdy przepływ pracy:

Działa po naciśnięciu przycisku głównego
Może być wyzwalany ręcznie
Używa git cliff do wykrywania zmian
Obsługuje cały proces wydania

Monitorowanie wydań#

Możesz monitorować wydania poprzez:

strona GitHub Releases.
Karta GitHub Actions dla przepływów pracy
Pliki dziennika zmian w każdym katalogu komponentów

Korzyści#

Podejście ciągłego wydawania zapewnia:

Szybka dostawa: Zmiany docierają do użytkowników natychmiast po scaleniu
Redukcja wąskich gardeł: Brak oczekiwania na ręczne wydania
Przejrzysta komunikacja: Zautomatyzowane dzienniki zmian z wiadomości commit
Spójny proces: Ten sam przepływ wersji dla wszystkich komponentów
Zapewnienie jakości: Wydawane są tylko przetestowane zmiany

Rozwiązywanie problemów#

Jeśli zwolnienie nie powiedzie się:

Sprawdź dzienniki GitHub Actions pod kątem nieudanego przepływu pracy
Upewnij się, że wiadomości commit są zgodne z konwencjonalnym formatem
Sprawdź, czy wszystkie testy zakończyły się pomyślnie
Sprawdź, czy komponent został pomyślnie skompilowany

Dla pilnych poprawek, które wymagają natychmiastowego wydania:

Upewnij się, że Twój commit ma jasny zakres
Po scaleniu monitoruj przepływ pracy wydania
W razie potrzeby uruchom zwolnienie ręczne

Wydanie App Store#

Podczas gdy CLI i Server są zgodne z opisanym powyżej procesem ciągłego wydawania, aplikacja iOS jest wyjątkiem ze względu na proces weryfikacji App Store firmy Apple:

Ręczne wersje: Wersje aplikacji iOS wymagają ręcznego przesłania do App Store.
Opóźnienia w przeglądzie: Każda wersja musi przejść przez proces weryfikacji Apple, który może potrwać od 1 do 7 dni.
Zmiany zbiorcze: Wiele zmian jest zazwyczaj łączonych w każdym wydaniu iOS.
TestFlight: Wersje beta mogą być dystrybuowane za pośrednictwem TestFlight przed wydaniem w App Store.
Informacje o wersji: Musi być napisana specjalnie dla wytycznych App Store

Aplikacja na iOS nadal przestrzega tych samych konwencji zatwierdzania i używa git cliff do generowania dziennika zmian, ale faktyczne wydanie dla użytkowników odbywa się w rzadszym, ręcznym harmonogramie.