다음을 통해 공유

배포

  • 아티클

중요

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

지원 타임라인 및 대안에 대해 자세히 알아보세요.

다중 배포 테스트

시작 문서에서는 특정 배포 키를 사용하여 CodePush 플러그 인을 구성하는 방법을 설명했습니다. 그러나 릴리스 StagingProduction 를 효과적으로 테스트하려면 CodePush 앱(또는 사용자가 만들었을 수 있는 사용자 지정 배포)을 처음 만들 때 만드는 것이 좋습니다. 이렇게 하면 본인의 유효성을 검사할 수 없었던 최종 사용자에게 업데이트를 릴리스하지 않습니다.

참고

클라이언트 쪽 롤백 기능은 충돌을 초래한 릴리스를 설치한 후 사용자의 차단을 해제하는 데 도움이 될 수 있으며, 서버 쪽 롤백(예 appcenter codepush rollback: )을 사용하면 식별된 후 추가 사용자가 잘못된 릴리스를 설치하지 못하도록 방지할 수 있습니다. 그러나 잘못된 업데이트가 처음에 광범위하게 릴리스되는 것을 방지할 수 있다면 더 좋습니다.

및 Production 배포를 Staging 활용하면 다음과 같은 워크플로를 달성할 수 있습니다(자유롭게 사용자 지정할 수 있음).

  1. 명령을 사용하여 appcenter codepush release-react 배포에 Staging CodePush 업데이트를 릴리스합니다(또는 appcenter codepush release 더 많은 제어가 필요한 경우).

  2. 앱의 스테이징/베타 빌드를 실행하고, 서버에서 업데이트를 동기화하고, 예상대로 작동하는지 확인합니다.

  3. 명령을 사용하여 appcenter codepush promote 테스트된 릴리스를 Production 에서 로 Staging 승격

  4. 앱의 프로덕션/릴리스 빌드를 실행하고, 서버에서 업데이트를 동기화하고, 예상대로 작동하는지 확인합니다.

    팁

    보다 신중한 접근 방식을 사용하려는 경우 #3의 일부로 "단계적 롤아웃"을 수행하도록 선택할 수도 있습니다. 이를 통해 사용자의 백분율(예: )만 프로덕션 업데이트를 사용할 수 있도록 하여 업데이트에 대한 추가 잠재적 위험을 완화할 수 있습니다(예 appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20: #2에서 테스트가 가능한 모든 디바이스/조건을 터치했나요?). 그런 다음, 충돌 보고서 또는 고객 피드백이 들어오는지 확인하기 위해 적절한 시간을 기다린 후 를 실행 appcenter codepush patch -a <ownerName>/<appName> Production -r 100하여 전체 대상 그룹으로 확장할 수 있습니다.

위의 단계는 앱의 "스테이징 빌드" 및 "프로덕션 빌드"를 참조합니다. 빌드 프로세스에서 이미 "환경"당 고유한 이진 파일을 생성하는 경우 CodePush 배포 키를 교환하는 것은 앱에서 사용하는 다른 서비스(예: Facebook)에 대한 환경별 구성을 처리하는 것과 같으므로 더 이상 읽을 필요가 없습니다. 그러나 이를 수용하기 위해 빌드 프로세스를 설정하는 방법에 대한 예제를 찾는 경우 앱이 대상으로 하는 플랫폼에 따라 다음 섹션을 참조하세요.

Android

Android Gradle 플러그 인을 사용하면 각 "빌드 유형"(예: 디버그, 릴리스)에 대한 사용자 지정 구성 설정을 정의할 수 있습니다. 이 메커니즘을 사용하면 CodePush 스테이징 배포 키 및 릴리스 빌드를 사용하여 CodePush 프로덕션 배포 키를 사용하도록 디버그 빌드를 쉽게 구성할 수 있습니다.

참고

미리 알림으로 터미널에서 를 실행 appcenter codepush deployment list -a <ownerName>/<appName> -k 하여 이러한 키를 검색할 수 있습니다.

이를 설정하려면 다음 단계를 수행합니다.

React Native >= v0.60

  1. 프로젝트의 앱 수준 build.gradle 파일(예: android/app/build.gradle 표준 React Native 프로젝트)을 엽니다.

  2. 섹션을 android { buildTypes {} } 찾아 각각 및 Production 배포 키를 참조 Staging 하는 및 release 빌드 유형 모두 debug 에 대한 항목을 정의 resValue 합니다.

    android {
    ...
    buildTypes {
        debug {
            ...
            // Note: CodePush updates shouldn't be tested in Debug mode as they're overriden by the RN packager. However, because CodePush checks for updates in all modes, we must supply a key.
            resValue "string", "CodePushDeploymentKey", '""'
            ...
        }
        releaseStaging {
            ...
            resValue "string", "CodePushDeploymentKey", '"<INSERT_STAGING_KEY>"'
            // Note: It's a good idea to provide matchingFallbacks for the new buildType you create to prevent build issues
            // Add the following line if not already there
            matchingFallbacks = ['release']
            ...
        }
        release {
            ...
            resValue "string", "CodePushDeploymentKey", '"<INSERT_PRODUCTION_KEY>"'
            ...
        }
    }
    ...
}

참고

빌드 프로세스에서 배포 키를 구성하는 경우 에서 strings.xml 키를 제거해야 합니다*

참고

에 대한 releaseStaging 명명 규칙은 이 줄 때문에 중요합니다.

React Native v0.29의 경우 - v0.59

  1. 파일을 열고 MainApplication.java 다음을 변경합니다.

    @Override
protected List<ReactPackage> getPackages() {
     return Arrays.<ReactPackage>asList(
         ...
         new CodePush(BuildConfig.CODEPUSH_KEY, MainApplication.this, BuildConfig.DEBUG), // Add/change this line.
         ...
     );
}

  2. 앱의 build.gradle 파일 열기(예: android/app/build.gradle 표준 React Native 프로젝트)

  3. 섹션을 android { buildTypes {} } 찾아 각각 및 Production 배포 키를 참조 Staging 하는 및 release 빌드 유형 모두 debug 에 대한 항목을 정의 buildConfigField 합니다. 원하는 경우 파일에서 gradle.properties 키 리터럴을 정의한 다음 여기에서 참조할 수 있습니다. 어느 쪽이든 작동하며 개인적인 취향의 문제입니다.

    android {
    ...
    buildTypes {
        debug {
            ...
            // Note: CodePush updates shouldn't be tested in Debug mode as they're overridden by the RN packager. However, because CodePush checks for updates in all modes, we must supply a key.
            buildConfigField "String", "CODEPUSH_KEY", '""'
            ...
        }

        releaseStaging {
            ...
            buildConfigField "String", "CODEPUSH_KEY", '"<INSERT_STAGING_KEY>"'

            // Note: It's a good idea to provide matchingFallbacks for the new buildType you create to prevent build issues
            // Add the following line if not already there
            matchingFallbacks = ['release']
            ...
        }

        release {
            ...
            buildConfigField "String", "CODEPUSH_KEY", '"<INSERT_PRODUCTION_KEY>"'
            ...
        }
    }
    ...
}

    팁

    미리 알림으로 터미널에서 를 실행 appcenter codepush deployment list -a <ownerName>/<appName> --displayKeys 하여 이러한 키를 검색할 수 있습니다.

    참고

    에 대한 releaseStaging 명명 규칙은 이 줄 때문에 중요합니다.

  4. 문자열 리터럴이 CodePush 아니라 정의한 빌드 구성을 통해 배포 키를 생성자에 전달합니다.

React Native v0.19의 경우 - v0.28

MainActivity.java 파일을 열고 다음을 변경합니다.

@Override
protected List<ReactPackage> getPackages() {
    return Arrays.<ReactPackage>asList(
        ...
        new CodePush(BuildConfig.CODEPUSH_KEY, this, BuildConfig.DEBUG), // Add/change this line.
        ...
    );
}

참고

Gradle 파일에서 빌드 설정에 다른 이름을 지정한 경우 Java 코드에 이를 반영해야 합니다.

정말 간단하죠! 이제 앱을 실행하거나 빌드할 때 디버그 빌드가 배포와 Staging 동기화되도록 자동으로 구성되고 릴리스 빌드가 배포와 Production 동기화되도록 구성됩니다.

참고

기본적으로 react-native run-android 명령은 앱의 디버그 버전을 빌드하고 배포하므로 릴리스/프로덕션 빌드를 테스트하려면 'react-native run-android --variant release'를 실행합니다. Android 앱에 대한 릴리스 빌드를 구성하고 만드는 방법에 대한 자세한 내용은 React Native 문서를 참조하세요.

디버그 빌드와 릴리스 빌드를 동일한 디바이스에 동시에 설치하려는 경우(매우 권장됨) 디버그 빌드에 릴리스 빌드의 고유한 ID와 아이콘이 있는지 확인해야 합니다. 그렇지 않으면 OS 또는 사용자 둘 다 둘을 구분할 수 없습니다. 다음 단계를 수행하여 고유 ID를 구성할 수 있습니다.

  1. build.gradle 파일에서 디버그 빌드 유형에 대한 필드를 지정 applicationIdSuffix 합니다. 그러면 디버그 빌드에 OS에 대한 고유한 ID(예: com.foo 및 com.foo.debug)가 제공됩니다.

    buildTypes {
    debug {
        applicationIdSuffix ".debug"
    }
}

  2. app/src/debug/res 앱에서 디버그 빌드에 대한 리소스(예: 문자열, 아이콘, 레이아웃)를 재정의할 수 있는 디렉터리 구조를 만듭니다.

  3. values#2에서 만든 디버그 res 디렉터리 아래에 디렉터리를 만들고 디렉터리에서 app/src/main/res/values 기존 strings.xml 파일을 복사합니다.

  4. 새 디버그 strings.xml 파일을 열고 요소의 값을 다른 항목(예: )으로 foo-debug변경 <string name="app_name"> 합니다. 이렇게 하면 이제 디버그 빌드에 고유한 표시 이름이 있으므로 릴리스 빌드와 구분할 수 있습니다.

  5. 필요에 따라 디버그 빌드에 app/src/debug/res 대해 변경하려는 모든 앱 아이콘에 대해 디렉터리에 "미러된" 디렉터리를 만듭니다. 이 부분은 기술적으로 중요하지는 않지만 아이콘이 다른 경우 디바이스에서 디버그 빌드를 더 쉽게 발견할 수 있습니다.

정말 간단하죠! Android에서 리소스 병합이 작동하는 방식에 대한 자세한 내용은 리소스 병합을 참조하세요.

iOS

Xcode를 사용하면 Info.plist 파일 내에서 키 값(예 CodePushDeploymentKey : 설정)으로 참조할 수 있는 각 "구성"(예: 디버그, 릴리스)에 대한 사용자 지정 빌드 설정을 정의할 수 있습니다. 이 메커니즘을 사용하면 다른 CodePush 배포와 동기화하도록 구성된 이진 파일을 생성하도록 빌드를 쉽게 구성할 수 있습니다.

이를 설정하려면 다음 단계를 수행합니다.

  1. Xcode 프로젝트를 열고 프로젝트 탐색기 창에서 프로젝트를 선택합니다.

  2. 대상 중 하나가 아닌 프로젝트 노드가 선택되어 있는지 확인합니다.

  3. 정보 탭 선택

  4. +구성 섹션 내에서 단추를 클릭하고 중복 "릴리스" 구성을 선택합니다.

    구성

  5. 새 구성 스테이징 의 이름을 지정합니다(또는 원하는 대로).

  6. 빌드 설정 탭 선택

  7. 도구 모음에서 + 단추를 클릭하고 User-Defined 설정 추가를 선택합니다.

    설정

    이 설정의 이름을 MULTI_DEPLOYMENT_CONFIG. 설정으로 이동하여 Release에 대한 값을 $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME) 추가 합니다. 그 후 스테이징에 대한 값을 추가합니다$(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME).

    MultiDeploymentConfig

    참고

    Xcode 10 이하 버전의 경우: 구성별 빌드 위치 > 빌드 제품 경로 > 스테이징 으로 이동하여 스테이징 값을 에서 로 $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME) 변경합니다. $(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)

    BuildFilesPath

    참고

    https://github.com/facebook/react-native/issues/11813으로 인해 RN 0.40.0 이상에서 디버그 또는 릴리스 이외의 다른 구성을 사용할 수 있도록 이 단계를 수행해야 합니다.

  8. 도구 모음에서 + 단추를 다시 클릭하고 User-Defined 설정 추가를 선택합니다.

    이 설정CODEPUSH_KEY의 이름을 로 지정하고 확장한 다음 스테이징 구성의 스테이징 배포 키와 릴리스 구성에 대한 프로덕션 배포 키를 지정합니다.

    키 설정

    참고

    미리 알림으로 터미널에서 를 실행 appcenter codepush deployment list -a <ownerName>/<appName> --displayKeys 하여 이러한 키를 검색할 수 있습니다.

  9. 프로젝트의 Info.plist 파일을 열고 항목 값을 CodePushDeploymentKey 로 변경합니다. $(CODEPUSH_KEY)

    Info.plist

정말 간단하죠! 이제 앱을 실행하거나 빌드할 때 스테이징 빌드가 스테이 징 배포와 동기화되도록 자동으로 구성되고 릴리스 빌드가 프로덕션 배포와 동기화되도록 구성됩니다.

참고

오류 메시지가 ld: library not found for ...발견되면 가능한 해결 방법을 위해 이 문제를 검사.

또한 별도의 이름이나 아이콘을 지정하려는 경우 , Product Name및 Asset Catalog App Icon Set Name 빌드 설정을 수정Product Bundle Identifier하여 스테이징 빌드를 동일한 디바이스에 설치할 때 릴리스 빌드와 구별할 수 있습니다.

동적 배포 할당

위의 섹션에서는 여러 CodePush 배포를 사용하여 업데이트를 최종 사용자에게 광범위하게 릴리스하기 전에 효과적으로 테스트하는 방법을 보여 줍니다. 그러나 해당 워크플로는 배포 할당을 실제 이진 파일에 정적으로 포함하므로 스테이징 또는 프로덕션 빌드는 해당 배포의 업데이트만 동기화합니다. 대부분의 경우 팀, 고객, 관련자 등만 사전 프로덕션 릴리스와 동기화하기를 원하므로 스테이징과 동기화하는 방법을 알고 있는 빌드만 있으면 됩니다. 그러나 A/B 테스트를 수행하거나 특정 사용자에게 앱의 초기 액세스를 제공하려는 경우 런타임에 특정 사용자(또는 대상 그룹)를 특정 배포에 동적으로 배치하는 것이 유용할 수 있습니다.

이 워크플로를 수행하려면 메서드를 호출 codePush 할 때 현재 사용자가 동기화할 배포 키를 지정합니다. 지정된 경우 이 키는 앱의 Info.plist (iOS) 또는 MainActivity.java (Android) 파일에 제공된 "기본" 키를 재정의합니다. 이를 통해 스테이징 또는 프로덕션을 위한 빌드를 생성할 수 있으며, 필요에 따라 동적으로 "리디렉션"할 수도 있습니다.

// Imagine that "userProfile" is a prop that this component received
// that includes the deployment key that the current user should use.
codePush.sync({ deploymentKey: userProfile.CODEPUSH_KEY });

이러한 변경 사항이 있으면 이제 앱이 현재 사용자에 적합한 배포 키를 결정하는 방법을 선택해야 합니다. 실제로 이를 위한 두 가지 솔루션이 있습니다.

  1. 언제든지 배포를 변경하기 위한 사용자 표시 메커니즘을 노출합니다. 예를 들어 설정 페이지에는 "베타" 액세스를 사용하도록 설정하기 위한 토글이 있을 수 있습니다. 이 모델은 사전 프로덕션 업데이트의 개인 정보 보호에 관심이 없는 경우 잘 작동하며, 이전(및 잠재적으로 버그가 있는) 업데이트를 자신의 의지(예: Chrome 채널)에 옵트인할 수 있는 전원 사용자가 있는 경우 잘 작동합니다. 그러나 이 솔루션은 A/B 테스트를 투명하게 실행하는 데 도움이 되지 않는 사용자의 손에 결정을 내립니다.

  2. 동기화해야 하는 배포를 나타내는 추가 메타데이터를 사용하여 사용자의 서버 쪽 프로필에 주석을 추가합니다. 기본적으로 앱은 이진 포함 키를 사용할 수 있지만 사용자가 인증된 후 서버에서 다른 배포로 "리디렉션"을 선택할 수 있으므로 필요에 따라 특정 사용자 또는 그룹을 다른 배포에 증분 방식으로 배치할 수 있습니다. 서버 응답을 로컬 스토리지에 저장하여 새 기본값이 되도록 선택할 수도 있습니다. 사용자의 프로필과 함께 키를 저장하는 방법은 전적으로 인증 솔루션(예: Auth0, Firebase, 사용자 지정 DB + REST API)에 달려 있지만 일반적으로 매우 간단합니다.

    참고

    필요한 경우 최종 사용자가 서로 다른 배포 간에 전환할 수 있는 하이브리드 솔루션을 구현하는 동시에 서버가 해당 결정을 재정의할 수 있도록 할 수도 있습니다. 이렇게 하면 앱이 기본적으로 업데이트할 수 있도록 하는 "배포 확인" 계층 구조가 있으며, 최종 사용자는 비트에 대한 초기 액세스를 통해 보상을 받을 수 있지만 필요에 따라 사용자에 대해 A/B 테스트를 실행할 수도 있습니다.

이전 섹션에서 설명한 대로 업데이트의 시험판 테스트에 배포를 사용하는 Staging 것이 좋습니다. 위의 옵션 #1에 설명된 대로 조기 액세스를 허용하는 것이 아니라 사용자의 A/B 테스트에 반드시 사용하는 것은 아닙니다. 따라서 사용자 지정 앱 배포를 최대한 활용하여 사용자를 분할할 수 있지만 요구 사항에 적합합니다. 예를 들어 장기 또는 일회성 배포를 만들고, 앱의 변형을 릴리스한 다음, 특정 사용자를 배치하여 참여 방식을 확인할 수 있습니다.

// #1) Create your new deployment to hold releases of a specific app variant
appcenter codepush deployment add -a <ownerName>/<appName> test-variant-one

// #2) Target any new releases at that custom deployment
appcenter codepush release-react -a <ownerName>/<appName> -d test-variant-one

참고

"/" 및 ":" 문자는 배포 이름에서 지원되지 않습니다.

참고

배포의 "메트릭 설치"에 보고된 총 사용자 수는 한 배포에서 다른 배포로 "전환"된 사용자를 고려합니다. 예를 들어 프로덕션 배포에서 현재 총 사용자가 1명이라고 보고하지만 해당 사용자를 스테이징으로 동적으로 전환하면 프로덕션 배포는 총 0명의 사용자를 보고하고 스테이징 은 1(전환한 사용자)을 보고합니다. 이 동작을 사용하면 런타임 기반 배포 리디렉션 솔루션을 사용하는 경우에도 릴리스 채택을 정확하게 추적할 수 있습니다.