Czy można go wdrożyć? Jaki jest kolejny numer wersji? Jak automatycznie generować notatki do wersji?

Alfa. Beta. Produkcja. Raz dwa — iOS i Android. Plus Codepush. Mogą to być wersje Twojej aplikacji React Native. Chcę podzielić się z wami tym, jak wdrażamy wszystko automatycznie, używając przepływu GIT i „konwencjonalnych zatwierdzeń”. Zainspirowany „wydaniem semantycznym”.

Kiedy wypuścimy te wersje?

  • Wersja alfa. Każda noc. Do testów wewnętrznych. W oparciu o gałąź deweloperską.
  • Wersja beta. Wywoływane przez przejście do gałęzi beta.
  • Wersja produkcyjna. Przesłane do Apple Store i Google Play. Wywoływane przez naciśnięcie do gałęzi głównej.

Wszystkie te wersje są wydawane tylko wtedy, gdy istnieje powód, aby je wypuścić. Jeśli od ostatniej wersji nie było nowego zatwierdzenia, przepływ pracy zostanie anulowany automatycznie.

Jak wygląda nasza wersja?

Używamy słowa semver. Główny. Drobny. Skrawek. Może to być 1.3.4. Kiedy wypuszczamy wersję, tworzymy unikalny tag w GIT. Na przykład android/production/1.3.4/7683 lub ios/alpha/1.5.0/8754.

Dlaczego nie przechowujemy wersji w pakiecie.json 🚫

Gdybyśmy przechowywali wersję w plikupackage.json (co robi wiele osób), nie bylibyśmy w stanie automatycznie zwiększyć wersji. Ponieważ została zmieniona przez CircleCI, CircleCI musiałoby wypchnąć zmianę z powrotem do repozytorium. To spowodowałoby wydanie nowego wydania. Ponieważ każde pchnięcie powoduje zwolnienie. Nie mówiąc o tym, ile Bump version zatwierdzeń mielibyśmy w historii GIT.

Jak to działa z wydaniem produkcyjnym?

W tym przykładzie przekazujemy do gałęzi master i oczekujemy, że do sklepów zostanie przesłana aplikacja na Androida i iOS. Będziemy symulować awarię kompilacji iOS.

Naciśnij do Mistrza nr 1

Gałąź główna została „przyspieszona” (scalona) z zatwierdzenia A do zatwierdzenia D. Ostatnia wersja obu wersji znajduje się w momencie zatwierdzenia A (zobacz tagi).

Został uruchomiony przepływ pracy wydania. Pierwszy krok. Zainstaluj zależności. Nie ma sprawy. Tworzy tylko folder modułów węzłów. Drugi krok. Kontrola jakości kodu. Żart. Szarpie. Przepływ. Jeśli któryś z nich zakończy się błędem, cały przepływ pracy zostanie anulowany.

Po tym kroku nasz przepływ pracy jest podzielony na gałąź Android i gałąź iOS. I w tym momencie analiza zatwierdzeń odgrywa dużą rolę w przepływie pracy.

Android
Nasz skrypt (Analiza Androida) znajduje ostatni tag dla android/production (po prostu za pomocą narzędzia wiersza poleceń git). Znacznik znajduje się w zatwierdzeniu A. Pobiera ostatnią wersję poprzez analizę nazwy znacznika. Jest 1.3.4. Następnie, analizując zatwierdzenia, znajduje numer kolejnej wersji.

  • Zatwierdź B. Funkcja (słowo kluczowe feat). Oznacza to, że musimy zwiększyć mniejszą liczbę 1.4.0. Jeśli zwiększysz numer pomocniczy, musisz zresetować numer poprawki (patrz dokumentacja semver).
  • Zatwierdź C. Napraw (słowo kluczowe fix). Zwiększa numer poprawki 1.4.1.
  • Zatwierdź D. To tylko aktualizacja dokumentacji (słowo kluczowe doc). Numer wersji nie uległ zmianie.

Otóż ​​to. Mamy kolejny numer wersji. Żadnych ręcznych działań! Następna wersja 1.4.1 jest wyższa niż bieżąca wersja 1.3.4. Wydanie trwa. Zdecydowano automatycznie. Możemy przekazać numer do Fastlane i stworzyć wydanie. Gdy kompilacja jest już gotowa, można ją kontynuować, wdrażając wersję w sklepie. Po wdrożeniu tworzy nowy tag w HEAD (zatwierdzenie D) i generuje informacje o wersji. Koniec z Androidem!

iOS
Nasz skrypt (etap analizy iOS) znajduje ostatni tag dla ios/production. Kontynuuje w taki sam sposób, jak część na Androida. Otrzymuje numer kolejnej wersji 1.4.1 i kontynuuje tworzenie i wdrażanie kroków.

Aby było to trochę skomplikowane, powiedzmy, że kompilacja wydania iOS nie powiodła się. Ponieważ nasze narzędzie do kompilacji jest źle skonfigurowane.

Co powinniśmy teraz zrobić? Android jest już wydany. Jeśli coś zmienimy i przekażemy do wzorca, ponownie wypuścimy Androida. Możemy poczekać na CircleCI i ręcznie anulować zadanie. 🤔 Na szczęście nie musimy. Zobaczmy dlaczego.

Naciśnij, aby opanować #2

Naprawiliśmy problem, który powodował, że nasza aplikacja na iOS nie została wydana. Teraz przesłaliśmy poprawkę do mistrza. Spowoduje to ponowne uruchomienie przepływu pracy wdrażania. Ale dzięki naszym skryptom przepływ pracy będzie tym razem inny.

Android
Od ostatniej wersji produkcyjnej Androida (1.4.1) dokonano tylko jednego zatwierdzenia. I to właśnie uległo zmianie od ostatniej wersji. Ponieważ Android został pomyślnie wydany (Push to master #1). Nowe zatwierdzenie E nie zwiększy numeru wersji. Ponieważ jest to po prostu aktualizacja narzędzi budowlanych. Przepływ pracy w systemie Android kończy się na etapie analizy systemu Android.

iOS
Sytuacja będzie taka sama jak podczas push to master #1. Jest tylko jedno zatwierdzenie więcej. Ale to zatwierdzenie nie zmienia wersji. Ostatnia wersja wersji iOS to 1.3.4 w dniu zatwierdzenia A. Analizuje zatwierdzenia i dowiaduje się, że nowa wersja będzie miała numer 1.4.1. Kontynuuje budowanie, wdrażanie i tym razem zakończy się sukcesem. 🎉

Mimo że ponownie przeszliśmy do wersji wzorcowej, wersja na Androida nie została ponownie wydana. Nie musieliśmy niczego anulować ręcznie. Wszystko działa automatycznie. Po prostu analizując zatwierdzenia.

Informacje o wydaniu

Może nawet generować informacje o wersji na podstawie analizy zatwierdzeń. Oto nasza historia GIT po przejściu na poziom master nr 2.

Informacje o wydaniu dla iOS obejmują zatwierdzenie B jako nową funkcję i zatwierdzenieC jako poprawkę (łatkę). Pominie zatwierdzenie C i zatwierdzenie D, ponieważ nie zmieniają one niczego dla użytkowników.

Przyjazny dla Codepush? 👍

Prawdopodobnie słyszałeś już o codepush. Narzędzie, które daje nam możliwość wydania tylko części JavaScript. Użytkownicy natychmiast otrzymają aktualizacje. Dobry pomysł. Ale w prawdziwym świecie, kiedy przygotowywaliśmy wydanie, zawsze było trudno wiedzieć, czy możemy wydać tylko JavaScript, czy nie. Zawsze były wątpliwości. I coś ekstra, czego potrzebowaliśmy przy każdym wydaniu.

Teraz mamy to narzędzie do zwalniania. Analizuje za nas zobowiązania. Nasi programiści muszą jedynie zaznaczyć zatwierdzenie, nad którym pracują. Powiedzmy, że napiszą słowo kluczowe do wiadomości zatwierdzenia. Na przykład [codepush-ok].

Następnie robi się dokładnie tak samo jak przy wgraniu do sklepów. Znajduje ostatni znacznik wydania codepush. Analizuj zatwierdzenia od tego wydania. Jeśli istnieje jedno zatwierdzenie, które nie jest oznaczone jako [codepush-ok], wdrożenie zostanie anulowane. Jeśli wszystkie zatwierdzenia zostaną oznaczone [codepush-ok], możemy wypuścić wersję codepush. Czy to nie jest łatwe?

Jak udostępniać aplikacje React Native?

Będzie mi miło, jeśli zostawisz komentarz i zdradzisz mi swój sekret dotyczący wydania. Jak radzisz sobie z wersjonowaniem aplikacji React Native? Nadal robisz to ręcznie? Czy używasz package.json?

📝 Przeczytaj tę historię później w Dzienniku.

🗞 Obudź się w każdą niedzielę rano, a w Twojej skrzynce odbiorczej pojawią się najważniejsze historie techniczne, opinie i aktualności z tego tygodnia: Otrzymuj godny uwagi biuletyn ›