최신 앱을 위한 환경 설정

You’ve shipped the release, signed the native binary, and watched the production rollout start normally. Then support reports that users can’t complete a purchase. The crash log looks unrelated, so you spend hours tracing requests, plugin initialization, and recent JavaScript changes. The cause turns out to be a staging API URL left in a rushed production build.

그런 실패는 비상식적인 것이 아닙니다. 환경 설정 환경 설정은 배포에 특화된 설정, 예를 들어 API 엔드포인트, 기능 플래그, 데이터베이스 인증 정보 및 제 3 자 키를 애플리케이션 code에서 분리하는 학문입니다. Capacitor 및 Electron 앱에서 분리는 더 어려울 수 있습니다. 웹 자산이 네이티브 컨테이너 내부에 패키징되기 때문에, 구성 오류는 서버에서 변경할 수 있는 값이 아닌 서명된 아티팩트의 일부가 될 수 있습니다.

더 깊은 문제는 구성 드리프트, 개발, 스테이징 및 프로덕션 간의 점진적인 분열입니다. 개발자가 하나의 .env 파일을 업데이트 한 후, 릴리스 엔지니어가 CI 변수를 변경하고, 모바일 빌드가 이전 버전의 값을 패키징합니다. 앱은 컴파일이 가능하지만, 환경은 동일한 시스템을 나타내지 않습니다. __CAPGO_KEEP_0__ 앱의 개발자와 릴리스 엔지니어는 개발과 프로덕션 간의 차이를 이해하여 일부 명백한 오류를 피할 수 있지만, 드리프트는 운영 모델이 필요하며, 단순한 파일 이름 규칙만으로는 충분하지 않습니다. differences between development and production in Capacitor apps 목차

컨텍스트: Capgo 마케팅 웹사이트. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 위치: 페이지 blog/[slug].astro. 메시지 키 `table_of_contents` (목차)

환경 설정이 프로덕션 앱을 망치기 때문입니다.

• 드립은 무해한 예외로 시작합니다
  • 환경 설정
  • 빌드 시 구성은 릴리스 병목 현상을 발생시킵니다
• 네 가지 주요 구성 패턴을 비교합니다
  • 패턴 1, 12 요소 환경 변수
  • 패턴 2, 환경별 빌드
  • 패턴 3, 런타임 구성
  • 패턴 4, 전용 비밀 관리
• 보안 및 CI/CD implication을 무시할 수 없습니다
  • pipeline에서 구성이 누출됩니다
  • 보안은 릴리스 속도와 공존해야 합니다
• Capacitor와 Electron에서 환경 구성 구현
  • 하나의 계약을 정의하고 유효성 검사합니다
  • Capacitor 내장 구성
  • Electron은 프로세스 경계가 필요합니다.
• Capgo을 사용하여 목표 업데이트와 롤백을 단순화합니다.
  • 채널은 환경 소유권을 명확하게 합니다.
• 환경 설정 감사 목록

환경 설정이 프로덕션 앱을 망치게 되는 이유

가장 비싼 구성 오류는 거의 항상 구성 오류처럼 보이지 않습니다. 잘못된 API 기본 URL은 인증 실패, 빈 계정 화면, 결제 오류 또는 네이티브 플러그인 충돌로 나타날 수 있습니다. 오류가 빌드 PIPELINE 소유자에게 도달할 때까지 원래 오류는 여러 커밋과 성공적인 스토어 제출 아래에 묻혀 있을 수 있습니다.

하이브리드 앱은 특정 오류 패턴을 보입니다. Capacitor은 웹 애플리케이션을 컴파일하고 iOS 또는 Android 프로젝트 내에 자산을 넣습니다. Electron은 렌더러와 메인 프로세스 code을 데스크톱 애플리케이션으로 패키지합니다. 엔드포인트 또는 기능 플래그가 빌드 중에 해결되는 경우 결과 값은 아티팩트와 함께 전송됩니다. 이후 변경하는 경우 일반적으로 새로운 번들을 생성하고 다시 서명한 후 해당 채널을 통해 배포해야 합니다.

드리프트는 무해한 예외로 시작합니다.

구성 드리프트는 합리적인 단축키에서 시작됩니다:

• 지역 오버라이드: 개발자가 기능을 막기 위해 테스트 엔드포인트를 하드 코딩하고 이를 제거하지 않습니다.
• 분리된 PIPELINE 변수: CI는 프로덕션 값이 저장소의 문서화된 구성과 일치하지 않습니다.
• 자연어 전용 설정: Android, iOS 및 Electron은 다른 플러그인 식별자 또는 콜백 설정을 받습니다.
• 비문서화된 플래그: 운영 체제는 배포 시스템에서 직접 기능 플래그를 변경합니다. 반면 스테이징 환경은 이전 동작을 계속 사용합니다.

각 선택 사항은 독립적으로 작동할 수 있습니다. 문제는谁도 어느 값이 권위가 있는지, 어느 환경이 소유하고 있는지, 그리고 언제 마지막으로 변경되었는지 알 수 없을 때 발생합니다.

실용적인 규칙: 만약 구성 값이 애플리케이션 로직과 독립적으로 변경될 수 있다면, 이를 배포 입력으로 대신 소스 code로 다루세요.

스테이징 환경은 프로덕션과 충분히 유사해야 통합 문제를 노출할 수 있어야 합니다. 그러나 격리된 엔드포인트, 자격 증명 및 데이터를 사용해야 합니다. 환경이 분리되면 스테이징이 유용한 연습이 더 이상되지 않습니다. 릴리스는 하나의 가정에 대한 모든 테스트를 통과할 수 있고 다른 가정에 대한 테스트를 통과하지 못할 수 있습니다.

배포 시점 구성은 릴리스 병목 현상을 생성합니다.

배포 시점 구성은 여전히 유용합니다. 공개 컴파일 타임 값, 플랫폼별 식별자 및 네이티브 도구에 의해 필요로 하는 설정은 애플리케이션 패키징되기 전에 존재해야 합니다. 문제는 운영 체제가 릴리스 후에 변경할 수 있는 값으로 빌드 시점 주입을 사용하는 것입니다.

생산 API이 새로운 엔드포인트로 이동하는 경우, 전통적인 Capacitor 워크플로우를 사용하면 팀은 값을 변경하고 웹 자산을 빌드하고 네이티브 프로젝트를 동기화하고 애플리케이션을 서명하고 플랫폼의 릴리스 프로세스를 통해 배포합니다. Electron 팀은 변경된 값이 패키지된 애플리케이션 내부에 속하는 경우에 동일한 주기를 겪습니다.

이 워크플로우는 의도적인 제품 릴리스에 적합하지만 급박한 구성 수정에 대한 좋은 대응은 아닙니다. 바이너리는 건강하고 자바스크립트는 변경되지 않았지만 단일 문자열이 완전한 배포 주기를 강요할 수 있습니다.

안전한 디자인은 세 가지 층을 분리합니다:

1. 애플리케이션 논리환경 구성
2. 비밀 자료이 분리는 이탈을 드러내고 팀이 생산이 다른 방식으로 작동하는 경우에 명확한 대답을 제공합니다: 생산이 다른 방식으로 작동하는지 여부를 확인하기 전에 구성 입력을 비교하세요.
3. 비교하는 네 가지 주요 구성 패턴__CAPGO_KEEP_0__

That separation makes drift visible. It also gives the team a clear answer when production behaves differently: compare the configuration inputs before blaming the code.

__CAPGO_KEEP_0__

하이브리드 애플리케이션의 모든 부분에 적합한 단일 구성 패턴이 없습니다. 백엔드에서는 시작 시 프로세스 환경 변수를 읽을 수 있지만 Capacitor 렌더러에는 전통적인 서버 프로세스가 없습니다. Electron은 메인 프로세스와 렌더러 사이에 또 다른 경계를 추가합니다. 올바른 선택은 값이 공개되야 하는지, 민감한지, 출시 후 변경될 수 있는지, 또는 네이티브 빌드 도구에 의해 필요하는지에 따라 달라집니다.

패턴 하나, 12-Factor 환경 변수

12-Factor 모델은 구성 요소를 환경에 따라 입력으로 다루며, 서버 프로세스, 컨테이너 및 CI 작업과 같은 경우에 자연스럽게 작동합니다. 서비스는 시작 시 값을 읽을 수 있고 여러 배포에서 동일한 아티팩트를 사용할 수 있습니다.

클라이언트 측 앱은 모델을 복잡하게 만듭니다. 브라우저 자바스크립트에 의해 참조되는 값은 결국 클라이언트에 제공되어야 하므로, 환경 변수를 통해 도착했더라도 비밀로 취급되지 않아야 합니다. 공개 API 원본 또는 기능 플래그는 빌드 시 치환을 사용할 수 있지만, 의미 있는 권한을 가진 자격 증명은 역할할 수 있는 클라이언트 패키지에 배송되지 않아야 합니다.

Electron 및 Capacitor의 경우, 이 패턴은 빌드 오케스트레이션 및 공개 구성비밀을 보호하는 데 적합하지 않습니다. 이 패턴은 런타임 변동성이 제한적이지만, 다른 전달 층이 존재할 경우 conceptual 오버헤드가 낮습니다.

패턴 두, 환경별 빌드

개발, 스테이징, 및 프로덕션 빌드 프로필을 유지하는 팀이 많습니다. 각 프로필은 자신의 엔드포인트, 앱 식별자, 네이티브 서비스 파일, 및 기능 플래그를 선택합니다. 이 방법은 플랫폼 요구 사항과 함께 쉽게 설명할 수 있습니다.

약점은 아티팩트 분기입니다. 세 빌드는 다른 동작을 포함할 수 있습니다. 특히 조건부 컴파일 또는 플랫폼 특정 스크립트가 pipe라인에 들어가면, 모든 구성 변경은 새로운 빌드를 생성하고, 서명, 인증, 스토어 처리, 또는 수동 릴리스 조정과 같은 다른 동작을 트리거할 수 있습니다.

롤백도 아티팩트 분포와 관련이 있습니다. 이전 바이너리로 롤백할 수 있지만, 사용자는 이미 다른 버전을 설치할 수 있고, 롤백 경로는 분배 채널에 따라 달라집니다.

패턴 3, 런타임 구성

런타임 구성은 네이티브 아티팩트 외부의 가변 값을 이동합니다. 애플리케이션은 런치 시 구성 문서를 가져오거나 이전에 전달된 문서를 로컬 캐시에서 읽습니다. 이로 인해 팀은 애플리케이션 code을 변경하지 않고 엔드포인트 및 플래그를 수정할 수 있습니다.

거래로는 새로운 시작 의존성이 있습니다. 원격 구성 서비스가 unavailable일 경우, 앱은 안전한 캐시, 바운드 타임아웃, 및 알려진 폴백 정책이 필요합니다. 폴백은 항상 잘못된 환경을指向하지 않아야합니다. 문서의 스키마를 검증하고, 적절한 경우 원본을 인증하고, 앱이 적용한 구성 버전을 기록해야합니다.

하이브리드 앱의 경우, 비서밀 값에 대한 가장 유연한 패턴입니다. 그러나 네트워크 연결이 없는 상태에서 앱을 실행하는 모바일 사용자가 많아 offline 동작에 주의가 필요합니다.

패턴 네, 전용 비밀 관리

HashiCorp Vault와 AWS Secrets Manager와 같은 플랫폼은_sensitive 백엔드 자료를 제어하기 위해 설계되었습니다. 그들은 접근 정책, 감사 기록, 암호화, 및 회전 워크플로를 지원합니다. 따라서 서버 측 서비스가 비밀 저장소에 인증할 수 있어 사용자에게 자격 증명을 노출하지 않고도 사용할 수 있습니다.

그들은 클라이언트-비밀 문제를 해결하지 않습니다. 장치의 소유자에 의해 검사될 수 있는 장치에 비밀을 전달하는 경우, 클라이언트 애플리케이션은만 비밀을 공개할 수 있는 값을 받을 수 있어야 하며, 권한이 있는 작업은 백엔드 뒤에 남아야 합니다.

단일 앱에 작업하는 팀이 간헐적으로 릴리즈를 할 수 있다면, 환경별 빌드와 엄격한 검증을 시작할 수 있다. 성장하는 팀이 병렬로 스테이징과 프로덕션 작업을 필요로 한다면, 런타임层를 사용하여 아티팩트 분열을 줄일 수 있다. 고속 릴리즈 팀은 불변 애플리케이션 번들, 런타임 구성, 백엔드 인증 정보를 위한 비밀 관리자를 combine해야 한다. Capacitor의 기능 플래그 구현 지침 __CAPGO_KEEP_0__의 기능 플래그 구현 지침은 런타임 layer에 들어맞는다. 플래그가 스코프가 되고, 감사되고, 클라이언트에게 노출될 수 있는지 안전한지 확인해야 한다.

보안 및 CI/CD implication을 무시할 수 없다

구성 값은 CI에서 자동으로 안전하지 않다. 값이 클라이언트 번들, 네이티브 리소스, Electron 아카이브, 로그 파일, 크래시 리포트, 장치 백업에 들어가면, 그 아티팩트에 접근할 수 있는 사람에 의해 검사될 수 있다고 가정해야 한다.

공개 식별자 및 클라이언트 사이드 설정은 비밀과 다르다. 모바일 API 키가 애플리케이션을 식별하기만 하면, 제공자가 키가 있는 곳에 키를 기대하고 키의 사용을 제한한다면, 번들에 키가 포함될 수 있다. 데이터베이스 인증 정보, 서명 비밀, 특권 토큰, 제한되지 않은 서비스 인증 정보는 같은 곳에 포함될 수 없다. OWASP SAMM은 생산 비밀을 분리하거나 암호화하여 비밀의 라이프 사이클을 관리하는 대신, 비밀을 포함하는 아티팩트가 저장소에 포함되지 않도록 하며, 비밀을 기다리지 않고 발생한 사고를 대비해야 한다.

pipeline에서 설정이 누출되는 곳입니다.

CI/CD 시스템은 평범한 방식으로 실패합니다. 셸 명령어는 확장 변수를 출력하고, 빌드가 실패하면 비밀을 예외에 포함하거나, 디버깅 단계에서 환경 덤프를 아카이브합니다. .env.production 파일은 또한 버전 관리 시스템에 포함될 수 있습니다. 이는 레포지토리가 불완전한 레포지토리를 상속받았기 때문입니다. .gitignore.

_sensitive한_값을 안전한 저장소에 저장하고 pipeline의 권한을 좁게 유지하세요. 빌드 작업은 해당 목적에 필요한 값만 받고, 로그는 그 값을 가립니다. 생성된 자바스크립트, 네이티브 리소스, Electron 아카이브, 및 소스 맵을 확인하여 의도치 않은 포함을 검사하세요. remotely 전달된 구성 페이로드에 체크섬 또는 서명이 있으면 도난을 감지할 수 있지만, 클라이언트가 볼 수 있는 값을 비밀로 만드는 것은 아닙니다.

분석 또는 다른 sensitive한 데이터를 처리하는 팀은 ELECTE의 AI 분석에 대한 보안 백서를 사용하여 별도의 리소스를 사용할 수 있습니다. 보안은 릴리즈 속도와 공존해야 합니다. CI/CD pipeline에서 고정된 비밀을 포함하는 3 단계의 보안 위험을 보여주는 다이어그램입니다.

pipeline에서 설정이 누출되는 곳입니다.

생산 환경의 비밀 키를 위한 안전한 패턴은 저장, 전송 및 저장 중 암호화, 최소 권한 접근, 및 회전입니다. mutable public endpoint의 경우 안전한 패턴은 다릅니다. endpoint는 버전화된 런타임 문서를 통해 전달 될 수 있으며 사용 전에 검증되고, 오류가 발생하면 폐쇄되도록 제한 될 수 있습니다.

권한이 있는 자격 증명을 Capacitor 또는 Electron code에 넣지 마십시오. 백엔드 라운드 트립을 피하기 위해. obfuscation, minification, 또는 숨겨진 렌더러 변수에 의존하지 마십시오. 그 기술은 간단한 검사를 더 어려워지게 하지만, 클라이언트 디바이스의 신뢰 모델을 변경하지는 않습니다.

실용적인 pipeline은 책임을 분리합니다:

• 소스 제어: 구성 요소 스키마 및 안전한 예시를 커밋하고, live secret는 커밋하지 마십시오.
• 빌드 단계: 만들어지는 artifact에 필요한 값만 주입하고, 로그에서 secret 확장 방지를 막십시오.
• 배포 단계: 인증된, 관찰 가능한 채널을 통해 환경에 따라 런타임 번들을 적용하십시오.
• 회전 단계: 백엔드 자격 증명을 정의된 일정에 따라 폐쇄하고, 즉시 무효화 경로를 포함하여 교체하십시오.

The Capacitor CI/CD secret 관리 방법 __CAPGO_KEEP_0__ 팀에 가장 유용한 CI/CD secret 관리 방법은 명시적인 인벤토리와 pair 될 때입니다. 변수 하나하나에 대해, 공개인지 sensitive인지, 소유주가 누구인지, 어떤 환경에서 사용하는지, 그리고 변경이 native rebuild을 필요로 하는지 문서화하세요.

Capacitor와 Electron에서 환경 설정 구현

A maintainable setup starts with one configuration contract, not a pile of framework-specific conditionals. Keep safe environment inputs in predictable files, load them through the build system, and expose them to application code through a small typed service.

작업 가능한 저장소 레이아웃은 다음과 같습니다:

.env
.env.staging
.env.production
.env.example
src/config/
  schema.ts
  config-service.ts
capacitor.config.ts
electron/
  main.ts
  preload.ts

__CAPGO_KEEP_0__ .env.example 소스 제어에만 속해야 합니다. 다른 파일은 무시하고 CI는 각 대상에 대한 값을 제공해야 합니다. 파일에는 공개 엔드포인트와 기능 플래그가 포함될 수 있지만 sensitive 백엔드 인증서는 전용 비밀 저장소에 남겨야 하며 클라이언트 번들에 포함되지 않아야 합니다.

하나의 계약을 정의하고 유효성 검사하세요

Vite와 함께, 클라이언트 노출 변수는 일반적으로 __CAPGO_KEEP_0__ 접두사를 사용합니다. 접두사는 가시성 신호이며 보안 경계가 아닙니다. VITE_ __CAPGO_KEEP_0__

// src/config/schema.ts
export type AppConfig = {
  apiBaseUrl: string
  enableNewCheckout: boolean
  environment: 'development' | 'staging' | 'production'
}

function required(name: string, value: string | undefined): string {
  if (!value) {
    throw new Error(`Missing required configuration: ${name}`)
  }
  return value
}

export function loadConfig(): AppConfig {
  const environment = required('VITE_APP_ENV', import.meta.env.VITE_APP_ENV)

  if (!['development', 'staging', 'production'].includes(environment)) {
    throw new Error(`Unsupported environment: ${environment}`)
  }

  return {
    apiBaseUrl: required('VITE_API_BASE_URL', import.meta.env.VITE_API_BASE_URL),
    enableNewCheckout: import.meta.env.VITE_ENABLE_NEW_CHECKOUT === 'true',
    environment: environment as AppConfig['environment'],
  }
}

애플리케이션 시작 시 호출하세요. 누락된 값은 명확한 오류를 발생시키고 지역 엔드포인트를 선택하는 대신에야 합니다. 단일 결정은 생산 중 오류 경로를 방지하는 대형 클래스의 버그를 방지합니다. loadConfig() __CAPGO_KEEP_0__

로컬 작업을 위해, Vite는 해당 모드에 맞는 파일을 선택할 수 있습니다. .env.staging스테이징 빌드는 .env.production을 사용할 수 있습니다. 그러나 프로덕션 빌드는

Capacitor native configuration

__CAPGO_KEEP_0__ 네이티브 구성 capacitor.config.ts네이티브 프로젝트는 종종 환경에 따라 달라지는 식별자, 서비스 파일 또는 플러그인 설정이 필요합니다.

// capacitor.config.ts
import type { CapacitorConfig } from '@capacitor/cli'

const isProduction = process.env.APP_ENV === 'production'

const config: CapacitorConfig = {
  appId: isProduction ? 'com.example.app' : 'com.example.app.staging',
  appName: isProduction ? 'Example' : 'Example Staging',
  webDir: 'dist',
  plugins: {
    PushNotifications: {
      presentationOptions: ['badge', 'sound', 'alert'],
    },
  },
}

export default config

에 이러한 값을 유지하세요. 그러나 private 키를 저장하지 마세요.

파이어베이스 파일, 푸시 알림 인증서 및 플랫폼 식별자는 네이티브 빌드 PIPELINE이 선택하고 적절한 접근 제어와 함께 저장해야 합니다. 프로덕션 앱은 스테이징 서비스 인증서를 재사용하지 않아야 합니다. 왜냐하면 빌드는 컴파일 될 때 발생하기 때문입니다. Capacitor local environment setup guide __CAPGO_KEEP_0__ 로컬 환경 설정 가이드

팀이 로컬 모드를 표준화하는 데 도움이 될 수 있지만, 저장소에는 명시적인 계약과 CI 검증이 필요합니다.

Electron은 프로세스 경계가 필요합니다. process.env main process에서 사용할 수 있지만 렌더러에서 정의되지 않거나 의도적으로 사용할 수 없는 경우에만 사용하십시오. 안전한 구성만 프리로드 브리지를 통해 전달하십시오.

// electron/main.ts
import { app, BrowserWindow } from 'electron'
import path from 'node:path'

function createWindow() {
  const window = new BrowserWindow({
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
      contextIsolation: true,
      nodeIntegration: false,
    },
  })

  const safeConfig = {
    apiBaseUrl: process.env.API_BASE_URL,
    environment: process.env.APP_ENV,
  }

  window.webContents.on('did-finish-load', () => {
    window.webContents.send('app-config', safeConfig)
  })

  return window
}

app.whenReady().then(createWindow)

// electron/preload.ts
import { contextBridge, ipcRenderer } from 'electron'

contextBridge.exposeInMainWorld('appConfig', {
  get: () => new Promise((resolve) => {
    ipcRenderer.once('app-config', (_event, config) => resolve(config))
  }),
})

렌더러에서 객체를 다시 검증하십시오. 브리지는 공개 런타임 값만 노출하고 비밀 저장소 토큰이나 특권 파일 시스템 기능은 절대 노출하지 않도록 하십시오.

가장 일반적인 구현 오류는 파일이 자동으로 개인화된다는 가정입니다. 번들러는 생성된 자바스크립트에 그들의 값을 포함할 수 있고, 패키징 단계는 그 자체로 파일을 포함할 수 있습니다. 최종 아티팩트를만들 때는 소스 tree만 검사하지 마세요. .env __CAPGO_KEEP_0__를 사용한 Targeted Updates 및 Rollbacks 단순화

Simplifying Targeted Updates and Rollbacks with Capgo

__CAPGO_KEEP_0__

Capgo의 실시간 업데이트 모델은 이러한 격차를 해결합니다. 대상 채널 개발, 스테이징 및 프로덕션과 같은 배포 계층에 대한 채널

Consider a production API endpoint that changes unexpectedly. The team can update the configuration source, build the web bundle, and publish it to the production channel instead of waiting for a native store release. The important boundary remains intact: this approach doesn’t bypass platform rules for native code, and it doesn’t make a secret safe to ship. It does reduce the time required to correct compatible web-layer configuration.

생산 __CAPGO_KEEP_0__ 엔드포인트가 예기치 않게 변경되었다고 가정해 보겠습니다. 팀은 구성 소스 업데이트, 웹 번들을 빌드하고 프로덕션 채널에 게시할 수 있습니다. 네이티브 __CAPGO_KEEP_1__에 대한 플랫폼 규칙을 우회하지 않으며, 중요한 경계가 유지됩니다. 또한 비밀을 안전하게 배포하지 않습니다. 이 접근 방식은 호환 가능한 웹-layer 구성에 대한 오류를 수정하는 데 필요한 시간을 줄입니다.

채널은 환경 소유권을 명확하게 합니다. 채널은 개발자 개인의 선호도에 해당하지 않습니다. 개발자 테스터는 개발 콘텐츠를, 스테이징 사용자는 스테이징 콘텐츠를, 프로덕션 사용자는 프로덕션에 승인된 번들을 받습니다. CI는 해당 빌드 및 유효성 검사 단계 후에 적절한 번들을 게시할 수 있습니다.

롤백도 중요합니다. 새로운 구성이 불건전한 서비스를 참조하는 경우, 릴리스 오퍼레이터는 해당 채널에 이전에 알려진 좋은 버킷을 선택할 수 있어야 합니다. 버전 기록, 배포 경계, 장치 수준 보고를 통해 팀은 문제가 광범위한지 또는 롤아웃 구역에 국한된지 결정할 수 있습니다.

결과는 다음과 같습니다.

1. 개발 환경에서 버킷을 빌드하고 유효성을 검사하세요.
2. 테스트된 콘텐츠를 스테이징으로 승격하세요.
3. 제품 채널 업데이트 승인하세요.
4. 수용률과 실패를 모니터링하세요.
5. 구성 동작이 잘못되면 채널을 되돌리세요.

이 프로세스는 각 엔드포인트 수정에 대해緊急 네이티브 빌드를 생성하는 유혹을 줄입니다. Capgo 버전 관리 및 롤백 워크플로우 특히 환경별 릴리스가 필요하며 추적 가능한 기록을 유지할 수 있는 팀에게는 특히 관련이 있습니다.

환경 구성 감사 목록

매JOR 릴리스 전에 및 pipeline 변경 후에 이 감사 목록을 실행하세요.

• 소스 코드를 검사하세요: 보안에 취약한 정보가 소스 코드에 포함되지 않았는지 확인하세요. 또한 생성된 자바스크립트, 네이티브 리소스, 소스 맵, 또는 Electron 아카이브에 포함되지 않았는지 확인하세요.
• 분리된 환경: 개발, 스테이징, 및 프로덕션 환경이 서로 다른 엔드포인트, 식별자, 및 승인된 키를 사용하는지 확인하세요.
• 입력 보호: 모든 .env 버전은 무시되며 .env.example 필수 스키마가 문서화되었습니다.
• CI 검토: pipeline가 개발자의 로컬 머신에 의존하지 않고 제어된 저장소에서 값을 주입하는지 확인하세요.
• 회복 테스트: 런타임 구성이 필수 값이 누락된 경우 빠르게 실패하고,.compatiable 업데이트가 롤백될 수 있는 네이티브 셸을 재빌드하지 않고 롤백할 수 있는지 확인하세요.

The audit is complete only when someone can identify the owner, source, scope, and rollback procedure for every production configuration value.

Capgo provides signed live updates for CapacitorJS and Electron apps, including targeted channels and versioned rollbacks for compatible JavaScript, CSS, configuration, and asset changes. If your team wants to reduce rebuild cycles while keeping environment updates controlled, visit Capgo and evaluate it alongside your existing CI/CD process.