Wydania i podpisywanie

Każde wydanie wycinasz z main. Tytuł PR-a w konwencji conventional-commit decyduje o kolejnej wersji, a jeden workflow buduje, podpisuje i publikuje binarki dla macOS i Windows, gdy tylko ta wersja zostanie ustalona.

Branching i PR wydania

Pracujesz na dev i scalasz do main przez PR. Gdy tytuł PR-a jest zgodny z konwencją feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert, release-please czyta historię commitów na main i otwiera lub aktualizuje PR wydania z kolejną wersją i changelogiem. Scalasz ten PR, a on tworzy szkic GitHub Release wraz z tagiem. Commity chore nie podnoszą wersji, więc żeby wyciąć wydanie, trzeba poprawnie używać pozostałych typów commitów.

Przy hotfiksie pomijasz normalny przepływ:

1. Utwórz branch hotfix/<opis> z main.
2. Wprowadź tylko jeden commit fix(scope): ....
3. Scal go. Dzięki temu release-please otworzy PR podnoszący wersję patch.
4. Przenieś fix z powrotem do dev przez cherry-pick.

Po opublikowaniu wydania dev jest resetowany do stanu main, żeby oba branche się nie rozjeżdżały.

Od tagu do opublikowanych binarek

Gdy scalisz PR wydania, uruchamia to workflow wydania aplikacji desktopowej, opisany w całości na stronie CI/CD. Buduje on aplikację dla macOS Apple Silicon, macOS Intel i Windows, kompiluje krzyżowo CLI dla trzech platform docelowych, podpisuje pliki wyjściowe aktualizatora Tauri i wysyła każdy element do szkicu wydania. Skrypt weryfikacyjny sprawdza potem, czy szkic zawiera pełny oczekiwany zestaw podpisanych i niepodpisanych elementów, zanim przełączy go w żywe wydanie.

Aktualizacje trafiają do użytkowników jednym stabilnym kanałem, udostępnianym przez GitHub Releases. Mechanizm aktualizacji porównuje wersje i przesuwa użytkowników wyłącznie do przodu: nie ma API do cofania wersji.

Podpisywanie kodu i autentyczność binarek

Każdy plik Mach-O dołączony do aplikacji macOS, w tym CLI, Node.js i helpery napisane w Swifcie, podpisujesz osobno certyfikatem Developer ID Application, z Hardened Runtime i bezpiecznym znacznikiem czasu, a potem zlecasz notaryzację całej paczki w Apple, zanim trafi do użytkowników. Podpisy aktualizatora Tauri używają osobnego klucza Ed25519. Strona Autentyczność binarek tłumaczy, przed czym chroni każda z tych warstw i dlaczego to właśnie certyfikat Developer ID chronisz najbardziej.

Podpisywania kodu dla Windows jeszcze nie wdrożyłeś. Zamiast lokalnego pliku certyfikatu użyjesz Azure Artifact Signing (podpisywania w chmurze opartego na HSM), gdy to rozwiązanie wejdzie w życie.

Konfiguracja certyfikatu podpisującego i rotacja poświadczeń po wycieku to zadania operacyjne wykraczające poza tę stronę.