App Center CLI를 사용하여 CodePush 업데이트 릴리스

  • 아티클

중요

Visual Studio App Center는 2025년 3월 31일에 사용 중지될 예정입니다. Visual Studio App Center가 완전히 사용 중지될 때까지 계속 사용할 수 있지만 마이그레이션을 고려할 수 있는 몇 가지 권장 대안이 있습니다.

지원 타임라인 및 대안에 대해 자세히 알아봅니다.

설치

  • Node.js
  • App Center CLI를 설치합니다. npm install -g appcenter-cli

시작하기

  1. 명령을 사용하여 App Center 계정을 만들거나 CLI를 통해 로그인합니다 appcenter login .
  2. CodePush에 앱을 등록하고 필요에 따라 팀의 다른 개발자와 앱을 공유합니다.
  3. CodePush-ify 앱을 사용하여 사용하려는 배포를 가리킵니다(Apache Cordova 및 React Native).
  4. 앱에 대한 릴리스 및 업데이트

계정 관리

앱 업데이트 릴리스를 시작하기 전에 기존 CodePush 계정으로 로그인하거나 새 App Center 계정을 만듭니다. CLI를 설치한 후 다음 명령을 실행하여 이 작업을 수행할 수 있습니다.

appcenter login

이 명령은 브라우저를 시작하여 GitHub 또는 Microsoft 계정으로 인증하도록 요청합니다. 인증되면 GitHub/MSA ID에 "연결된" CodePush 계정을 만들고 CLI에 복사/붙여넣어 로그인할 수 있는 액세스 키를 생성합니다.

참고

등록한 후에는 CLI를 사용하여 자동으로 로그인되므로 명시적으로 로그아웃할 때까지 동일한 컴퓨터에서 다시 로그인할 필요가 없습니다.

인증

App Center CLI 내의 대부분의 명령에는 인증이 필요하므로 계정 관리를 시작하기 전에 등록할 때 사용한 GitHub 또는 Microsoft 계정을 사용하여 로그인합니다. 다음 명령을 실행하여 이 작업을 수행할 수 있습니다.

appcenter login

이 명령은 GitHub 또는 Microsoft 계정으로 인증하도록 요청하는 브라우저 창을 시작합니다. CLI에 복사 붙여넣는 액세스 키를 생성합니다(이를 묻는 메시지가 표시됨). 이제 성공적으로 인증되었으며 브라우저 창을 안전하게 닫을 수 있습니다.

이미 로그인한 경우 언제든지 검사 다음 명령을 실행하여 현재 인증 세션의 전자 메일 주소, 사용자 이름 및 표시 이름을 표시할 수 있습니다.

appcenter profile list

CLI에서 로그인하면 액세스 키가 세션 기간 동안 디스크에 유지되므로 계정에 액세스하려고 할 때마다 로그인할 필요가 없습니다. 세션을 종료하고 이 액세스 키를 삭제하려면 다음 명령을 실행합니다.

appcenter logout

실행 중인 세션(예: 친구의 노트북)을 유지하지 않으려는 컴퓨터에서 로그아웃하는 것을 잊어버린 경우 다음 명령을 사용하여 현재 로그인 세션을 나열하고 제거할 수 있습니다.

appcenter tokens list
appcenter tokens delete <machineName>

액세스 토큰

브라우저를 시작하지 않고 또는 GitHub 또는 Microsoft 자격 증명(예: CI 환경에서)을 사용할 필요 없이 CodePush 서비스에 대해 인증하려면 다음 명령을 실행하여 "액세스 토큰"(용도를 설명하는 이름과 함께)을 만들 수 있습니다.

appcenter tokens create -d "Azure DevOps Integration"

키는 한 번만 표시되므로 필요한 경우 어딘가에 저장해야 합니다. 새 키를 만든 후에는 브라우저를 시작하는 대신 "헤드리스" 인증을 사용할 수 있는 명령의 login 플래그를 사용하여 --token 해당 값을 지정할 수 있습니다.

appcenter login --token <accessToken>

이 메서드를 사용하여 로그인할 때 액세스 토큰은 로그아웃 시 자동으로 무효화되지 않으며 App Center 서버에서 명시적으로 제거될 때까지 이후 세션에서 사용할 수 있습니다. 그러나 디스크에서 자격 증명을 제거하려면 세션이 완료되면 로그아웃해야 합니다.

앱 관리

업데이트를 배포하기 전에 다음 명령을 사용하여 App Center를 사용하여 앱을 만듭니다.

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

앱이 Android 및 iOS를 모두 대상으로 하는 경우 CodePush를 사용하여 별도의 앱을 만드는 것이 좋습니다. 각 플랫폼에 대해 하나씩. 이렇게 하면 업데이트를 별도로 관리하고 릴리스할 수 있으며, 장기적으로는 업데이트를 더 간단하게 만드는 경향이 있습니다. 대부분의 사람들은 및 를 사용하여 앱 이름을 접미사로 -Android 추가합니다 -iOS. 예:

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

참고

iOS용으로 생성된 CodePush 업데이트 패키지에는 Android용으로 생성된 업데이트와 다른 콘텐츠가 있으므로 Android 및 iOS에 동일한 앱을 사용하면 설치 예외가 발생할 수 있습니다.

팁

App Center CLI의 중요한 새로운 기능 중 하나는 을 사용하여 appcenter apps set-current <ownerName>/<appName>앱을 현재 앱으로 설정하는 기능입니다. 앱을 현재 앱으로 설정하면 다른 CLI 명령에서 플래그를 -a 사용할 필요가 없습니다. 예를 들어 명령은 appcenter codepush deployment list -a <ownerName>/<appName> 현재 앱이 설정된 시점으로 appcenter codepush deployment list 단축할 수 있습니다. 를 사용하여 appcenter apps get-current계정의 현재 앱으로 설정된 앱을 검사 수 있습니다. 현재 앱을 설정하면 대부분의 CLI 명령을 더 짧게 입력할 수 있습니다.

원래 CodePush를 사용하면 앱에 두 개의 배포(및 Production)가Staging 자동으로 포함됩니다. App Center에서 다음 명령을 사용하여 직접 만들어야 합니다.

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

배포를 만든 후 를 사용하여 두 배포의 배포 키에 액세스할 수 있습니다. 이 키를 사용하여 appcenter codepush deployment list --displayKeys해당 SDK(Cordova 및 React Native 대한 세부 정보)를 통해 모바일 클라이언트를 구성할 수 있습니다.

앱에 지정한 이름이 마음에 들지 않는 경우 다음 명령을 사용하여 언제든지 이름을 바꿀 수 있습니다.

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

경고

앱 이름을 변경하면 분기 구성 및 빌드에서 약 48시간 동안 예기치 않은 문제가 발생할 수 있습니다.

어떤 시점에서 더 이상 앱이 필요하지 않은 경우 다음 명령을 사용하여 서버에서 제거할 수 있습니다.

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

이 명령을 사용하도록 구성된 앱이 업데이트 수신을 중지하기 때문에 이 명령을 실행할 때는 주의해야 합니다.

마지막으로 App Center 서버에 등록한 모든 앱을 나열하려면 다음 명령을 실행합니다.

appcenter apps list

앱 공동 작업

동일한 CodePush 앱에서 다른 개발자와 함께 작업하는 경우 아래 지침 집합에 따라 App Center 포털을 사용하여 공동 작업자로 추가할 수 있습니다.

  1. App Center 포털에서 협력자를 추가할 앱을 선택합니다.
  2. 페이지 왼쪽의 탐색 영역에서 설정을 클릭합니다.
  3. 협력자 링크를 클릭합니다.
  4. 협력자 메뉴 내에서 협력자의 이메일 주소를 입력하여 초대합니다.

중요

App Center의 협력자 기능은 각 협력자가 지정된 전자 메일 주소를 사용하여 App Center에 이미 등록되어 있어야 합니다.

추가되면 모든 협력자는 공유 앱에서 즉시 다음 권한을 갖습니다.

  1. 앱, 해당 협력자, 배포 및 릴리스 기록 보기
  2. 앱 배포에 대한 업데이트 릴리스
  3. 앱 배포 간에 업데이트 승격
  4. 앱 배포 롤백
  5. 앱 배포 내의 모든 릴리스 패치

협력자는 다음 작업을 수행할 수 없습니다.

  1. 앱 이름 바꾸기 또는 삭제
  2. 앱 내에서 새 배포 만들기, 이름 바꾸기 또는 삭제
  3. 배포의 릴리스 기록 지우기
  4. 앱에서 협력자 추가 또는 제거(*)

참고

개발자는 공유된 앱에서 공동 작업자로 자신을 제거할 수 있습니다.

시간이 지남에 따라 다른 사용자가 더 이상 사용자와 함께 앱을 작업하지 않는 경우 포털에서 이 협력자 메뉴를 사용하여 공동 작업자로 제거할 수도 있습니다.

앱에 추가된 모든 협력자를 나열하려는 경우 포털의 협력자 메뉴를 방문할 수 있습니다.

배포 관리

CodePush 관점에서 앱은 하나 이상의 "배포"에 대한 명명된 그룹화입니다. 앱은 앱의 플랫폼별 버전(예: Foo 앱의 iOS 포트)에 대한 개념적 "네임스페이스" 또는 "scope"을 나타내지만, 해당 배포는 업데이트를 릴리스하고(개발자용) 업데이트를 동기화하기 위한 실제 대상(최종 사용자용)을 나타냅니다. 배포를 사용하면 지정된 시간에 각 앱에 대해 여러 개의 "환경"을 사용할 수 있으며, 앱이 일반적으로 개발자의 개인 환경에서 테스트/QA/스테이징 환경으로 이동하는 현실을 모델링한 후 최종적으로 프로덕션 환경으로 전환할 수 있습니다.

참고

아래와 같이 , releasepromote 및 rollback 명령은 배포 지점을 고유하게 식별하는 두 가지의 조합이기 때문에 앱 이름과 배포 이름이 모두 작동해야 합니다(예: iOS 앱의 업데이트를 베타 테스터에 릴리스하려고 함).

앱이 CodePush 서비스에 등록될 때마다 및 Production배포를 Staging 만드는 것이 좋습니다. 이렇게 하면 업데이트를 최종 사용자에게 푸시하기 전에 각 업데이트를 철저히 테스트할 수 있는 내부 환경에 업데이트를 릴리스할 수 있습니다. 이 워크플로는 릴리스가 대량 소비에 대비할 수 있도록 하는 데 중요하며 오랫동안 웹에 설정된 관행입니다.

앱의 스테이징 및 프로덕션 버전이 요구 사항을 충족하기에 충분하다면 다른 작업을 수행할 필요가 없습니다. 그러나 알파, 개발 등 배포를 원하는 경우 다음 명령을 사용하여 쉽게 만들 수 있습니다.

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

앱과 마찬가지로 다음 명령을 각각 사용하여 배포를 제거하고 이름을 바꿀 수도 있습니다.

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

특정 앱에 포함된 배포 목록을 보려면 언제든지 다음 명령을 실행할 수 있습니다.

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

설치 메트릭은 다음과 같은 의미를 갖습니다.

  • 활성 - 현재 이 릴리스를 실행 중인 성공적인 설치 수입니다(사용자가 앱을 연 경우 이 버전이 표시/실행됨). 이 숫자는 최종 사용자가 이 릴리스에서 업그레이드할 때 변경됩니다. 이 메트릭은 활성 사용자의 총계와 전체 대상 그룹의 백분율을 모두 보여 줍니다. 이렇게 하면 사용자가 현재 실행 중인 업데이트의 배포를 쉽게 확인할 수 있을 뿐만 아니라 "내 최신 업데이트를 받은 사용자 수"와 같은 질문에 대답할 수 있습니다.

  • 합계 - 이 업데이트가 전체적으로 수신한 성공한 총 설치 수입니다. 이 수는 새 사용자/디바이스가 설치할 때만 증가하므로 항상 총 활성 수의 상위 집합입니다. 업데이트가 설치된 후 한 번 notifyApplicationReady (또는 sync)이 호출되면 성공한 것으로 간주됩니다. 업데이트가 다운로드되고 성공한 것으로 표시되는 시점 사이에는 "보류 중인" 업데이트로 보고됩니다(자세한 내용은 아래 참조).

  • 보류 중 - 이 릴리스가 다운로드되었지만 아직 설치되지 않은 횟수입니다(변경 내용을 적용하기 위해 앱이 다시 시작됨). 따라서 업데이트가 다운로드되면 이 메트릭이 증가하고 다운로드한 해당 업데이트가 설치되면 감소합니다. 이 메트릭은 주로 즉시 설치하도록 구성되지 않은 업데이트에 적용되며, 업데이트를 적용하기 위해 앱 다시 시작 또는 다시 시작에 의존하는 앱에 대한 릴리스 채택의 광범위한 그림을 제공하는 데 도움이 됩니다(예: 업데이트를 롤백하고 싶은데 아직 다운로드한 사람이 있는지 궁금합니다). 즉시 설치하도록 업데이트를 구성했고 보류 중인 업데이트가 계속 보고되고 있는 경우 앱 시작 시 (또는sync)를 호출 notifyApplicationReady 하지 않을 수 있습니다. 이는 설치 보고서를 보내기 시작하고 설치된 업데이트를 성공한 것으로 표시하는 방법입니다.

  • 롤백 - 이 릴리스가 클라이언트에서 자동으로 롤백된 횟수입니다. 이상적으로 이 숫자는 0이어야 하며, 이 경우 이 메트릭도 표시되지 않습니다. 그러나 설치 프로세스의 일부로 크래시가 포함된 업데이트를 릴리스한 경우 CodePush 플러그 인은 최종 사용자를 이전 릴리스로 롤백하고 해당 문제를 서버에 다시 보고합니다. 이렇게 하면 릴리스가 중단된 경우 최종 사용자가 차단 해제 상태를 유지할 수 있으며 CLI에서 이 원격 분석을 확인하면 잘못된 릴리스를 식별하고 서버에서 롤백 하여 응답할 수 있습니다.

  • 롤아웃 - 이 업데이트를 받을 수 있는 사용자의 백분율을 나타냅니다. 이 속성은 "활성" 롤아웃을 나타내는 릴리스에 대해서만 표시되므로 출시 비율은 100% 미만입니다. 또한 배포는 지정된 시간에 하나의 활성 롤아웃만 가질 수 있으므로 이 레이블은 배포 내의 최신 릴리스에만 존재합니다.

  • 사용 안 함 - 릴리스가 비활성화된 것으로 표시되었는지 여부를 나타내므로 최종 사용자가 다운로드할 수 있습니다. 이 속성은 사용하지 않도록 설정된 릴리스에 대해서만 표시됩니다.

메트릭 셀이 를 보고 No installs recorded하면 서버에서 이 릴리스에 대한 활동을 보지 못했음을 나타냅니다. 원격 분석 지원이 포함된 플러그 인 버전을 제외했거나 최종 사용자가 CodePush 서버와 아직 동기화하지 않았기 때문일 수 있습니다. 설치가 발생하는 즉시 릴리스에 대한 CLI에서 메트릭이 채워집니다.

릴리스 업데이트

앱이 App Center 서버에 대한 업데이트를 쿼리하도록 구성되면 업데이트 릴리스를 시작할 수 있습니다. 단순성과 유연성을 모두 제공하기 위해 App Center CLI에는 업데이트를 릴리스하기 위한 세 가지 명령이 포함되어 있습니다.

  1. 일반 - 외부 도구 또는 빌드 스크립트(예: Gulp 작업, react-native bundle 명령)에 의해 생성된 App Center 서버에 대한 업데이트를 릴리스합니다. 이렇게 하면 CodePush 관련 단계를 엄격하게 처리하고 앱별 컴파일 프로세스를 그대로 두므로 기존 워크플로에 맞추는 측면에서 가장 유연하게 사용할 수 있습니다.

  2. React Native - 일반 릴리스 명령과 동일한 기능을 사용하지만 및 를 모두 react-native bundleappcenter codepush release실행하도록 요구하는 대신 업데이트된 앱 콘텐츠(JS 번들 및 자산)를 생성하는 작업도 처리합니다.

  3. Cordova - 일반 릴리스 명령과 동일한 기능을 사용하지만 ( 또는 phonegap prepare) 및 appcenter codepush release를 모두 cordova prepare 실행하도록 요구하는 대신 앱 업데이트를 준비하는 작업도 처리합니다.

이러한 명령 중 사용해야 하는 명령은 대부분 요구 사항 또는 기본 설정의 문제입니다. 그러나 관련 플랫폼별 명령을 사용하여 시작(환경을 크게 간소화하기 때문에)한 다음, 더 큰 제어가 필요한 경우 범용 release 명령을 사용하는 것이 좋습니다.

참고

배포의 최신 릴리스 50개만 클라이언트에서 검색하고 다운로드할 수 있습니다.

업데이트 릴리스(일반)

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]

앱 이름 매개 변수

이 매개 변수는 이 업데이트가 릴리스될 App Center 앱의 이름을 지정합니다. 조회하려는 경우 명령을 실행 appcenter apps list 하여 앱 목록을 볼 수 있습니다.

콘텐츠 업데이트 매개 변수

이 매개 변수는 릴리스하려는 업데이트된 앱 코드 및 자산의 위치를 지정합니다. 단일 파일(예: React Native 앱의 JS 번들) 또는 디렉터리 경로(예: Cordova 앱의 /platforms/ios/www 폴더)를 제공할 수 있습니다. CLI가 자동으로 압축하므로 이러한 변경 내용을 배포하기 위해 여러 파일 또는 디렉터리를 압축할 필요가 없습니다.

지정한 경로는 앱의 플랫폼별 준비/번들 버전을 참조하는 것이 중요합니다. 다음 표에서는 릴리스하기 전에 실행해야 하는 명령과 나중에 매개 변수를 사용하여 updateContentsPath 참조할 수 있는 위치를 간략하게 설명합니다.

플랫폼 준비 명령 패키지 경로(프로젝트 루트를 기준으로)
Cordova(Android) cordova prepare android ./platforms/android/assets/www 디렉터리
Cordova(iOS) cordova prepare ios ./platforms/ios/www 디렉터리
wo/assets React Native(Android) react-native bundle --platform android --entry-file <entryFile> --bundle-output <bundleOutput> --dev false 옵션의 값입니다 --bundle-output .
자산 React Native(Android) react-native bundle --platform android --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false 앱의 --assets-dest 자산 및 JS 번들을 포함하는 새로 만든 디렉터리를 나타내는 옵션의 값입니다.
iOS(wo/assets) React Native react-native bundle --platform ios --entry-file <entryFile> --bundle-output <bundleOutput> --dev false 옵션 값 --bundle-output
자산 React Native(iOS) react-native bundle --platform ios --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false 앱의 --assets-dest 자산 및 JS 번들을 포함하는 새로 만든 디렉터리를 나타내는 옵션의 값입니다.

대상 이진 버전 매개 변수

이 매개 변수는 업데이트를 릴리스하는 애플리케이션의 저장소/이진 버전을 지정하므로 해당 버전을 실행하는 사용자만 업데이트를 수신하고 이전 또는 최신 버전의 앱 이진 파일을 실행하는 사용자는 업데이트를 받지 않습니다. 다음과 같은 이유로 유용합니다.

  1. 사용자가 이전 이진 버전을 실행하는 경우 실행 중인 버전과 호환되지 않는 CodePush 업데이트의 호환성이 손상되는 변경이 있을 수 있습니다.

  2. 사용자가 최신 이진 버전을 실행하는 경우 실행 중인 항목이 CodePush 업데이트와 더 최신(잠재적으로 호환되지 않을 수 있는) 것으로 추정됩니다.

여러 버전의 앱 스토어 이진 파일을 대상으로 업데이트하려는 경우 매개 변수를 셈버 범위 식으로 지정할 수도 있습니다. 이렇게 하면 범위 식(반환)semver.satisfies(version, range)true을 충족하는 이진 버전을 실행하는 모든 클라이언트 디바이스가 업데이트를 받습니다. 유효한 셈버 범위 식의 예는 다음과 같습니다.

범위 식 업데이트를 받는 사람
1.2.3 앱의 특정 이진 버전을 1.2.3 실행하는 디바이스만
* CodePush 앱에서 업데이트를 사용하도록 구성된 모든 디바이스
1.2.x 주 버전 1, 부 버전 2 및 앱의 패치 버전을 실행하는 디바이스
1.2.3 - 1.2.7 (포함) 및 1.2.7 (포함) 간에 1.2.3 모든 이진 버전을 실행하는 디바이스
>=1.2.3 <1.2.7 (포함) 및 1.2.7 (배타적) 간에 1.2.3 모든 이진 버전을 실행하는 디바이스
1.2 >=1.2.0 <1.3.0와 같습니다.
~1.2.3 >=1.2.3 <1.3.0와 같습니다.
^1.2.3 >=1.2.3 <2.0.0와 같습니다.

참고

앱의 셈버 식이 특수 셸 문자 또는 연산자(예: , ^또는 ** *)로 >시작하는 경우 셸이 CLI 프로세스에 올바른 값을 제공하지 않으므로 값을 따옴표로 래핑하지 않으면 명령이 올바르게 실행되지 않을 수 있습니다. 따라서 명령을 호출 release 할 때 앱의 targetBinaryVersion 매개 변수를 큰따옴표로 래핑하는 것이 가장 좋습니다(예appcenter codepush release -a <ownerName>/<appName> updateContents ">1.2.3": ).

다음 표에서는 CodePush에서 각 앱 유형에 대해 업데이트의 셈버 범위가 충족되는 것으로 예상하는 버전 값을 간략하게 설명합니다.

플랫폼 이진 버전의 원본
Cordova <widget version>config.xml 파일의 특성
React Native(Android) android.defaultConfig.versionName 프로젝트의 build.gradle 파일의 속성입니다.
React Native(iOS) CFBundleShortVersionStringInfo.plist 파일의 키
React Native(Windows) <Identity Version>Package.appxmanifest 파일의 키

참고

메타데이터 파일의 이진 버전에 패치 버전(예: 2.0)이 누락된 경우 의 패치 버전 0, 2.0 -> 2.0.0즉 로 처리됩니다.

배포 이름 매개 변수

이 매개 변수는 업데이트를 릴리스할 배포를 지정합니다. 기본값은 Staging이지만 , 또는 사용자 고유의 사용자 지정 배포 중 하나에 배포할 Production준비가 되면 이 인수를 명시적으로 설정하기만 하면 됩니다.

팁

매개 변수는 또는 -d를 --deployment-name 사용하여 설정할 수 있습니다.

Description 매개 변수

이 매개 변수는 배포에 대한 선택적 "변경 로그"를 제공합니다. 업데이트가 감지되면 앱이 최종 사용자에게 표시하도록 선택할 수 있도록 값이 클라이언트로 반올림됩니다(예: "새로운 기능?" 대화 상자를 통해). 이 문자열은 및 \t 와 같은 \n 컨트롤 문자를 허용하므로 가독성을 향상시키기 위해 설명에 공백 서식을 포함할 수 있습니다.

팁

이 매개 변수는 를 사용하여 --description설정할 수 있습니다.

사용 안 함 매개 변수

이 매개 변수는 업데이트를 최종 사용자가 다운로드할 수 있는지 여부를 지정합니다. 지정되지 않은 상태로 두면 업데이트를 사용하지 않도록 설정되지 않습니다. 대신 사용자는 앱이 를 호출 sync하는 순간 다운로드합니다. 이 매개 변수는 명시적으로 패치 하고 최종 사용자가 다운로드하도록 할 때까지 즉시 사용할 수 없는 업데이트를 릴리스하려는 경우에 유용할 수 있습니다(예: 알림 블로그 게시물이 라이브로 전환됨).

팁

이 매개 변수는 또는 -x을 --disabled 사용하여 설정할 수 있습니다.

필수 매개 변수

이 매개 변수는 업데이트를 필수로 간주할지 여부를 지정합니다(예: 중요한 보안 수정 사항이 포함됨). 이 특성은 클라이언트에 라운드 트립되며, 클라이언트는 이를 적용할지와 방법을 결정할 수 있습니다.

참고

이 매개 변수는 "플래그"이므로 릴리스가 선택 사항임을 나타내고 해당 존재는 필수임을 나타냅니다. 값(예 --mandatory true: )을 제공할 수 있지만 를 지정하면 릴리스를 --mandatory 필수로 표시하기에 충분합니다.

필수 특성은 서버가 앱 릴리스의 의미 체계가 최종 사용자에 대해 유지 관리되도록 필요에 따라 동적으로 수정하기 때문에 고유합니다. 예를 들어 앱에 다음과 같은 세 가지 업데이트를 릴리스한다고 상상해 보세요.

Release 필수?
v1 예
v2 예
v3 No

최종 사용자가 현재 를 실행 중 v1이고 업데이트를 위해 서버를 쿼리하는 경우(최신 버전이므로)로 응답 v3 하지만, 필수 업데이트가 릴리스된 이후 릴리스를 필수로 동적으로 변환합니다. 에 포함된 코드가 에 포함된 v3v2코드로 증분되므로 이 동작은 중요합니다. 필수 항목은 v2 아직 획득v2하지 않은 모든 사용자에게 계속 필수로 적용 v3 됩니다.

최종 사용자가 현재 를 실행하고 v2있고 업데이트를 위해 서버를 쿼리하는 경우 으로 v3응답하지만 릴리스는 선택 사항으로 둡니다. 이는 이미 필수 업데이트를 받았기 때문에 의 v3정책을 수정할 필요가 없기 때문입니다. 이 동작은 서버가 필수 플래그를 "동적으로 변환"한다고 말하는 이유입니다. 릴리스가 진행되는 한 해당 필수 특성은 릴리스할 때 지정한 값을 사용하여 항상 저장되기 때문입니다. 최종 사용자의 업데이트 검사 응답할 때만 필요에 따라 즉석에서 변경됩니다.

설명된 동작은 로 mandatory표시된 업데이트를 릴리스하는 경우에만 적용됩니다. 서버는 위에서 설명한 optional 대로 섞인 mandatory 업데이트가 있는 경우에만 릴리스 mandatory 를 로 변경합니다.

로 mandatory 표시된 릴리스는 로 변환 optional되지 않습니다.

팁

이 매개 변수는 또는 중 하나를 --mandatory 사용하여 설정할 수 있습니다. -m*

중복 릴리스 오류 매개 변수 없음

이 매개 변수는 업데이트가 배포의 최신 릴리스와 동일한 경우 CLI에서 오류 대신 경고를 생성하도록 지정합니다. 작은 수정으로 인해 프로덕션 코드가 변경되지 않은 릴리스를 트리거할 수 있는 지속적인 통합 시나리오에 유용합니다.

롤아웃 매개 변수

중요

이 매개 변수를 적용하려면 최종 사용자가 CodePush 플러그 인의 버전 1.6.0-beta+ (Cordova용) 또는 1.9.0-beta+ (React Native) 버전을 실행해야 합니다. 롤아웃 속성을 지정하는 업데이트를 릴리스하는 경우 이전 버전의 Cordova 또는 React Native 플러그 인을 실행하는 최종 사용자가 업데이트를 받을 수 없습니다. 플랫폼별 CodePush 플러그 인의 필요한 버전을 채택할 때까지(앞에서 설명한 대로) 앱 릴리스에서 롤아웃 값을 설정하는 것은 권장되지 않습니다.

이 매개 변수는 이 업데이트를 받을 수 있는 사용자 백분율(및 100사이의 1 정수)을 지정합니다. 앱 대상 그룹의 일부(예: 25%)를 사용하여 새 릴리스를 "플라이트"하고 모든 사용자가 광범위하게 사용할 수 있도록 하기 전에 예외 또는 크래시에 대한 피드백을 받거나 watch 경우 유용할 수 있습니다. 이 매개 변수가 설정되지 않은 경우 기본값은 입니다 100%. 수신할 사용자 수를 제한하도록 설정하기만 하면 됩니다.

롤아웃 기능을 사용하는 경우 다음과 같은 몇 가지 추가 고려 사항을 고려해야 합니다.

  1. 최신 릴리스가 "활성" 롤아웃(해당 롤아웃 속성이 null이 아닌 경우)인 배포에 대한 새 업데이트를 릴리스할 수 없습니다. 배포에 대한 추가 업데이트를 릴리스하려면 롤아웃을 "완료"(속성을 100로 설정rollout)해야 합니다.

  2. 최신 릴리스가 "활성" 롤아웃인 배포를 롤백하면 롤아웃 값이 지워집니다. 롤아웃 동작을 효과적으로 "비활성화"합니다.

  3. mandatory 및 필드와 description 달리 릴리스를 한 배포에서 다른 배포로 승격할 때는 속성이 전파 rollout 되지 않으므로 새 릴리스(대상 배포)에 롤아웃 값이 있도록 하려면 명령을 호출 promote 할 때 명시적으로 설정해야 합니다.

팁

이 매개 변수는 또는 중 하나를 --rollout 사용하여 설정할 수 있습니다. -r*

업데이트 릴리스(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]

이 release-react 명령은 동일한 모든 매개 변수(예--mandatory: , --description)를 지원하지만 다음 추가 작업을 수행하여 업데이트를 릴리스하는 프로세스를 간소화하는 "바닐라" release 명령의 React Native 특정 버전입니다.

  1. react-native bundle CodePush 서버에 릴리스될 업데이트 콘텐츠(JS 번들 및 자산)를 생성하는 명령을 실행합니다. 가능한 한 합리적인 기본값을 사용하지만(예: iOS 항목 파일의 이름이 index.ios.js가정하는 비 개발 빌드 만들기) 유연성을 사용하도록 관련 react-native bundle 매개 변수를 노출합니다(예 --sourcemap-output: ).

  2. 프로젝트의 Info.plist(iOS용) 및 build.gradle(Android용) 파일에 지정된 버전 이름을 사용하여 이 릴리스의 를 유추 targetBinaryVersion 합니다.

명령이 수행할 수 있는 차이점을 release-react 설명하기 위해 다음 예제에서는 "바닐라" release 명령을 사용하여 React Native 앱에 대한 업데이트를 생성하고 릴리스하는 방법을 보여 줍니다.

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

명령을 사용하여 동등한 동작을 release-react 수행하려면 오류가 발생하기 쉬운 다음 명령이 필요합니다.

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

앱 이름 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

배포 이름 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

Description 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

필수 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

중복 릴리스 오류 매개 변수 없음

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

롤아웃 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다. 지정되지 않은 상태로 두면 릴리스가 모든 사용자가 사용할 수 있게 됩니다.

대상 이진 버전 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다. 지정되지 않은 상태로 두면 기본적으로 앱의 Info.plist (iOS용) 및 build.gradle (Android용) 파일에 지정된 정확한 버전을 대상으로 지정합니다.

번들 이름 매개 변수

이 매개 변수는 생성된 JS 번들에 사용해야 하는 파일 이름을 지정합니다. 지정되지 않은 상태로 두면 지정된 플랫폼인 기본.jsbundle(iOS), index.android.bundle(Android) 및 index.windows.bundle(Windows)에 표준 번들 이름이 사용됩니다.

팁

이 매개 변수는 또는 중 하나를 --bundle-name 사용하여 설정할 수 있습니다. -b*

개발 매개 변수

이 매개 변수는 수정되지 않은 개발 JS 번들을 생성할지 여부를 지정합니다. 지정되지 않은 상태로 두면 기본적으로 경고가 비활성화되고 번들이 축소되는 위치로 설정 false 됩니다.

팁

이 매개 변수는 를 사용하여 설정할 수 있습니다. --development*

사용 안 함 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

항목 파일 매개 변수

이 매개 변수는 앱의 루트/항목 JavaScript 파일에 대한 상대 경로를 지정합니다. 지정되지 않은 상태로 두면 기본적으로 index.ios.js (iOS의 경우), index.android.js (Android의 경우) 또는 index.windows.bundle (Windows의 경우)로 설정되거나, 그렇지 않으면 index.js .

팁

이 매개 변수는 또는 중 하나를 --entry-file 사용하여 설정할 수 있습니다. -e*

Gradle 파일 매개 변수(Android에만 해당)

이 매개 변수는 릴리스에 대한 대상 이진 버전을 자동 검색하려고 할 때 CLI에서 사용해야 하는 build.gradle 파일의 상대 경로를 지정합니다. CLI는 "표준" React Native 프로젝트에서 프로젝트의 build.gradle 파일을 자동으로 찾을 수 있으므로 이 매개 변수는 고급 시나리오에만 사용됩니다. 그러나 프로젝트의 gradle 파일이 임의 위치에 있는 경우 CLI에서 검색할 수 없는 경우 이 매개 변수를 사용하면 매개 변수를 명시적으로 설정할 --target-binary-version 필요 없이 CodePush 업데이트를 계속 릴리스할 수 있습니다. build.gradle은 필수 파일 이름이기 때문에 포함된 폴더의 경로 또는 파일 자체의 전체 경로를 지정하면 둘 다 동일한 효과를 얻을 수 있습니다.

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

팁

이 매개 변수는 또는 중 하나를 --gradle-file 사용하여 설정할 수 있습니다. -g*

Plist 파일 매개 변수(iOS만 해당)

이 매개 변수는 릴리스의 대상 이진 버전을 자동 검색하려고 할 때 CLI에서 사용해야 하는 Info.plist 파일의 상대 경로를 지정합니다. CLI는 "표준" React Native 프로젝트에서 프로젝트의 Info.plist 파일을 자동으로 찾을 수 있고 매개 변수를 사용하여 --plistFilePrefix 환경별 plist 파일(예: STAGING-Info.plist)을 지원할 수 있으므로 이 매개 변수는 고급 시나리오에만 사용됩니다. 그러나 프로젝트의 plist가 임의 위치에 있는 경우 CLI에서 검색할 수 없는 경우 이 매개 변수를 사용하면 매개 변수를 명시적으로 설정할 --target-binary-version 필요 없이 CodePush 업데이트를 계속 릴리스할 수 있습니다.

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

팁

이 매개 변수는 또는 중 하나를 --plist-file 사용하여 설정할 수 있습니다. -p*

Plist 파일 접두사 매개 변수(iOS에만 해당)

이 매개 변수는 릴리스의 대상 이진 버전을 자동 검색하려고 할 때 CLI에서 사용해야 하는 Info.plist 파일의 파일 이름 접두사를 지정합니다. 이는 환경별 plist 파일(예: DEV-Info.plist, STAGING-Info.plist)을 만들고 매개 변수를 명시적으로 설정할 --target-binary-version 필요 없이 CodePush 업데이트를 릴리스하려는 경우에 유용할 수 있습니다. 를 지정하면 --plist-file-prefixCLI는 다음 위치에서 ./iosInfo.plist(기본 동작) 대신 라는 <prefix>-Info.plist파일을 찾습니다. 및 ./ios/<appName>. 프로젝트의 plist 파일이 이러한 디렉터리 중 하나에 있지 않거나(예: 앱이 포함된 RN 보기가 있는 네이티브 iOS 앱) 완전히 다른 파일 명명 규칙을 사용하는 경우 매개 변수를 사용하는 --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-"

원본 맵 출력 매개 변수

이 매개 변수는 생성된 JS 번들의 소스 맵 파일을 작성해야 하는 상대 경로를 지정합니다. 지정되지 않은 상태로 두면 원본 맵이 생성되지 않습니다.

팁

이 매개 변수는 또는 중 하나를 --sourcemap-output 사용하여 설정할 수 있습니다. -s*

빌드 구성 이름

이 릴리스를 대상으로 지정할 이진 버전을 지정하는 빌드 구성의 이름입니다. 예를 들어 "디버그" 또는 "릴리스"(iOS만 해당)입니다.

참고

이 매개 변수는 Xcode 11 이상을 사용하여 빌드할 때 Xcode에서 사용하는 기본 구성을 재정의하는 데 사용해야 합니다.

업데이트 릴리스(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]

이 release-cordova 명령은 동일한 매개 변수(예--mandatory: , --description)를 모두 지원하지만 다음 추가 작업을 수행하여 업데이트를 릴리스하는 프로세스를 간소화하는 "바닐라" release 명령의 Cordova 특정 버전입니다.

  1. cordova prepare (또는phonegap prepare) 명령을 실행하여 CodePush 서버에 릴리스될 업데이트 콘텐츠(www 폴더)를 생성합니다.

  2. 프로젝트의config.xml파일에 지정된 버전 이름을 사용하여 이 릴리스의 를 유추 targetBinaryVersion 합니다.

명령이 수행할 수 있는 차이점을 release-cordova 설명하기 위해 다음 예제에서는 "vanilla" release 명령을 사용하여 Cordova 앱에 대한 업데이트를 생성하고 릴리스하는 방법을 보여 줍니다.

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

명령을 사용하여 동등한 동작을 release-cordova 수행하려면 오류가 발생하기 쉬운 다음 명령이 필요합니다.

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

앱 이름 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

배포 이름 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

Description 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

필수 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

중복 릴리스 오류 매개 변수 없음

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

롤아웃 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다. 지정되지 않은 상태로 두면 릴리스가 모든 사용자가 사용할 수 있게 됩니다.

대상 이진 버전 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다. 지정되지 않은 상태로 두면 명령은 기본적으로 프로젝트의 메타데이터에서 지정된 버전만 대상으로 지정합니다(이 업데이트가 iOS 클라이언트용인 경우 Info.plist , Android 클라이언트의 경우 build.gradle ).

사용 안 함 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

빌드 매개 변수

이 매개 변수는 업데이트된 웹 자산을 생성할 때 (기본 동작) 대신 cordova prepare 실행할 cordova build 지 여부를 지정합니다. 프로젝트에 빌드 후크 전후(예: TypeScript를 변환하기 위해)가 포함되어 있으면 CodePush를 실행하는 cordova prepare 것으로 업데이트를 만들고 릴리스하는 데 충분하지 않습니다. 지정되지 않은 상태로 두면 기본값은 입니다 false.

팁

이 매개 변수는 또는 중 하나를 --build 사용하여 설정할 수 있습니다. -b*

업데이트 메타데이터 패치

업데이트를 릴리스한 후 하나 이상의 메타데이터 특성을 수정하려는 시나리오가 있을 수 있습니다(예: 중요한 버그 수정을 필수로 표시하는 것을 잊은 경우 업데이트의 출시 비율을 늘리려는 경우). 다음 명령을 실행하여 이 작업을 쉽게 수행할 수 있습니다.

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]

참고

이 명령은 릴리스의 실제 업데이트 내용(예 www : Cordova 앱의 폴더)을 수정하는 것을 허용하지 않습니다. 손상된 것으로 식별된 릴리스에 응답하려면 롤백 명령을 사용하여 즉시 롤백한 다음 필요한 경우 사용 가능한 경우 적절한 수정 사항으로 새 업데이트를 릴리스해야 합니다.

및 deploymentName를 <ownerName>/<appName> 제외하고 모든 매개 변수는 선택 사항이므로 이 명령을 사용하여 단일 특성 또는 모든 매개 변수를 한 번에 업데이트할 수 있습니다. 특성 플래그를 patch 지정하지 않고 명령을 호출하면 no-op이 발생합니다.

# 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%

Label 매개 변수

지정된 배포 내에서 업데이트할 릴리스(예 v23: )를 나타냅니다. 생략하면 요청된 변경 내용이 지정된 배포의 최신 릴리스에 적용됩니다. 업데이트하려는 릴리스에 대한 레이블을 조회하려면 명령을 실행하고 appcenter codepush deployment history 열을 참조할 Label 수 있습니다.

필수 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 릴리스를 필수로 간주할지 여부를 업데이트할 수 있습니다. 및 --mandatory true 는 --mandatory 동일하지만 이 플래그의 부재는 와 동일--mandatory false하지 않습니다. 매개 변수를 생략하면 대상 릴리스의 필수 속성 값이 변경되지 않습니다. 릴리스를 --mandatory false 명시적으로 선택적으로 만들려면 이 매개 변수를 로 설정합니다.

Description 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 릴리스에 대한 설명을 업데이트할 수 있습니다(예: 릴리스할 때 오타를 만들거나 설명을 추가하는 것을 잊은 경우). 이 매개 변수를 생략하면 대상 릴리스의 description 속성 값이 변경되지 않습니다.

사용 안 함 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 릴리스를 사용하지 않도록 설정해야 하는지 여부를 업데이트할 수 있습니다. 주의 --disabled 해야 하며 --disabled true 동일하지만 이 플래그가 없는 것은 와 동일 --disabled false하지 않습니다. 매개 변수를 생략하면 대상 릴리스의 사용 안 함 속성 값이 변경되지 않습니다. 이전에 사용하지 않도록 설정된 경우 릴리스를 명시적으로 획득할 수 있도록 하려면 이 매개 변수 --disabled false 를 로 설정합니다.

롤아웃 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 대상 릴리스의 출시 비율을 늘릴 수 있습니다. 이 매개 변수는 값이 현재 출시 값보다 큰 정수로만 설정할 수 있습니다. 또한 롤아웃을 "완료"하고 모든 사용자가 릴리스를 사용할 수 있도록 하려면 이 매개 변수를 --rollout 100로 설정할 수 있습니다. 이 매개 변수를 생략하면 대상 릴리스의 롤아웃 매개 변수 값이 변경되지 않습니다.

또한 위에서 설명한 대로 롤아웃 값 없이 업데이트를 릴리스할 때 롤아웃 100을 로 설정하는 것과 동등하게 처리됩니다. 롤아웃 없이 업데이트를 릴리스한 경우 롤아웃 비율을 낮추는 것으로 간주되므로 명령을 통해 patch 롤아웃 속성을 변경할 수 없습니다.

대상 이진 버전 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 릴리스가 호환되는 이진 버전을 나타내는 셈버 범위를 업데이트할 수 있습니다. 이는 원래 업데이트를 릴리스할 때(예: 지정 1.0.0 했지만 의미 1.1.0) 실수를 했거나 릴리스에서 지원하는 버전 범위를 늘리거나 줄이려는 경우에 유용할 수 있습니다(예: 릴리스가 결국에는 1.1.2 작동하지 않는다는 것을 발견). 이 매개 변수를 생략하면 대상 릴리스의 버전 속성 값이 변경되지 않습니다.

# 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"

업데이트 승격

특정 배포(예 Staging: )에 대한 업데이트를 테스트하고 "다운스트림"(예: 개발> 스테이징, 스테이징 프로덕션>)을 승격하려는 경우 다음 명령을 사용하여 한 배포에서 다른 배포로 릴리스를 복사할 수 있습니다.

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]

명령은 promote 원본 배포의 최신 릴리스에서 정확한 코드 및 메타데이터 (설명, 필수 및 대상 이진 버전)를 포함하는 대상 배포에 대한 새 릴리스를 만듭니다. 명령을 사용하여 release 한 환경에서 다른 promote 환경으로 업데이트를 "수동으로" 마이그레이션할 수 있지만 명령에는 다음과 같은 이점이 있습니다.

  1. 게시하려는 릴리스 자산을 다시 어셈블하거나 원본 배포 릴리스에 대한 설명/이진 버전을 기억할 필요가 없으므로 더 빠릅니다.

  2. 승격 작업은 원본 배포에서 이미 테스트한 정확한 항목(예: )이 대상 배포(예StagingProduction: )에서 활성화되도록 하기 때문에 오류가 발생하기 쉽습니다.

모든 사용자가 자동으로 생성된 Staging 환경과 환경을 활용하고 Production , 모든 릴리스를 Staging에 직접 수행한 다음 promote , 적절한 테스트 후 에서 로 StagingProduction 수행하는 것이 좋습니다.

Description 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 승격된 릴리스에 사용할 설명을 재정의할 수 있습니다. 지정되지 않은 경우 새 릴리스는 승격되는 릴리스에서 설명을 상속합니다.

사용 안 함 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 승격된 릴리스에 사용할 disabled 플래그의 값을 재정의할 수 있습니다. 지정되지 않은 경우 새 릴리스는 승격되는 릴리스에서 disabled 속성을 상속합니다.

필수 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 승격된 릴리스에 사용할 필수 플래그를 재정의할 수 있습니다. 지정되지 않은 경우 새 릴리스는 승격되는 릴리스에서 필수 속성을 상속합니다.

중복 릴리스 오류 매개 변수 없음

위의 섹션에 설명된 것과 동일한 매개 변수입니다.

롤아웃 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 새로 만든 릴리스를 사용자의 일부만 사용할 수 있도록 할지 여부를 지정할 수 있습니다. 다른 릴리스 메타데이터 매개 변수(예 description: ) rollout 와 달리 릴리스의 는 승격의 일부로 전달/상속되지 않으므로 새로 만든 릴리스를 모든 사용자가 사용할 수 없도록 하려면 명시적으로 설정해야 합니다.

대상 이진 버전 매개 변수

위의 섹션에 설명된 것과 동일한 매개 변수이며 승격된 릴리스에 사용할 대상 이진 버전을 재정의할 수 있습니다. 지정되지 않은 경우 새 릴리스는 승격되는 릴리스에서 대상 이진 버전 속성을 상속합니다.

# 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 "*"

롤백 업데이트

배포의 릴리스 기록은 변경할 수 없으므로 릴리스된 후에는 업데이트를 삭제하거나 제거할 수 없습니다. 그러나 손상된 업데이트를 릴리스하거나 의도하지 않은 기능이 포함된 경우 명령을 사용하여 rollback 쉽게 롤백할 수 있습니다.

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

이 명령을 실행하면 최신 버전 이전 버전 과 정확히 동일한 코드 및 메타데이터 를 포함하는 배포에 대한 새 릴리스가 만들어집니다. 예를 들어 앱에 다음 업데이트를 릴리스한 경우를 생각해 보세요.

해제 Description 필수
v1 초기 릴리스! Yes
v2 새 기능 추가됨 No
v3 버그 수정 Yes

해당 배포에서 rollback 명령을 실행하면 릴리스의 내용 v2 이 포함된 새 릴리스(v4)가 만들어집니다.

해제 Description 필수
v1 초기 릴리스! Yes
v2 새 기능 추가됨 No
v3 버그 수정 Yes
v4(v3에서 v2로 롤백) 새 기능 추가됨 No

이미 획득한 v3 최종 사용자는 이제 앱이 업데이트 검사 수행할 때 로 "다시 이동"v2됩니다. 또한 를 계속 실행 v2중이므로 를 획득한 v3적이 없는 사용자는 이미 최신 릴리스를 실행 중이므로 업데이트를 받지 못합니다(따라서 업데이트 검사 릴리스 레이블 외에 패키지 해시를 사용하는 이유입니다).

이전(예 v3 : ->v2)이 아닌 다른 릴리스로 배포를 롤백하려는 경우 선택적 --target-release 매개 변수를 지정할 수 있습니다.

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

참고

롤백에 의해 생성된 릴리스는 명령의 deployment history 출력에 주석이 추가되어 보다 쉽게 식별할 수 있습니다.

릴리스 기록 보기

다음 명령을 사용하여 특정 앱 배포에 대한 50개의 최신 릴리스 기록을 볼 수 있습니다.

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

기록에는 각 릴리스에 대한 모든 특성(예: 레이블, 필수)이 표시되며 승격 또는 롤백 작업으로 인해 릴리스가 만들어졌는지 여부를 나타냅니다.

배포 기록

또한 기록에는 각 릴리스에 대한 설치 메트릭이 표시됩니다. 위의 명령에 대한 설명서에서 메트릭 데이터를 해석하는 방법에 대한 deployment list 세부 정보를 볼 수 있습니다.

릴리스 기록 지우기

다음 명령을 사용하여 배포에 대한 릴리스 기록을 지울 수 있습니다.

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

이 명령을 실행한 후 연결된 배포 키를 사용하여 업데이트를 받도록 구성된 클라이언트 디바이스는 더 이상 지워진 업데이트를 받지 않습니다. 이 명령은 되돌릴 수 없으므로 프로덕션 배포에서 사용하면 안 됩니다.

코드 서명

무엇인가요?

코드 서명은 나중에 설치하기 전에 클라이언트 쪽에서 유효성을 검사할 수 있는 번들에 대한 디지털 서명을 만드는 방법입니다.

이 기능이 필요한 이유

개발자는 자신이 제공하는 코드가 작성한 코드임을 알고 싶어합니다. 코드 서명은 이러한 보증을 제공하는 기본 메커니즘이며 전체 클래스의 중간자 공격을 완화하거나 제거하는 데 도움이 될 수 있습니다.

작동 원리

먼저 개발자는 비대칭 키 쌍을 생성합니다. 프라이빗 키는 번들에 서명하는 데 사용됩니다. 번들 서명 확인을 위한 공개 키입니다. 그런 다음 CodePush CLI는 프라이빗 키를 사용하여 , release-react 및 release-cordova 명령 중에 release번들에 서명합니다. 공개 키는 모바일 애플리케이션과 함께 제공됩니다. 키 생성 및 관리에 대한 제어는 개발자의 손에 있습니다.

릴리스 명령이 끝나면 CLI는 번들의 콘텐츠 해시를 계산하고 이 값을 프라이빗 키로 서명된 JWT에 배치합니다. CodePush 플러그 인이 디바이스에 번들을 다운로드하면 JWT가 포함된 파일을 확인하고 .codepushrelease 공개 키를 사용하여 JWT 서명의 유효성을 검사합니다. 유효성 검사에 실패하면 업데이트가 설치되지 않습니다.

이 기능을 사용하기 위한 요구 사항

이 기능을 사용하려는 경우 다음 단계를 수행합니다.

  1. 을 포함한 새 이진 업데이트 생성

    • 코드 서명을 지원하는 CodePush 플러그 인 업데이트
    • 공개 키를 사용하도록 코드 푸시 sdk 구성(자세한 내용은 관련 React Native SDK(iOS, Android) 또는 Cordova SDK 섹션 참조)

  2. 새 이진 버전을 대상으로 하고 (또는 -k) 매개 변수 값을 지정하는 --private-key-path 새 CodePush 업데이트를 생성합니다.

SDK/CLI 내에서 코드 서명 기능이 지원되는지 확인하려면 호환성 테이블을 참조하세요.

CodePush SDK 코드 서명이 지원되는 버전 지원되는 플랫폼 최소 CodePush CLI 버전 필요
react-native-code-push 5.1.0 Android, iOS 2.1.0
cordova-plugin-code-push 1.10.0 Android, iOS 2.1.2

키 생성

코드 서명은 서명을 위해 PEM으로 인코딩된 RSA 키(비 인증서)를 지원합니다. 아래와 같이 openssl을 통해 생성할 수 있습니다.

# 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

생성된 키 예제:

# 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-----

서명된 업데이트 릴리스

서명된 업데이트를 릴리스하려면 또는 release-react 명령에 (또는 -k) 옵션을 release 사용해야 --private-key-path 합니다.