Udostępnij za pośrednictwem

Zwalnianie aktualizacji CodePush przy użyciu interfejsu wiersza polecenia centrum aplikacji

  • Artykuł

Ważne

Program Visual Studio App Center ma zostać wycofany 31 marca 2025 r. Mimo że możesz nadal używać programu Visual Studio App Center do momentu jej pełnego wycofania, istnieje kilka zalecanych alternatyw, do których można rozważyć migrację.

Dowiedz się więcej o osiach czasu pomocy technicznej i alternatywach.

Instalacja

  • Instalowanie Node.js
  • Zainstaluj interfejs wiersza polecenia centrum aplikacji: npm install -g appcenter-cli

Getting Started

  1. Utwórz konto centrum aplikacji lub zaloguj się za pomocą interfejsu appcenter login wiersza polecenia przy użyciu polecenia .
  2. Zarejestruj aplikację przy użyciu narzędzia CodePush i opcjonalnie udostępnij aplikację innym deweloperom w zespole.
  3. CodePush-ify twoja aplikacja i wskaż ją we wdrożeniu, którego chcesz użyć (Apache Cordova i React Native).
  4. Wydawanie i aktualizowanie aplikacji.

Zarządzanie kontem

Przed rozpoczęciem wydawania aktualizacji aplikacji zaloguj się przy użyciu istniejącego konta CodePush lub utwórz nowe konto centrum aplikacji. Możesz to zrobić, uruchamiając następujące polecenie po zainstalowaniu interfejsu wiersza polecenia:

appcenter login

To polecenie spowoduje uruchomienie przeglądarki z prośbą o uwierzytelnienie przy użyciu konta GitHub lub Microsoft. Po uwierzytelnieniu utworzy konto CodePush "połączone" z tożsamością usługi GitHub/MSA i wygeneruje klucz dostępu, który można skopiować/wkleić do interfejsu wiersza polecenia, aby się zalogować.

Uwaga

Po zarejestrowaniu użytkownik jest automatycznie zalogowany przy użyciu interfejsu wiersza polecenia, więc dopóki nie wylogujesz się jawnie, nie musisz ponownie logować się z tej samej maszyny.

Authentication

Większość poleceń w interfejsie wiersza polecenia centrum aplikacji wymaga uwierzytelnienia, więc przed rozpoczęciem zarządzania kontem zaloguj się przy użyciu konta GitHub lub konta Microsoft użytego podczas rejestrowania. Można to zrobić, wykonując następujące polecenie:

appcenter login

To polecenie spowoduje uruchomienie okna przeglądarki z prośbą o uwierzytelnienie przy użyciu konta GitHub lub Microsoft. Spowoduje to wygenerowanie klucza dostępu do kopiowania i wklejania do interfejsu wiersza polecenia (zostanie wyświetlony monit o jego podanie). Teraz pomyślnie uwierzytelniono się i można bezpiecznie zamknąć okno przeglądarki.

Za każdym razem, gdy chcesz sprawdzić, czy już się zalogowano, możesz uruchomić następujące polecenie, aby wyświetlić adres e-mail bieżącej sesji uwierzytelniania, nazwę użytkownika i nazwę wyświetlaną:

appcenter profile list

Po zalogowaniu się z interfejsu wiersza polecenia klucz dostępu będzie nadal używany do dysku przez czas trwania sesji, aby nie trzeba było logować się za każdym razem, gdy próbujesz uzyskać dostęp do konta. Aby zakończyć sesję i usunąć ten klucz dostępu, wykonaj następujące polecenie:

appcenter logout

Jeśli zapomnisz wylogować się z komputera, na którym nie chcesz opuszczać uruchomionej sesji (na przykład laptopa znajomego), możesz użyć następujących poleceń, aby wyświetlić listę i usunąć wszystkie bieżące sesje logowania.

appcenter tokens list
appcenter tokens delete <machineName>

Tokeny dostępu

Aby uwierzytelnić się w usłudze CodePush bez uruchamiania przeglądarki lub bez konieczności używania poświadczeń usługi GitHub lub Microsoft (na przykład w środowisku ciągłej integracji), można wykonać następujące polecenie, aby utworzyć "token dostępu" (wraz z nazwą opisującą, co to jest):

appcenter tokens create -d "Azure DevOps Integration"

Klucz będzie wyświetlany tylko raz, więc pamiętaj, aby zapisać go gdzieś w razie potrzeby! Po utworzeniu nowego klucza można określić jego wartość przy użyciu --token flagi login polecenia, która umożliwia użycie uwierzytelniania "headless", w przeciwieństwie do uruchamiania przeglądarki.

appcenter login --token <accessToken>

Podczas logowania przy użyciu tej metody token dostępu nie zostanie automatycznie unieważniony podczas wylogowania i może być używany w przyszłych sesjach, dopóki nie zostanie jawnie usunięty z serwera Centrum aplikacji. Należy jednak wylogować się po zakończeniu sesji, aby usunąć poświadczenia z dysku.

Zarządzanie aplikacjami

Przed wdrożeniem aktualizacji utwórz aplikację w centrum aplikacji przy użyciu następującego polecenia:

appcenter apps create -d <appDisplayName> -o <operatingSystem>  -p <platform>

Jeśli aplikacja jest przeznaczona zarówno dla systemu Android, jak i iOS, zdecydowanie zalecamy utworzenie oddzielnych aplikacji przy użyciu programu CodePush. Jeden dla każdej platformy. Dzięki temu można zarządzać aktualizacjami i wydać je oddzielnie, co w dłuższej perspektywie ma tendencję do uproszczenia. Większość osób sufiksuje nazwę aplikacji z elementami -Android i -iOS. na przykład:

appcenter apps create -d MyApp-Android -o Android -p React-Native
appcenter apps create -d MyApp-iOS -o iOS -p Cordova

Uwaga

Użycie tej samej aplikacji dla systemów Android i iOS może spowodować wyjątki instalacji, ponieważ pakiet aktualizacji CodePush utworzony dla systemu iOS będzie miał inną zawartość niż aktualizacja utworzona dla systemu Android.

Porada

Jedną z ważnych nowych funkcji w interfejsie wiersza polecenia centrum aplikacji jest możliwość ustawienia aplikacji jako bieżącej aplikacji przy użyciu polecenia appcenter apps set-current <ownerName>/<appName>. Ustawiając aplikację jako bieżącą aplikację, nie musisz używać flagi w innych poleceniach interfejsu -a wiersza polecenia. Na przykład polecenie appcenter codepush deployment list -a <ownerName>/<appName> można skrócić do appcenter codepush deployment list momentu ustawienia bieżącej aplikacji. Możesz sprawdzić, która aplikacja jest ustawiona jako bieżąca aplikacja konta przy użyciu polecenia appcenter apps get-current. Ustawienie bieżącej aplikacji sprawia, że wpisywanie większości poleceń interfejsu wiersza polecenia jest krótsze.

W przypadku oryginalnego koduPush aplikacje automatycznie miały dwa wdrożenia (Staging i Production). W centrum aplikacji należy utworzyć je samodzielnie przy użyciu następujących poleceń:

appcenter codepush deployment add -a <ownerName>/<appName> Staging
appcenter codepush deployment add -a <ownerName>/<appName> Production

Po utworzeniu wdrożeń można uzyskać dostęp do kluczy wdrażania dla obu wdrożeń przy użyciu programu appcenter codepush deployment list --displayKeys, za pomocą którego można rozpocząć konfigurowanie klientów mobilnych za pośrednictwem odpowiednich zestawów SDK (szczegóły dotyczące oprogramowania Cordova i React Native).

Jeśli zdecydujesz, że nie lubisz nazwy nadanej aplikacji, możesz zmienić jej nazwę w dowolnym momencie przy użyciu następującego polecenia:

appcenter apps update -n <newName> -a <ownerName>/<appName>

Ostrzeżenie

Zmiana nazwy aplikacji może powodować nieoczekiwane problemy z konfiguracją gałęzi i kompilacjami przez około 48 godzin.

Jeśli w pewnym momencie nie potrzebujesz już aplikacji, możesz usunąć ją z serwera przy użyciu następującego polecenia:

appcenter apps delete -a <ownerName>/<appName>

Należy zachować ostrożność podczas wykonywania tego polecenia, ponieważ wszystkie aplikacje skonfigurowane do korzystania z niego przestaną otrzymywać aktualizacje.

Na koniec, jeśli chcesz wyświetlić listę wszystkich aplikacji zarejestrowanych na serwerze usługi App Center, uruchom następujące polecenie:

appcenter apps list

Współpraca aplikacji

Jeśli będziesz pracować z innymi deweloperami w tej samej aplikacji CodePush, możesz dodać je jako współpracowników przy użyciu portalu Centrum aplikacji, postępując zgodnie z poniższymi instrukcjami:

  1. W portalu Centrum aplikacji wybierz aplikację, dla której chcesz dodać współpracowników
  2. W obszarze nawigacji po lewej stronie kliknij pozycję Ustawienia
  3. Kliknij link Współpracownicy
  4. W menu współpracowników wprowadź adresy e-mail współpracowników, aby je zaprosić.

Ważne

Funkcja Współpracowników w centrum App Center oczekuje, że każdy współpracownik zarejestrował się już w Centrum aplikacji przy użyciu określonego adresu e-mail.

Po dodaniu wszyscy współpracownicy będą natychmiast mieli następujące uprawnienia w udostępnionej aplikacji:

  1. Wyświetlanie aplikacji, jej współpracowników, wdrożeń i historii wersji
  2. Wydawanie aktualizacji do dowolnych wdrożeń aplikacji
  3. Podwyższanie poziomu aktualizacji między dowolnymi wdrożeniami aplikacji
  4. Wycofywanie wszystkich wdrożeń aplikacji
  5. Stosowanie poprawek wszystkich wersji we wszystkich wdrożeniach aplikacji

Współpracownicy nie mogą wykonywać żadnej z następujących czynności:

  1. Zmienianie nazwy lub usuwanie aplikacji
  2. Tworzenie, zmienianie nazwy lub usuwanie nowych wdrożeń w aplikacji
  3. Czyszczenie historii wersji wdrożenia
  4. Dodawanie lub usuwanie współpracowników z aplikacji (*)

Uwaga

Deweloper może usunąć siebie jako współpracownika z aplikacji, która została im udostępniona.

W miarę upływu czasu, jeśli ktoś nie pracuje już nad aplikacją, możesz je również usunąć jako współpracownik, korzystając z tego menu współpracowników w portalu.

Za każdym razem, gdy chcesz wyświetlić listę wszystkich współpracowników, którzy zostali dodani do aplikacji, możesz odwiedzić menu współpracowników w portalu.

Zarządzanie wdrożeniami

Z perspektywy CodePush aplikacja jest nazwanym grupowaniem dla co najmniej jednego "wdrożeń". Chociaż aplikacja reprezentuje koncepcyjną "przestrzeń nazw" lub "zakres" dla wersji aplikacji specyficznej dla platformy (na przykład port aplikacji Foo dla systemu iOS), jej wdrożenia reprezentują rzeczywisty cel wydawania aktualizacji (dla deweloperów) i synchronizowania aktualizacji (dla użytkowników końcowych). Wdrożenia umożliwiają korzystanie z wielu "środowisk" dla każdej aplikacji w locie w danym momencie oraz modelowanie rzeczywistości, którą aplikacje zwykle przenoszą się ze środowiska osobistego dewelopera do środowiska testowego/qa/przejściowego, zanim w końcu przejdą do środowiska produkcyjnego.

Uwaga

Jak widać poniżej, releasepromote polecenia i rollback wymagają zarówno nazwy aplikacji, jak i nazwy wdrożenia, ponieważ jest to kombinacja tych dwóch, które jednoznacznie identyfikują punkt dystrybucji (na przykład chcę opublikować aktualizację mojej aplikacji systemu iOS do moich testerów beta).

Za każdym razem, gdy aplikacja jest zarejestrowana w usłudze CodePush, zalecamy utworzenie następujących wdrożeń: Staging i Production. Dzięki temu można rozpocząć wydawanie aktualizacji w środowisku wewnętrznym, w którym można dokładnie przetestować każdą aktualizację przed wypchnięciem ich do użytkowników końcowych. Ten przepływ pracy ma kluczowe znaczenie dla zapewnienia, że wydania są gotowe do masowego użycia i jest praktyką, która została ustanowiona w Internecie przez długi czas.

Jeśli masz tymczasową i produkcyjną wersję aplikacji wystarczy, aby spełnić Twoje potrzeby, nie musisz robić nic innego. Jeśli jednak chcesz przeprowadzić wdrożenie alfa, deweloperskie itp., możesz je łatwo utworzyć przy użyciu następującego polecenia:

appcenter codepush deployment add -a <ownerName>/<appName> <deploymentName>

Podobnie jak w przypadku aplikacji, można również usunąć wdrożenia i zmienić ich nazwy, używając odpowiednio następujących poleceń:

appcenter codepush deployment remove -a <ownerName>/<appName> <deploymentName>
appcenter codepush deployment rename -a <ownerName>/<appName> <deploymentName> <newDeploymentName>

Za każdym razem, gdy chcesz wyświetlić listę wdrożeń, które zawiera określona aplikacja, możesz uruchomić następujące polecenie:

appcenter codepush deployment list -a <ownerName>/<appName>

Metryki instalacji mają następujące znaczenie:

  • Aktywne — liczba pomyślnych instalacji, które są obecnie uruchomione w tej wersji (jeśli użytkownik otworzył aplikację, zobaczy/uruchomi tę wersję). Ta liczba zmieni się w miarę uaktualniania użytkowników końcowych do i z dala od tej wersji. Ta metryka przedstawia zarówno łączną liczbę aktywnych użytkowników, jak i procent ogólnej grupy odbiorców, która reprezentuje. Dzięki temu można łatwo określić dystrybucję aktualizacji aktualnie uruchomionych przez użytkowników, a także odpowiedzieć na pytania, takie jak "Ilu użytkowników otrzymało moją najnowszą aktualizację?".

  • Suma — całkowita liczba pomyślnych instalacji, które ta aktualizacja otrzymała ogólnie. Ta liczba rośnie tylko w miarę instalowania nowych użytkowników/urządzeń, więc zawsze jest to nadzbiór całkowitej liczby aktywnych. Aktualizacja jest uznawana za pomyślną po notifyApplicationReady wywołaniu metody (lub sync) po jej zainstalowaniu. Między chwilą pobrania aktualizacji i oznaczania jej powodzeniem będzie ona zgłaszana jako "oczekująca" aktualizacja (zobacz poniżej, aby uzyskać szczegółowe informacje).

  • Oczekujące — liczba pobrań tej wersji, ale nie została jeszcze zainstalowana (aplikacja została ponownie uruchomiona, aby zastosować zmiany). Dlatego ta metryka zwiększa się w miarę pobierania aktualizacji i zmniejsza się w miarę instalowania odpowiednich pobranych aktualizacji. Ta metryka dotyczy głównie aktualizacji, które nie są skonfigurowane do natychmiastowej instalacji, i pomaga zapewnić szerszy obraz wdrażania wydania dla aplikacji, które polegają na wznowieniu aplikacji lub ponownym uruchomieniu w celu zastosowania aktualizacji (na przykład chcę wycofać aktualizację i jestem ciekaw, czy ktoś ją jeszcze pobrał). Jeśli aktualizacje zostały skonfigurowane do zainstalowania natychmiast i nadal są wyświetlane oczekujące aktualizacje zgłaszane, prawdopodobnie nie wywołujesz notifyApplicationReady metody (lub sync) podczas uruchamiania aplikacji, czyli metody, która rozpoczyna wysyłanie raportów instalacji i oznacza zainstalowane aktualizacje jako pomyślne.

  • Wycofywanie — liczba przypadków automatycznego wycofania tej wersji na kliencie. W idealnym przypadku ta liczba powinna być równa zero, a w takim przypadku ta metryka nawet nie jest wyświetlana. Jeśli jednak wydano aktualizację zawierającą awarię w ramach procesu instalacji, wtyczka CodePush wycofa użytkownika końcowego z powrotem do poprzedniej wersji i zgłosi ten problem z powrotem do serwera. Dzięki temu użytkownicy końcowi mogą pozostać odblokowani, jeśli wersje są uszkodzone, i widząc tę telemetrię w interfejsie wiersza polecenia, można zidentyfikować błędne wydania i reagować na nie, cofając je na serwerze.

  • Wdrożenie — wskazuje procent użytkowników, którzy kwalifikują się do otrzymania tej aktualizacji. Ta właściwość będzie wyświetlana tylko dla wydań reprezentujących wdrożenie "aktywne", dlatego mają wartość procentową wdrożenia, która jest mniejsza niż 100%. Ponadto, ponieważ wdrożenie może mieć tylko jedno aktywne wdrożenie w danym momencie, ta etykieta będzie obecna tylko w najnowszej wersji w ramach wdrożenia.

  • Wyłączone — wskazuje, czy wersja została oznaczona jako wyłączona, czy nie, i tak jest pobierana przez użytkowników końcowych. Ta właściwość będzie wyświetlana tylko dla wersji, które są wyłączone.

Gdy komórka metryk zgłasza No installs recordedwartość , oznacza to, że serwer nie widział żadnych działań w tej wersji. Może to być spowodowane tym, że wyklucza wersje wtyczek, które obejmowały obsługę telemetrii, lub żaden użytkownik końcowy nie zsynchronizował jeszcze z serwerem CodePush. Po zakończeniu instalacji zaczniesz widzieć metryki wypełnione w interfejsie wiersza polecenia dla wersji.

Zwalnianie Aktualizacje

Po skonfigurowaniu aplikacji do wykonywania zapytań o aktualizacje na serwerze Centrum aplikacji można rozpocząć wydawanie do niej aktualizacji. Aby zapewnić zarówno prostotę, jak i elastyczność, interfejs wiersza polecenia centrum aplikacji zawiera trzy różne polecenia do wydawania aktualizacji:

  1. Ogólne — zwalnia aktualizację serwera Usługi App Center, która została wygenerowana przez zewnętrzne narzędzie lub skrypt kompilacji (na przykład zadanie Gulp, react-native bundle polecenie ). Zapewnia to największą elastyczność w zakresie dopasowywania do istniejących przepływów pracy, ponieważ ściśle zajmuje się krokiem specyficznym dla programu CodePush i pozostawia proces kompilacji specyficznej dla aplikacji.

  2. React Native — używa tej samej funkcjonalności co polecenie wydania ogólnego, ale obsługuje również zadanie generowania zaktualizowanej zawartości aplikacji (pakiet JS i elementy zawartości), zamiast wymagać uruchomienia zarówno react-native bundle polecenia , jak i .appcenter codepush release

  3. Cordova — używa tej samej funkcjonalności co polecenie wydania ogólnego, ale obsługuje również zadanie przygotowania aktualizacji aplikacji do ciebie, zamiast wymagać uruchamiania zarówno cordova prepare (lub phonegap prepare), jak i .appcenter codepush release

Które z tych poleceń, których należy użyć, jest głównie kwestią wymagań lub preferencji. Zalecamy jednak uruchomienie odpowiedniego polecenia specyficznego dla platformy (ponieważ znacznie upraszcza to środowisko), a następnie użyj polecenia ogólnego przeznaczenia release , jeśli/gdy wymagana jest większa kontrola.

Uwaga

Tylko 50 najnowszych wersji we wdrożeniu można odnaleźć i pobrać przez klientów.

Zwalnianie Aktualizacje (ogólne)

appcenter codepush release -a <ownerName>/<appName> -c <updateContentsPath> -t <targetBinaryVersion> -d <deploymentName>

[-t|--target-binary-version <version>]
[-с|--update-contents-path <updateContentsPath>]
[-r|--rollout <rolloutPercentage>]
[--disable-duplicate-release-error]
[-k|--private-key-path <privateKeyPath>]
[-m|--mandatory]
[-x|--disabled]
[--description <description>]
[-d|--deployment-name <deploymentName>]
[-a|--app <ownerName>/<appName>]
[--disable-telemetry]
[-v|--version]

Parametr nazwy aplikacji

Ten parametr określa nazwę aplikacji Centrum aplikacji, dla których jest wydana ta aktualizacja. Jeśli chcesz go wyszukać, możesz uruchomić appcenter apps list polecenie , aby wyświetlić listę aplikacji.

Aktualizuj parametr zawartości

Ten parametr określa lokalizację zaktualizowanego kodu aplikacji i zasobów, które chcesz zwolnić. Można podać jeden plik (na przykład pakiet JS dla aplikacji React Native) lub ścieżkę do katalogu (na przykład /platforms/ios/www folder aplikacji Cordova). Nie musisz spakować wielu plików ani katalogów, aby wdrożyć te zmiany, ponieważ interfejs wiersza polecenia automatycznie je spakuje.

Należy pamiętać, że określona ścieżka odwołuje się do określonej platformy, przygotowanej/dołączonej wersji aplikacji. W poniższej tabeli przedstawiono polecenie, które należy uruchomić przed zwolnieniem, a także lokalizację, do której można później odwołać się przy użyciu parametru updateContentsPath :

Platforma Polecenie Prepare Ścieżka pakietu (względem katalogu głównego projektu)
Cordova (Android) cordova prepare android ./platforms/android/assets/www Katalogu
Cordova (iOS) cordova prepare ios ./platforms/ios/www Katalogu
React Native wo/assets (Android) react-native bundle --platform android --entry-file <entryFile> --bundle-output <bundleOutput> --dev false --bundle-output Wartość opcji.
React Native w/assets (Android) react-native bundle --platform android --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false --assets-dest Wartość opcji, która powinna reprezentować nowo utworzony katalog zawierający zasoby aplikacji i pakiet JS
React Native wo/assets (iOS) react-native bundle --platform ios --entry-file <entryFile> --bundle-output <bundleOutput> --dev false --bundle-output Wartość opcji
React Native w/assets (iOS) react-native bundle --platform ios --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false --assets-dest Wartość opcji, która powinna reprezentować nowo utworzony katalog zawierający zasoby aplikacji i pakiet JS

Docelowy parametr wersji binarnej

Ten parametr określa wersję magazynu/binarną aplikacji, dla której jest udostępniana aktualizacja, tak aby tylko użytkownicy z uruchomioną tą wersją otrzymywali aktualizację, podczas gdy użytkownicy korzystający ze starszej lub nowszej wersji pliku binarnego aplikacji nie będą otrzymywać aktualizacji. Jest to przydatne z następujących powodów:

  1. Jeśli użytkownik korzysta ze starszej wersji binarnej, istnieje możliwość wystąpienia zmian powodujących niezgodność w aktualizacji CodePush, która nie byłaby zgodna z tym, co jest uruchomione.

  2. Jeśli użytkownik korzysta z nowszej wersji binarnej, zakłada się, że to, co jest uruchomione, jest nowsze (i potencjalnie niezgodne) z aktualizacją CodePush.

Jeśli chcesz, aby aktualizacja dotyczyła wielu wersji pliku binarnego sklepu z aplikacjami, umożliwimy również określenie parametru jako wyrażenia zakresu semver. W ten sposób każde urządzenie klienckie z uruchomioną wersją pliku binarnego, które spełnia wyrażenie zakresu (semver.satisfies(version, range) zwraca true), otrzyma aktualizację. Przykłady prawidłowych wyrażeń zakresu semver są następujące:

Wyrażenie zakresu Kto otrzymuje aktualizację
1.2.3 Tylko urządzenia z konkretną wersją 1.2.3 binarną aplikacji
* Każde urządzenie skonfigurowane do korzystania z aktualizacji z aplikacji CodePush
1.2.x Urządzenia z wersją główną 1, wersją pomocniczą 2 i dowolną wersją poprawki aplikacji
1.2.3 - 1.2.7 Urządzenia z dowolną wersją binarną między 1.2.3 (włącznie) i 1.2.7 (włącznie)
>=1.2.3 <1.2.7 Urządzenia z dowolną wersją binarną między 1.2.3 (włącznie) i 1.2.7 (wyłącznie)
1.2 Odpowiednik >=1.2.0 <1.3.0
~1.2.3 Odpowiednik >=1.2.3 <1.3.0
^1.2.3 Odpowiednik >=1.2.3 <2.0.0

Uwaga

Jeśli wyrażenie semver aplikacji rozpoczyna się od specjalnego znaku powłoki lub operatora, takiego jak >, ^lub ** *, polecenie może nie zostać wykonane poprawnie, jeśli nie opakowujesz wartości w cudzysłowie, ponieważ powłoka nie dostarczy odpowiednich wartości do naszego procesu interfejsu wiersza polecenia. Dlatego najlepiej opakowować parametr aplikacji targetBinaryVersion w podwójny cudzysłów podczas wywoływania release polecenia, na przykład appcenter codepush release -a <ownerName>/<appName> updateContents ">1.2.3".

W poniższej tabeli przedstawiono wartość wersji, którą codePush oczekuje, że zakres semver aktualizacji zostanie spełniony dla każdego odpowiedniego typu aplikacji:

Platforma Źródło wersji binarnej
Cordova Atrybut <widget version> w pliku config.xml
React Native (Android) Właściwość android.defaultConfig.versionName w pliku build.gradle projektu
React Native (iOS) Klucz CFBundleShortVersionString w pliku Info.plist
React Native (Windows) Klucz <Identity Version> w pliku Package.appxmanifest

Uwaga

Jeśli w plikach metadanych brakuje wersji poprawki, na przykład 2.0, będzie ona traktowana jako wersja poprawki 0, czyli 2.0 -> 2.0.0.

Parametr nazwy wdrożenia

Ten parametr określa wdrożenie, do którego ma zostać wydana aktualizacja. Domyślnie jest Stagingto wartość , ale gdy wszystko będzie gotowe do wdrożenia w Productionusłudze lub w jednym z własnych wdrożeń niestandardowych, wystarczy jawnie ustawić ten argument.

Porada

Parametr można ustawić przy użyciu polecenia --deployment-name lub -d.

Parametr opisu

Ten parametr zawiera opcjonalny "dziennik zmian" dla wdrożenia. Wartość jest zaokrąglona do klienta, aby po wykryciu aktualizacji aplikacja mogła ją wyświetlić użytkownikowi końcowemu (na przykład za pomocą okna dialogowego "Co nowego?" . Ten ciąg akceptuje znaki sterujące, takie jak \n i \t , aby można było uwzględnić formatowanie białych znaków w opisach w celu zwiększenia czytelności.

Porada

Ten parametr można ustawić przy użyciu polecenia --description.

Wyłączony parametr

Ten parametr określa, czy aktualizacja powinna być pobierana przez użytkowników końcowych, czy nie. Jeśli aktualizacja nie zostanie określona, nie zostanie wyłączona. Zamiast tego użytkownicy będą pobierać go w momencie, gdy aplikacja wywołuje metodę sync. Ten parametr może być cenny, jeśli chcesz opublikować aktualizację, która nie jest natychmiast dostępna, dopóki nie zostanie jawnie poprawiona i chcesz, aby użytkownicy końcowi mogli go pobrać (na przykład wpis w blogu anonsu poszedł na żywo).

Porada

Ten parametr można ustawić przy użyciu polecenia --disabled lub -x.

Obowiązkowy parametr

Ten parametr określa, czy aktualizacja powinna być uznawana za obowiązkową, czy nie (na przykład zawiera krytyczną poprawkę zabezpieczeń). Ten atrybut jest zaokrąglony do klienta, który może zdecydować, czy i jak chce go wymusić.

Uwaga

Ten parametr jest "flagą", więc jego brak wskazuje, że wydanie jest opcjonalne, a jego obecność wskazuje, że jest obowiązkowy. Można podać dla niego wartość (na przykład --mandatory true), jednak określenie jest wystarczające do oznaczania --mandatory wydania jako obowiązkowe.

Obowiązkowy atrybut jest unikatowy, ponieważ serwer będzie dynamicznie modyfikował go w taki sposób, aby upewnić się, że semantyka wydań aplikacji jest utrzymywana dla użytkowników końcowych. Załóżmy na przykład, że wydano następujące trzy aktualizacje aplikacji:

Release Obowiązkowe?
v1 Nie
v2 Tak
v3 Nie

Jeśli użytkownik końcowy jest obecnie uruchomiony v1, a oni wysyłają zapytanie do serwera o aktualizację, odpowie ( v3 ponieważ jest to najnowsze), ale będzie dynamicznie konwertować wydanie na obowiązkowe, ponieważ obowiązkowa aktualizacja została wydana między. To zachowanie jest ważne, ponieważ kod zawarty w pliku v3 jest przyrostowy dla tego, który znajduje się w v2pliku . Cokolwiek się obowiązkowe v2 nadal v3 obowiązkowe dla każdego, kto jeszcze nie nabył v2.

Jeśli użytkownik końcowy jest obecnie uruchomiony v2i wysyła zapytanie do serwera o aktualizację, odpowie za pomocą polecenia v3, ale pozostaw wydanie jako opcjonalne. Dzieje się tak dlatego, że otrzymali już obowiązkową aktualizację, dlatego nie ma potrzeby modyfikowania zasad programu v3. Dlatego mówimy, że serwer będzie "dynamicznie konwertować" obowiązkową flagę, ponieważ jeśli chodzi o wydanie, jego obowiązkowy atrybut będzie zawsze przechowywany przy użyciu wartości określonej podczas jego wydawania. Jest on zmieniany tylko w razie potrzeby podczas odpowiadania na sprawdzanie aktualizacji od użytkownika końcowego.

Opisane zachowanie ma zastosowanie tylko w przypadku wydania aktualizacji oznaczonej jako mandatory. Serwer zmieni optional wydanie na tylko mandatory wtedy, gdy istnieją międzyoperacyjne mandatory aktualizacje, jak pokazano powyżej.

Wydanie oznaczone jako mandatory nigdy nie zostanie przekonwertowane na optional.

Porada

Ten parametr można ustawić przy użyciu polecenia --mandatory lub -m*

Brak zduplikowanego parametru błędu wydania

Ten parametr określa, że jeśli aktualizacja jest identyczna z najnowszą wersją wdrożenia, interfejs wiersza polecenia powinien wygenerować ostrzeżenie zamiast błędu. Jest to przydatne w scenariuszach ciągłej integracji, w których oczekuje się, że niewielkie modyfikacje mogą wyzwalać wydania, w których nie zmieniono kodu produkcyjnego.

Parametr wdrożenia

Ważne

Aby ten parametr mógł obowiązywać, użytkownicy końcowi muszą mieć uruchomioną wersję 1.6.0-beta+ (dla cordova) lub 1.9.0-beta+ (dla React Native) wtyczki CodePush. W przypadku wydania aktualizacji, która określa właściwość wprowadzania, żaden użytkownik końcowy z starszą wersją wtyczki Cordova lub React Native nie będzie uprawniony do aktualizacji. Dopóki nie przyjmiesz niezbędnej wersji wtyczki CodePush specyficznej dla platformy (jak wspomniano wcześniej), nie zalecamy ustawienia wartości wdrożenia w wersjach aplikacji, ponieważ nikt go nie otrzyma.

Ten parametr określa procent użytkowników (jako liczbę całkowitą między 1 i 100), które powinny kwalifikować się do otrzymania tej aktualizacji. Może to być przydatne, jeśli chcesz "lot" nowych wydań z częścią odbiorców aplikacji (na przykład 25%), i uzyskać opinię lub watch dla wyjątków lub awarii, zanim udostępnisz ją szeroko dla wszystkich. Jeśli ten parametr nie jest ustawiony, wartość domyślna 100%to . Wystarczy ustawić ją, aby ograniczyć liczbę użytkowników, którzy ją otrzymają.

W przypadku korzystania z funkcji wdrażania należy pamiętać o kilku dodatkowych kwestiach:

  1. Nie można wydać nowej aktualizacji do wdrożenia, którego najnowsza wersja jest "aktywnym" wdrożeniem (jego właściwość wdrożenia ma wartość inną niż null). Wdrożenie musi zostać "ukończone" (ustawienie rollout właściwości na 100) przed udostępnieniem dalszych aktualizacji wdrożenia.

  2. Jeśli wycofasz wdrożenie, którego najnowsza wersja jest "aktywnym" wdrożeniem, wartość wdrożenia zostanie wyczyszczona, skutecznie "dezaktywując" zachowanie wdrożenia

  3. mandatory W przeciwieństwie do pól idescription, gdy podwyższasz poziom wydania z jednego wdrożenia do innego, nie będzie propagowany rollout właściwość, a więc jeśli chcesz, aby nowa wersja (we wdrożeniu docelowym) miała wartość wdrożenia, musisz jawnie ustawić ją podczas wywoływania promote polecenia.

Porada

Ten parametr można ustawić przy użyciu polecenia --rollout lub -r*

Zwalnianie Aktualizacje (React Native)

appcenter codepush release-react -a <ownerName>/<appName> -d <deploymentName> -t <targetBinaryVersion>
[-t|--target-binary-version <targetBinaryVersion>]
[-o|--output-dir]
[-s|--sourcemap-output]
[-c|--build-configuration-name <arg>]
[--plist-file-prefix]
[-p|--plist-file]
[-g|--gradle-file]
[-e|--entry-file]
[--development]
[-b|--bundle-name <bundleName>]
[-r|--rollout <rolloutPercentage>]
[--disable-duplicate-release-error]
[-k|--private-key-path <privateKeyPath>]
[-m|--mandatory]
[-x|--disabled]
[--description <description>]
[-d|--deployment-name <deploymentName>]
[-a|--app <ownerName>/<appName>]
[--disable-telemetry]
[-v|--version]

Polecenie release-react jest React Native specyficzną wersją polecenia "vanilla"release, które obsługuje wszystkie te same parametry (na przykład --mandatory, --description), ale upraszcza proces wydawania aktualizacji, wykonując następujące dodatkowe zadania:

  1. react-native bundle Uruchomienie polecenia w celu wygenerowania zawartości aktualizacji (pakietu JS i zasobów), które zostaną wydane na serwerze CodePush. Używa rozsądnych wartości domyślnych tak bardzo, jak to możliwe (na przykład utworzenie kompilacji innej niż deweloperskie, przy założeniu, że plik wpisu systemu iOS nosi nazwę index.ios.js), ale także uwidacznia odpowiednie react-native bundle parametry w celu zapewnienia elastyczności (na przykład --sourcemap-output).

  2. Wnioskowanie targetBinaryVersion tej wersji przy użyciu nazwy wersji określonej w plikach Info.plist projektu (dla systemu iOS) i build.gradle (dla systemu Android).

Aby zilustrować różnicę, jaką release-react może zrobić polecenie, w poniższym przykładzie pokazano, jak można wygenerować i wydać aktualizację dla aplikacji React Native przy użyciu polecenia "vanilla"release:

mkdir ./CodePush

react-native bundle --platform ios \
--entry-file index.ios.js \
--bundle-output ./CodePush/main.jsbundle \
--assets-dest ./CodePush \
--dev false

appcenter codepush release -a <ownerName>/MyApp-iOS -c ./CodePush -t 1.0.0

Osiągnięcie równoważnego zachowania za release-react pomocą polecenia wymaga następującego polecenia, co jest mniej podatne na błędy:

appcenter codepush release-react -a <ownerName>/MyApp-iOS

Parametr nazwy aplikacji

Jest to ten sam parametr, który został opisany w powyższej sekcji.

Parametr nazwy wdrożenia

Jest to ten sam parametr, który został opisany w powyższej sekcji.

Parametr opisu

Jest to ten sam parametr, który został opisany w powyższej sekcji.

Obowiązkowy parametr

Jest to ten sam parametr, który został opisany w powyższej sekcji.

Brak zduplikowanego parametru błędu wydania

Jest to ten sam parametr, który został opisany w powyższej sekcji.

Parametr wdrożenia

Jest to ten sam parametr, który został opisany w powyższej sekcji. Jeśli wersja nie zostanie określona, zostanie udostępniona wszystkim użytkownikom.

Docelowy parametr wersji binarnej

Jest to ten sam parametr, który został opisany w powyższej sekcji. W przypadku pozostawienia nieokreślonej wartości domyślnej jest określanie dokładnej wersji określonej w plikach Info.plist (dla systemu iOS) i build.gradle (dla systemu Android).

Parametr nazwy pakietu

Ten parametr określa nazwę pliku, która powinna być używana dla wygenerowanego pakietu JS. Jeśli nazwa pakietu nie zostanie określona, zostanie użyta dla określonej platformy: main.jsbundle (iOS), index.android.bundle (Android) i index.windows.bundle (Windows).

Porada

Ten parametr można ustawić przy użyciu polecenia --bundle-name lub -b*

Parametr programowania

Ten parametr określa, czy wygenerować niezaminyfikowany pakiet JS. W przypadku pozostawienia nieokreślonej wartości domyślnej false jest to, gdzie ostrzeżenia są wyłączone, a pakiet jest minyfikowany.

Porada

Ten parametr można ustawić przy użyciu polecenia --development*

Wyłączony parametr

Jest to ten sam parametr, który został opisany w powyższej sekcji.

Parametr pliku wpisu

Ten parametr określa ścieżkę względną do pliku JavaScript katalogu głównego/wpisu aplikacji. W przypadku pozostawienia nieokreślonej wartości domyślnej jest index.ios.js (dla systemu iOS), index.android.js (dla systemu Android) lub index.windows.bundle (dla systemu Windows), jeśli ten plik istnieje lub index.js w inny sposób.

Porada

Ten parametr można ustawić przy użyciu polecenia --entry-file lub -e*

Parametr pliku Gradle (tylko system Android)

Ten parametr określa ścieżkę względną do pliku build.gradle , którego interfejs wiersza polecenia powinien użyć podczas próby autowykrywania docelowej wersji binarnej dla wydania. Ten parametr jest przeznaczony tylko dla zaawansowanych scenariuszy, ponieważ interfejs wiersza polecenia może automatycznie znaleźć plik build.gradle projektu w projektach "standard" React Native. Jeśli jednak plik gradle projektu znajduje się w dowolnej lokalizacji, interfejs wiersza polecenia nie może odnaleźć, a następnie użycie tego parametru umożliwia kontynuowanie wydawania aktualizacji CodePush bez konieczności jawnego ustawiania parametru --target-binary-version . Ponieważ build.gradle jest wymaganą nazwą pliku, określenie ścieżki do folderu zawierającego lub pełnej ścieżki do samego pliku spowoduje osiągnięcie tego samego efektu.

appcenter codepush release-react -a <ownerName>/MyApp-Android  -g "./foo/bar/"
appcenter codepush release-react -a <ownerName>/MyApp-Android  -g "./foo/bar/build.gradle"

Porada

Ten parametr można ustawić przy użyciu polecenia --gradle-file lub -g*

Parametr pliku Plist (tylko system iOS)

Ten parametr określa ścieżkę względną do pliku Info.plist , którego interfejs wiersza polecenia powinien użyć podczas próby autowykrywania docelowej wersji binarnej dla wydania. Ten parametr jest przeznaczony tylko dla zaawansowanych scenariuszy, ponieważ interfejs wiersza polecenia może automatycznie znaleźć plik Info.plist projektu w projektach "standard" React Native i można użyć parametru --plistFilePrefix do obsługi plików plist środowiska (na przykład STAGING-Info.plist). Jeśli jednak plik plist projektu znajduje się w dowolnej lokalizacji, nie można odnaleźć interfejsu wiersza polecenia, użycie tego parametru umożliwia kontynuowanie wydawania aktualizacji CodePush bez konieczności jawnego ustawiania parametru --target-binary-version .

appcenter codepush release-react -a <ownerName>/MyApp-iOS -p "./foo/bar/MyFile.plist"

Porada

Ten parametr można ustawić przy użyciu polecenia --plist-file lub -p*

Parametr prefiksu pliku Plist (tylko system iOS)

Ten parametr określa prefiks nazwy pliku Info.plist , którego interfejs wiersza polecenia powinien używać podczas próby autowykrywania docelowej wersji binarnej dla wydania. Może to być przydatne, jeśli utworzono pliki plist dla środowiska (na przykład DEV-Info.plist, STAGING-Info.plist) i chcesz wydać aktualizacje CodePush bez konieczności jawnego ustawiania parametru --target-binary-version . Określając --plist-file-prefixelement , interfejs wiersza polecenia będzie szukać pliku o nazwie <prefix>-Info.plist, zamiast pliku Info.plist (co jest zachowaniem domyślnym), w następujących lokalizacjach: ./ios i ./ios/<appName>. Jeśli plik plist projektu nie znajduje się w jednym z tych katalogów (na przykład aplikacja jest natywną aplikacją systemu iOS z osadzonymi widokamirn) lub używa zupełnie innej konwencji nazewnictwa plików, rozważ użycie parametru --plist-file .

# Autodetect the target binary version of this release by looking up the
# app version within the STAGING-Info.plist file in either the ./ios or ./ios/<APP> directories.
appcenter codepush release-react -a <ownerName>/MyApp-iOS  --plist-file-prefix "STAGING"

# Tell the CLI to use your dev plist (`DEV-Info.plist`).
# The hyphen separator can be explicitly stated.
appcenter codepush release-react -a <ownerName>/MyApp-iOS --plist-file-prefix "DEV-"

Parametr wyjściowy mapy źródłowej

Ten parametr określa ścieżkę względną do miejsca, w którym powinien zostać zapisany plik mapy źródłowej pakietu JS. Jeśli nie zostanie określona, mapy źródłowe nie zostaną wygenerowane.

Porada

Ten parametr można ustawić przy użyciu polecenia --sourcemap-output lub -s*

Nazwa konfiguracji kompilacji

Nazwa konfiguracji kompilacji, która określa wersję binarną, na której ma być docelowa ta wersja. Na przykład "Debuguj" lub "Wydanie" (tylko system iOS).

Uwaga

Ten parametr powinien być używany podczas kompilowania z programem Xcode 11 lub nowszym, aby zastąpić domyślną konfigurację używaną przez program Xcode.

Zwalnianie Aktualizacje (Cordova)

appcenter codepush release-cordova -a <ownerName>/<appName> -d <deploymentName> -t <targetBinaryVersion>
[-t|--target-binary-version <targetBinaryVersion>]
[--is-release-build-type]
[-b|--build]
[-r|--rollout <rolloutPercentage>]
[--disable-duplicate-release-error]
[-k|--private-key-path <privateKeyPath>]
[-m|--mandatory]
[-x|--disabled]
[--description <description>]
[-d|--deployment-name <deploymentName>]
[-a|--app <ownerName>/<appName>]
[--disable-telemetry]
[-v|--version]

Polecenie release-cordova to specyficzna dla oprogramowania Cordova wersja polecenia "vanilla" release , która obsługuje wszystkie te same parametry (na przykład --mandatory, --description), ale upraszcza proces wydawania aktualizacji, wykonując następujące dodatkowe zadania:

  1. cordova prepare Uruchomienie polecenia (lub phonegap prepare) w celu wygenerowania zawartości aktualizacji (folderu www), która zostanie wydana na serwerze CodePush.

  2. Wnioskowanie targetBinaryVersion tej wersji przy użyciu nazwy wersji określonej w pliku config.xml projektu.

Aby zilustrować różnicę, jaką release-cordova może wykonać polecenie, w poniższym przykładzie pokazano, jak można wygenerować i wydać aktualizację aplikacji Cordova przy użyciu polecenia "vanilla" release :

cordova prepare ios
appcenter codepush release -a <ownerName>/MyApp-iOS -c ./platforms/ios/www -t 1.0.0

Osiągnięcie równoważnego zachowania za release-cordova pomocą polecenia wymaga następującego polecenia, co jest mniej podatne na błędy:

appcenter codepush release-cordova -a <ownerName>/MyApp-iOS

Parametr nazwy aplikacji

Jest to ten sam parametr, co parametr opisany w powyższej sekcji.

Parametr nazwy wdrożenia

Jest to ten sam parametr, co parametr opisany w powyższej sekcji.

Parametr opisu

Jest to ten sam parametr, co parametr opisany w powyższej sekcji.

Obowiązkowy parametr

Jest to ten sam parametr, co parametr opisany w powyższej sekcji.

Brak zduplikowanego parametru błędu wydania

Jest to ten sam parametr, co parametr opisany w powyższej sekcji.

Parametr wdrożenia

Jest to ten sam parametr, co parametr opisany w powyższej sekcji. Jeśli wersja nie zostanie określona, zostanie udostępniona wszystkim użytkownikom.

Docelowy parametr wersji binarnej

Jest to ten sam parametr, co parametr opisany w powyższej sekcji. Jeśli pole pozostanie nieokreślone, polecenie domyślnie określa wartość docelową tylko określoną wersję w metadanych projektu (Info.plist , jeśli ta aktualizacja dotyczy klientów systemu iOS i build.gradle dla klientów z systemem Android).

Wyłączony parametr

Jest to ten sam parametr, co parametr opisany w powyższej sekcji.

Parametr kompilacji

Ten parametr określa, czy chcesz uruchomić cordova build zamiast cordova prepare (co jest zachowaniem domyślnym), podczas generowania zaktualizowanych zasobów internetowych. Jest to przydatne, jeśli projekt zawiera punkty zaczepienia przed kompilacją lub po nim (na przykład w celu transpilowania języka TypeScript), dlatego uruchomienie cordova prepare codePush nie wystarczy do utworzenia i wydania aktualizacji. Jeśli pozostawiono nieokreślony, wartość domyślna to false.

Porada

Ten parametr można ustawić przy użyciu polecenia --build lub -b*

Poprawianie metadanych aktualizacji

Po wydaniu aktualizacji mogą wystąpić scenariusze, w których chcesz zmodyfikować co najmniej jeden atrybut metadanych (na przykład nie pamiętasz oznaczania poprawki krytycznej usterki jako obowiązkowej, chcesz zwiększyć procent wdrożenia aktualizacji). Można to łatwo zrobić, uruchamiając następujące polecenie:

appcenter codepush patch -a <ownerName>/<appName> <deploymentName> <existing-release-label>
[-r|--rollout <rolloutPercentage>]
[-d|--description <description>]
[-t|--target-binary-version <targetBinaryVersion>]
[-a|--app <ownerName>/<appName>]
[--disable-telemetry]
[-v|--version]

Uwaga

To polecenie nie zezwala na modyfikowanie rzeczywistej zawartości aktualizacji wydania (na przykład www folderu aplikacji Cordova). Jeśli chcesz odpowiedzieć na wydanie, które zostało zidentyfikowane jako uszkodzone, należy użyć polecenia wycofywania , aby natychmiast wycofać je, a następnie w razie potrzeby wydać nową aktualizację z odpowiednią poprawką, gdy jest dostępna.

Oprócz parametrów <ownerName>/<appName> i deploymentNamewszystkie parametry są opcjonalne, dlatego można użyć tego polecenia do zaktualizowania pojedynczego atrybutu lub wszystkich z nich jednocześnie. patch Wywołanie polecenia bez określenia żadnej flagi atrybutu spowoduje brak operacji.

# Mark the latest production release as mandatory
appcenter codepush patch -a <ownerName>/MyApp-iOS Production -m

# Increase the rollout for v23 to 50%
appcenter codepush patch -a <ownerName>/MyApp-iOS Production v23 -rollout 50%

Parametr etykiety

Wskazuje, v23która wersja (na przykład ) ma zostać zaktualizowana w ramach określonego wdrożenia. Jeśli pominięto, żądane zmiany zostaną zastosowane do najnowszej wersji w określonym wdrożeniu. Aby wyszukać etykietę wydania, którą chcesz zaktualizować, możesz uruchomić appcenter codepush deployment history polecenie i odwołać się do kolumny Label .

Obowiązkowy parametr

Jest to ten sam parametr co parametr opisany w powyższej sekcji i umożliwia aktualizację, czy wydanie powinno być uznawane za obowiązkowe, czy nie. Zwróć uwagę na to, że --mandatory i --mandatory true są równoważne, ale brak tej flagi nie jest odpowiednikiem --mandatory false. Jeśli parametr zostanie pominięty, żadna zmiana nie zostanie zmieniona na wartość obowiązkowej właściwości wydania docelowego. Ustaw ten parametr na , aby --mandatory false jawnie ustawić wydanie jako opcjonalne.

Parametr opisu

Jest to ten sam parametr, który został opisany w powyższej sekcji, i umożliwia zaktualizowanie opisu wydania (na przykład wpisanie literówki podczas wydawania lub zapomnienie dodania opisu w ogóle). Jeśli ten parametr zostanie pominięty, żadna zmiana nie zostanie zmieniona na wartość właściwości opisu wersji docelowej.

Wyłączony parametr

Jest to ten sam parametr co parametr opisany w powyższej sekcji i umożliwia aktualizowanie, czy wydanie powinno być wyłączone, czy nie. Zwróć uwagę --disabled i --disabled true są równoważne, ale brak tej flagi nie jest odpowiednikiem --disabled false. Jeśli parametr zostanie pominięty, żadna zmiana nie zostanie zmieniona na wartość wyłączonej właściwości wydania docelowego. Ustaw ten parametr na --disabled false , aby jawnie udostępnić wydanie, jeśli zostało ono wcześniej wyłączone.

Parametr wdrożenia

Jest to ten sam parametr co parametr opisany w powyższej sekcji i umożliwia zwiększenie procentu wdrożenia wersji docelowej. Ten parametr można ustawić tylko na liczbę całkowitą, której wartość jest większa niż bieżąca wartość wdrożenia. Ponadto, jeśli chcesz "ukończyć" wdrożenie i udostępnić wydanie wszystkim, możesz ustawić ten parametr na --rollout 100wartość . Jeśli ten parametr zostanie pominięty, żadna zmiana nie zostanie wprowadzonych do wartości parametru wdrożenia wersji docelowej.

Ponadto, jak wspomniano powyżej, po wydaniu aktualizacji bez wartości wdrożenia jest ona traktowana równoważne z ustawieniem wdrożenia na 100wartość . Jeśli aktualizacja została wydana bez wdrożenia, nie można zmienić jej właściwości wdrożenia za pomocą patch polecenia , ponieważ zostanie to uznane za obniżenie wartości procentowej wdrożenia.

Docelowy parametr wersji binarnej

Jest to ten sam parametr co parametr opisany w powyższej sekcji i umożliwia zaktualizowanie zakresu semver , który wskazuje, z którymi wersjami binarnymi jest zgodna wersja. Może to być przydatne w przypadku popełnienia błędu podczas pierwotnego wydania aktualizacji (na przykład określonej 1.0.0 , ale oznaczanej 1.1.0) lub chcesz zwiększyć lub zmniejszyć zakres wersji obsługiwanej przez wydanie (na przykład wykryto, że wydanie nie działa 1.1.2 w końcu). Jeśli ten parametr zostanie pominięty, żadna zmiana nie zostanie zmieniona na wartość właściwości wersji docelowej wydania.

# Add a "max binary version" to an existing release
# by scoping its eligibility to users running >= 1.0.5
appcenter codepush patch -a <ownerName>/MyApp-iOS Staging -t "1.0.0 - 1.0.5"

Promowanie Aktualizacje

Po przetestowaniu aktualizacji dla określonego wdrożenia (na przykład Staging) i chcesz podwyższyć poziom jej "podrzędnego" (na przykład dev-staging>, staging-production>), możesz użyć następującego polecenia, aby skopiować wydanie z jednego wdrożenia do innego:

appcenter codepush promote -a <ownerName>/<appName> -s <sourceDeploymentName> -d <destDeploymentName>
[-s|--source-deployment-name <sourceDeploymentName>]
[-d|--destination-deployment-name <destDeploymentName>]
[-t|--target-binary-version <targetBinaryVersion>] 
[-r|--rollout <rolloutPercentage>]
[--disable-duplicate-release-error]
[--description <description>]
[-a|--app <ownerName>/<appName>] 
[--disable-telemetry]

Polecenie promote tworzy nową wersję wdrożenia docelowego, która zawiera dokładny kod i metadane (opis, obowiązkowy i docelową wersję binarną) z najnowszej wersji wdrożenia źródłowego. Chociaż można użyć release polecenia , aby "ręcznie" migrować aktualizację z jednego środowiska do drugiego, promote polecenie ma następujące korzyści:

  1. Jest to szybsze, ponieważ nie trzeba ponownie usuwać zasobów wydania, które chcesz opublikować lub zapamiętać opis/wersję binarną dla wydania wdrożenia źródłowego.

  2. Jest to mniej podatne na błędy, ponieważ operacja podwyższania poziomu gwarantuje, że dokładnie to, co już przetestowano we wdrożeniu źródłowym (na przykład Staging), stanie się aktywne we wdrożeniu docelowym (na przykład Production).

Zalecamy, aby wszyscy użytkownicy korzystali z automatycznie utworzonych Staging środowisk i Production wykonywać wszystkie wydania bezpośrednio w programie Staging, a następnie promote od Staging do po Production odpowiednim przetestowaniu.

Parametr opisu

Jest to ten sam parametr, który został opisany w powyższej sekcji, i umożliwia zastąpienie opisu, który będzie używany dla promowanej wersji. Jeśli nie zostanie określona, nowa wersja odziedziczy opis z promowanej wersji.

Wyłączony parametr

Jest to ten sam parametr co opisany w powyższej sekcji i umożliwia zastąpienie wartości flagi wyłączonej, która będzie używana dla promowanej wersji. Jeśli nie zostanie określona, nowa wersja odziedziczy właściwość wyłączoną z promowanej wersji.

Obowiązkowy parametr

Jest to ten sam parametr, który został opisany w powyższej sekcji, i umożliwia zastąpienie obowiązkowej flagi, która będzie używana dla promowanej wersji. Jeśli nie zostanie określona, nowa wersja odziedziczy obowiązkową właściwość z promowanej wersji.

Brak zduplikowanego parametru błędu wydania

Jest to ten sam parametr, który został opisany w powyższej sekcji.

Parametr wdrożenia

Jest to ten sam parametr co ten opisany w powyższej sekcji i umożliwia określenie, czy nowo utworzona wersja powinna być udostępniana tylko dla części użytkowników. W przeciwieństwie do innych parametrów metadanych wydania (na przykład description), rollout wydanie nie jest przenoszone/dziedziczone w ramach podwyższania poziomu i dlatego należy jawnie ustawić to, jeśli nie chcesz, aby nowo utworzone wydanie było dostępne dla wszystkich użytkowników.

Docelowy parametr wersji binarnej

Jest to ten sam parametr co opisany w powyższej sekcji i umożliwia zastąpienie docelowej wersji binarnej, która będzie używana dla promowanej wersji. Jeśli nie zostanie określona, nowa wersja odziedziczy docelową właściwość wersji binarnej z promowanej wersji.

# Promote the release to production and make it
# available to all versions using that deployment
appcenter codepush promote -a <ownerName>/MyApp-iOS -s Staging -d Production -t "*"

Wycofywanie Aktualizacje

Historia wydania wdrożenia jest niezmienna, więc nie można usunąć ani usunąć aktualizacji po jej wydaniu. Jeśli jednak wydasz aktualizację, która jest uszkodzona lub zawiera niezamierzone funkcje, łatwo ją wycofać przy użyciu rollback polecenia :

appcenter codepush rollback <ownerName>/<appName> <deploymentName>
appcenter codepush rollback -a <ownerName>/MyApp-iOS Production

Wykonanie tego polecenia powoduje utworzenie nowej wersji wdrożenia, która zawiera dokładnie ten sam kod i metadane co wersja przed najnowszą wersją. Załóżmy na przykład, że wydano następujące aktualizacje aplikacji:

Release Opis Obowiązkowy
v1 Wersja początkowa! Tak
v2 Dodano nową funkcję Nie
v3 Poprawki błędów Tak

Jeśli uruchomisz polecenie w tym wdrożeniu rollback , zostanie utworzone nowe wydanie (v4), które zawiera zawartość v2 wydania.

Release Opis Obowiązkowy
v1 Wersja początkowa! Tak
v2 Dodano nową funkcję Nie
v3 Poprawki błędów Tak
Wersja 4 (wycofywanie z wersji 3 do wersji 2) Dodano nową funkcję Nie

Użytkownicy końcowi, którzy już uzyskali v3 , zostaną "przeniesieni z powrotem" do v2 momentu, gdy aplikacja przeprowadza sprawdzanie aktualizacji. Ponadto wszyscy użytkownicy, którzy nadal korzystali v2z programu , a zatem nigdy nie uzyskali v3aktualizacji, nie otrzymają aktualizacji, ponieważ są one już uruchomione w najnowszej wersji (dlatego nasze sprawdzanie aktualizacji używa skrótu pakietu oprócz etykiety wydania).

Jeśli chcesz wycofać wdrożenie w wersji innej niż poprzednia (na przykład v3 ->v2), możesz określić opcjonalny --target-release parametr:

appcenter codepush rollback -a <ownerName>/MyApp-iOS Production --target-release v34

Uwaga

Wydanie utworzone przez wycofanie zostanie oznaczone adnotacją w danych wyjściowych deployment history polecenia, aby ułatwić ich identyfikację.

Wyświetlanie historii wydania

Historię 50 najnowszych wersji dla konkretnego wdrożenia aplikacji można wyświetlić przy użyciu następującego polecenia:

appcenter codepush deployment history -a <ownerName>/<appName> <deploymentName>

Historia będzie wyświetlać wszystkie atrybuty dotyczące każdej wersji (na przykład etykieta, obowiązkowe), a także wskazuje, czy jakiekolwiek wydania zostały wykonane z powodu promocji lub operacji wycofywania.

Historia wdrażania

Ponadto historia wyświetla metryki instalacji dla każdej wersji. Szczegółowe informacje o interpretacji danych metryk można wyświetlić w dokumentacji powyższego deployment list polecenia.

Czyszczenie historii wersji

Historię wydania wdrożenia można wyczyścić przy użyciu następującego polecenia:

appcenter codepush deployment clear -a <ownerName>/<appName> <deploymentName>

Po uruchomieniu tego polecenia urządzenia klienckie skonfigurowane do odbierania aktualizacji przy użyciu skojarzonego klucza wdrożenia nie będą już otrzymywać aktualizacji, które zostały wyczyszczone. To polecenie jest nieodwracalne i nie powinno być używane we wdrożeniu produkcyjnym.

Podpisywanie kodu

Co to?

Podpisywanie kodu to sposób tworzenia podpisów cyfrowych dla pakietów, które można później zweryfikować po stronie klienta przed instalacją.

Dlaczego tego potrzebujemy?

Deweloperzy chcą wiedzieć, że kod, który wysyła, jest kodem, który napisali. Podpisywanie kodu jest podstawowym mechanizmem zapewniającym taką pewność i może pomóc w ograniczeniu lub wyeliminowaniu całej klasy ataków typu man-in-the-middle.

Jak to działa?

Najpierw deweloper generuje parę kluczy asymetrycznych: klucz prywatny będzie używany do podpisywania pakietów; klucz publiczny do weryfikacji podpisu pakietu. Następnie interfejs wiersza polecenia CodePush używa klucza prywatnego do podpisywania pakietów podczas releasepoleceń release-react i release-cordova . Klucz publiczny jest dostarczany z aplikacją mobilną. Kontrola nad generowaniem i zarządzaniem kluczami jest w rękach dewelopera.

Na końcu polecenia wydania interfejs wiersza polecenia oblicza skrót zawartości pakietu i umieszcza tę wartość w zestawie JWT podpisanym przy użyciu klucza prywatnego. Gdy wtyczka CodePush pobiera pakiet do urządzenia, sprawdza .codepushrelease plik zawierający JWT i weryfikuje podpis JWT przy użyciu klucza publicznego. Jeśli walidacja nie powiedzie się, aktualizacja nie jest zainstalowana.

Wymagania dotyczące korzystania z tej funkcji

Jeśli planujesz użyć tej funkcji, wykonaj następujące kroki:

  1. Tworzenie nowej aktualizacji binarnej, w tym

    • zaktualizowano wtyczkę CodePush obsługującą podpisywanie kodu
    • Skonfiguruj zestaw SDK wypychania kodu do korzystania z klucza publicznego (zapoznaj się z odpowiednimi sekcjami zestawu SDK React Native (iOS, Android) lub Cordova SDK, aby uzyskać szczegółowe informacje)

  2. Utwórz nową aktualizację CodePush, która jest przeznaczona dla nowej wersji binarnej i określa --private-key-path wartość parametru (lub -k)

Zapoznaj się z naszymi tabelami zgodności, aby określić, czy funkcja podpisywania kodu jest obsługiwana w zestawie SDK/interfejsie wiersza polecenia:

CodePush SDK Wersja, z której jest obsługiwana obsługa podpisywania kodu Obsługiwane platformy Wymagana minimalna wersja interfejsu wiersza polecenia codePush
react-native-code-push 5.1.0 Android, iOS 2.1.0
cordova-plugin-code-push 1.10.0 Android, iOS 2.1.2

Generowanie klucza

Podpisywanie kodu obsługuje klucze RSA zakodowane za pomocą protokołu PEM (niecertyfikacyjne) do podpisywania. Można je wygenerować za pośrednictwem pliku openssl, jak pokazano poniżej:

# generate private RSA key and write it to private.pem file
openssl genrsa -out private.pem

# export public key from private.pem into public.pem
openssl rsa -pubout -in private.pem -out public.pem

Przykład wygenerowanych kluczy:

# public key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4moC3GsqF7YISFMQ0fnU
0rUF2xhxNqSGx9/GTxCynsQhR3hceroDXj3rAOTxnNkePB27uZfRDHrH3/LLoj9V
k2ghKRtfjDwXa85uDK8slSQDB9ZlD1TLQEJDZpKr1OTXY9VwbgtFaotSXoFmG3MO
RQeALCbrAgDxQ5Q2kJn6rfBuBoszfUz1qZqrlrY74Axerv1/UtTjL8uyF5r00Bxj
kvTveC2Pm5A3kq6QANktgfKWy9Ugs/4ykZF7fxfH+ukJW+iXwLACrdfzhegg/41H
5w06m30h0jqhIBZ3nbj5MN+qVbANHJMjz+fXqXx1Ovr1DfGtdKOku/BTWDxojCl1
iwIDAQAB
-----END PUBLIC KEY-----

# private key
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA4moC3GsqF7YISFMQ0fnU0rUF2xhxNqSGx9/GTxCynsQhR3hc
eroDXj3rAOTxnNkePB27uZfRDHrH3/LLoj9Vk2ghKRtfjDwXa85uDK8slSQDB9Zl
D1TLQEJDZpKr1OTXY9VwbgtFaotSXoFmG3MORQeALCbrAgDxQ5Q2kJn6rfBuBosz
fUz1qZqrlrY74Axerv1/UtTjL8uyF5r00BxjkvTveC2Pm5A3kq6QANktgfKWy9Ug
s/4ykZF7fxfH+ukJW+iXwLACrdfzhegg/41H5w06m30h0jqhIBZ3nbj5MN+qVbAN
HJMjz+fXqXx1Ovr1DfGtdKOku/BTWDxojCl1iwIDAQABAoIBAQCdwf/8VS8fFlbv
DfHKXKlNp5RM9Nrtl/XRjro+nQPYXBBUHClT2gg+wiXcmalAAIhwmscSqhWe/G4I
PMRmaHrYGtYALnKE49nt5AgKDoSh5lW2QExqQkrcm08bSVcxH8J0bWPJSVE0y564
+rCKr8BhmLhWC0f0PXPeAoeCeceRKYX2oDgO8A0yZRSQUdRWiXOiQ4mUQ3IPCmBc
gD1JJNZ5kR4O904PZz5pbgyvN2t5BKOgLKq+x+8Pa8Rb21rFZKMHO8W04oKaRiGs
f4xwOBAWDOfzDKJzT5xepcPyycgjxcuvyKB2g8biWnDGGOTxDgqMX+R4XeP1aISC
h9bzfRoBAoGBAPREuPhIXRJOsIgSWAAiC5vhLZ9wWELWG95eibQm2SfpY4F0sPpE
lNQJ4yzC7J4BiApFzs1yxwwRmgpVd+wF9iMb4NSzaiTM7fju/Xv4aGhBqRXEokGF
v3QxIlbAwBqeL0rJAAadjbUTTO/u6sC80LI3bfPrn/z1hupZQGR559gjAoGBAO1J
xQ2ODVS4dSH2P+Ocd9LiUBPGyV97+MFixh6z1c2Fd3bNuiIhCxkrng45Dq0CkX84
nPUvtYxEQZoFvyB7gAm0SVlLHnJwBiq+Mp9g0UXSy6rZbjhiFkQs1W/W+Z2OIDsC
y+uXZT7No/J9VyjdrWzZJaBImO8/E4NONXWn8M95AoGACH97j+e0lTZ3ncRFm3uT
u9CRrcJSz8BzJ8FSORpA48qS06YjohFQvC+734rIgJa9DN5w22Tq19ik60cd7PAo
KACISd4UC0O147ssxmtV9oqSP1ef7XehuYEcGLiL9mEadBeaEKDalToeqxo8wIfR
GuIiySGhZ0ODdhO00coL7tECgYBargddD70udDNnICj4PbJY5928QQpxr/m3RZz6
3LTHDstBnosUQdZw7wc+3jUqjsG1gZgR5wKVMPx09N8+dZPPoZMqSZfAGelxajAE
UkaHTXBBwUfqyilCMnP6gofv2wGcK4xsYvXxEzslDxtA5b5By5Yic7vmKg+17Sxm
4yAW2QKBgDyEUzXq3Rrm7ZT720pPhuQDDSO0eHe1L1MUjTRsJ96GkIl0iqQCVgK8
A/6rFFTEeVf8L6GNMTwdtnDFz/CqIU+K1X4HLXmUY2suffWVxZ4KYqiEszCbyrdO
puayMcrx2unhKQyDYjUvD8GxHyquA+p52KDke2TkKfDxfzv0WOE1
-----END RSA PRIVATE KEY-----

Zwalnianie podpisanej aktualizacji

Aby zwolnić podpisaną aktualizację, należy użyć --private-key-path opcji (lub -k) dla release polecenia lub release-react .