Capgo 환경 최적화: 하나의 모바일 앱 ID를 사용한 스테이징

팀들은 일반적으로 모바일 환경에 대한 세 가지 접근 방식 중 하나를 선택합니다.

두 개의 앱 ID (프로덕션 + 프리 프로덕션)
단일 앱 ID + 동적 런타임 환경switching
단일 앱 ID + Capgo 채널

The first two can work, but they create long-term friction. In real teams, Capgo 채널 모델은 일반적으로 가장 깨끗합니다.

중복된 앱 ID가 노이즈가 되기 때문에

Using com.myapp 와 com.myapp.beta 가 간단해 보이지만, 빠르게 중복이 발생합니다.

두 개의 릴리스 PIPELINE
두 개의 푸시 ID, 깊이 링크, 권한 매핑
두 개의 분석 및 충돌 ID
환경 설정과 불일치하는 동작 사이의 환경

두 개의 제품을 스토어 콘솔, 팀 및 내부 QA 지침을 관리합니다.

Why 런타임-switching config가 종종 복잡합니다.

'one app ID + 런타임 switch' 패턴은 일반적으로 앱이 시작 시 환경 변수 또는 플래그를 읽고 API, 키 및 업데이트 동작을 동적으로 라우팅합니다.

이것은 다음까지 작동합니다.:

QA가 의도하지 않은 흐름을 우회하기 시작하여 구성 상태가陈舊해지면
프로덕션에서 잘못된 엔드포인트를 사용하는 경우
환경 드리프트가 복잡한 버그를 일으키는 경우
사용자 기기에서 “이 바이너리가 사용하는 구성 버전은 무엇인가?”를 디버깅해야 하는 경우

이 복잡성은 각 릴리스마다 증가하고 팀의 속도가 느려지는 곳입니다.

The Capgo way: one app ID, many channels

Capgo makes environment control explicit through channels:

앱 스토어 / 플레이에서 하나의 프로덕션 앱 ID를 유지하세요.
“쉘” (자연스러운 변경이 실제 재빌드가 필요할 때까지) 에 대한 한 개의 네이티브 바이너리를 배포하세요.
채널 대신 중복된 앱 식별성을 통해 동작을 라우팅하세요.

이것은 실제로 다음과 같은 의미를 가지고 있습니다:

production: 모든 사용자
staging: 내부 QA 및 릴리스 후보
beta: 초대된 테스터
hotfix:緊急 패치 트랙

Your TestFlight/Play 내부 테스트 앱은 "forever. You do JS/CSS/asset 업데이트를 __CAPGO_KEEP_0__에서 반복적으로 수행할 수 있습니다. 새로운 네이티브 앱을 릴리스하지 않고도. staging forever. You do JS/CSS/asset updates there repeatedly through Capgo without publishing a new native app.

1) 네이티브 릴리스 기준

Your 마지막 네이티브 바이너리는 많은 JS 반복에서 동일하게 유지됩니다.

네이티브 표면 영역이 실제로 변경된 경우에만 네이티브 바이너리를 다시 빌드합니다.

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

2) 환경별 전용 채널 사용

채널을 사용하여 업데이트를 릴리스합니다:

Publish updates with channels:

bun run build
bunx @capgo/cli deploy --channel staging

테스트 환경에서 테스트, 문제 해결, 그리고 프로모션:

bunx @capgo/cli promote vX.Y.Z --channel production

버전을 명시적으로 지정하는 것을 선호하는 경우:

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) 테스트 플라이트(TestFlight)를 '항상 전제제작'으로 유지:

iOS 워크플로우에서, 이는 전제제작 업데이트와 연관된 테스트 플라이트 빌드를 유지할 수 있음을 의미합니다:

JS 변경 사항에 대해 자주 네이티브로 제출하지 않습니다.
QA는 스테이징 채널을 통해 근처의 프로덕션 code를 항상 유효성 검사합니다.
프로덕션 사용자는 프로모션된 프로덕션 채널 배포만 받습니다.

4) 제어된 워크플로우에만 채널 Switching 사용:

고급 팀에게는 QA/관리자 사용자에게 제어된 채널 Switch를 노출하세요:

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

이것은 선택사항입니다. 대부분의 팀은 대시보드에서 채널 assignments를 사용하고 내부 사용자만 아니라 모든 고객에게 채널 Switch를 사용하지 않습니다.

운영 체크리스트:

한 앱 ID만 사용합니다. (중복된 프로덕션/스테이징 ID가 없습니다.)
원본 네이티브 빌드 PIPELINE
채널 매핑 문서화 (staging, beta, production, hotfix)
프로모션 경로 CI/CD에서 강제
네이티브 리빌드만 실제 네이티브 변경 시
롤백 테스트 정기적으로

실질적인 이점

이 접근 방식은 환경漂移을 제거하고 빌드 충돌을 줄이고修정을 가속화합니다:

QA가 실제 바이너리를 받을 수 있으므로 (가짜 '스테이징 앱' 식별자 없음)
테스트 플라이트 경로가 안정적입니다.
팀은 '두 앱 ID 부채'를 피합니다.
JS-만의 수정을 Capgo에서 빠르게 푸시할 수 있습니다.

결과적으로 관리는 더 간단합니다: fewer artifacts, cleaner telemetry, 그리고 릴리스 운영에서 더 많은 놀람이 없습니다.

Capgo 환경 최적화: 단일 모바일 앱 ID를 사용한 스테이징

__CAPGO_KEEP_0__ 환경 최적화: 단일 모바일 앱 ID를 사용한 스테이징 Capgo Environment Best Practices: Staging with One Mobile App ID __CAPGO_KEEP_0__ 환경 최적화: 단일 모바일 앱 ID를 사용한 스테이징 계획 채널 라우팅 및 스테이지 롤아웃을 위해 채널 채널 채널 채널 Beta 테스트 솔루션 Beta 테스트 솔루션 채널 버전 목표 솔루션 버전 목표 솔루션의 제품 워크플로우에 대해.

Capgo 환경 최적화 방법: 단일 모바일 앱 ID를 사용한 스테이징