최신 앱을 위한 환경 설정

앱을 배포하고 네이티브 바이너리를 서명하고 프로덕션 롤아웃을 정상적으로 시작했습니다. 그런 다음 지원팀에서 사용자가 구매를 완료할 수 없다고 보고합니다. 크래시 로그는 관련이 없다고 생각되므로, 요청, 플러그인 초기화 및 최근 자바스크립트 변경 사항을 추적하는 시간을 보냈습니다. 원인은 급히 프로덕션 빌드를 만들 때 남겨진 스테이징 API URL로 밝혀졌습니다.

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

더 깊은 문제는 구성 드리프트, 개발, 스테이징 및 프로덕션 간의 점진적인 분열입니다. 개발자가 하나의 파일을 업데이트하고 릴리스 엔지니어가 CI 변수를 변경하고 모바일 빌드가 이전 값의 보관을 보존하는 경우 앱은 컴파일이 가능하지만 환경은 더 이상 동일한 시스템을 나타내지 않습니다. __CAPGO_KEEP_0__ 앱의 개발과 프로덕션 간의 차이를 이해하는 팀은 명백한 실수를 피할 수 있지만 드리프트는 운영 모델이 필요하며 단순한 파일 이름 규칙만으로는 충분하지 않습니다. .env 실질적인 문제는 간단합니다: 동일한 코드베이스를 여러 환경으로 배포하는 방법은 다시 빌드, 다시 서명하거나 매 구성 변경마다 네이티브 앱을 제출하는 것 없이 무엇입니까? differences between development and production in Capacitor apps 컨텍스트: Capgo 마케팅 웹사이트. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 위치: 페이지 blog/[slug].astro. 메시지 키 `table_of_contents` (목차)

환경 설정이 프로덕션 앱을 망치기 시작하는 이유

드립은 무해한 예외로 시작합니다

환경 설정
- 환경 설정은 배포에 특정한 설정, 예를 들어 __CAPGO_KEEP_0__ 엔드포인트, 기능 플래그, 데이터베이스 인증 정보 및 제 3 자 키를 애플리케이션 __CAPGO_KEEP_1__에서 분리하는 학문입니다. __CAPGO_KEEP_2__ 및 Electron 앱에서 분리는 더 어려울 수 있습니다. 웹 자산이 네이티브 컨테이너 내부에 패키징되기 때문에, 구성 오류는 서버에서 변경할 수 있는 값이 아닌 서명된 아티팩트의 일부가 될 수 있습니다.
- 빌드 시 구성이 릴리즈 병목 현상을 발생시킨다
네 가지 주요 구성 패턴을 비교한다
보안과 CI/CD implication을 무시할 수 없다
- pipeline에서 구성이 누출된다
- 보안은 릴리즈 속도와 공존해야 한다
Implementing Environment Config in Capacitor and Electron
Capgo을 사용하여 목표 업데이트 및 롤백을 단순화합니다.
- 채널은 환경 소유권을 명확하게 합니다.
환경 설정 감사 목록

생산 앱이 환경 설정으로 깨질 때의 이유

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

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

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

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

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

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

실용적인 규칙: 설정 값이 애플리케이션 로직과 독립적으로 변경될 수 있다면, 이를 배포 입력으로 대신 소스 code로 처리해야 합니다.

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

배포 시점에 빌드 시간 설정이 생성되는 문제:

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

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

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

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

애플리케이션 논리, 환경이 달라져도 동일하게 유지되어야 하는 것이어야 합니다.
환경 구성, 엔드포인트, 플래그 및 비_sensitive 런타임 동작을 선택합니다.
비밀 자료, 제어된 저장소에 속해야 하며 필요할 때만 주입되어야 합니다.

이러한 분리는 드리프트를 가시화합니다. 또한 프로덕션에서 다른 동작을 하는 경우 팀은 구성 입력을 비교하여 code을 비난하기 전에 명확한 대답을 얻을 수 있습니다.

네 가지 주요 구성 패턴 비교

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

12-Factor 패턴 1, 12-Factor 환경 변수

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

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

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

__CAPGO_KEEP_0__

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

이 접근 방식의 약점은 아티팩트 분열입니다. 세 빌드는 다른 동작을 포함할 수 있습니다. 특히 조건부 컴파일 또는 플랫폼 특정 스크립트가 pipe line에 침투할 때 특히 그렇습니다. 모든 구성 변경은 새로운 빌드를 생성하고 서명, 인증, 스토어 처리 또는 수동 릴리스 조정과 같은 다른 작업을 트리거할 수 있습니다.

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

패턴 3, 런타임 구성

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

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

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

네 번째 패턴, 전용 비밀 관리

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

그들은 클라이언트-비밀 문제를 해결하지 못합니다. 장치의 소유자만이 장치의 내용을 검사할 수 있는 경우, 모바일 또는 데스크톱 클라이언트로 비밀을 전달하는 경우 일반적으로 클라이언트 애플리케이션은 유출될 수 있는 값을 받을 수 없습니다. 반면에 특권된 작업은 백엔드 뒤에 남아야 합니다.

패턴	빌드 복잡도	재 제출이 필요합니다.	롤백 속도	최적의 경우
12-Factor 변수	서버의 경우 낮고, 하이브리드 빌드의 경우 중간	일반적으로, 클라이언트로 묶인 값에 대해	보통	백엔드 서비스 및 공개 빌드 입력
환경별 빌드	환경이 증가할수록 보통	값이 변경될 때, 묶인 값	보통에서 느림	작은 팀 및 자주 업데이트하지 않는 경우
런타임 구성	보통	호환되는 웹 층의 변경은 제외	버전이 지정된 페이로드와 함께 빠름	변경 가능한 엔드포인트, 플래그 및 클라이언트 동작
비밀 관리 플랫폼	중간에서 높은 수준	백엔드 전용 비밀에 대해 사용하지 않음	서버 소비자에게 빠르다	권한이 있는 백엔드 인증서

단일 앱에 작업하는 팀이 간헐적으로 릴리즈를 할 수 있다면, per-environment 빌드와 엄격한 검증을 시작할 수 있다. 병행 스테이징과 프로덕션 작업이 필요한 성장하는 팀은 artifact 분산을 줄이기 위해 런타임层를 필요로 한다. 고속 릴리즈 팀은 immutable 애플리케이션 번들, 런타임 구성, 백엔드 인증서의 비밀 관리자를 combine해야 한다. Capacitor의 기능 플래그 구현 지침 __CAPGO_KEEP_0__의 기능 플래그 구현 지침은 런타임 layer에 들어맞는다. 제공된 플래그가 scope, audit, safe to expose to client로 scope되어야 한다.

보안 및 CI/CD의 중요하지 않은 implication

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

공개 식별자 및 클라이언트 사이드 설정은 비밀과 다르다. 모바일 API 키가 애플리케이션을 식별하기만 한다면, 제공자가 키가 bundle에 존재하고, 키의 사용을 제한한다면, 키가 안전할 수 있다. 그러나 데이터베이스 인증서, 서명 비밀, 권한이 있는 토큰, 또는 제한되지 않은 서비스 인증서는 같은 위치에 안전하지 않다. OWASP SAMM은 비밀을 분리하거나 암호화하여 프로덕션 비밀을 관리하고, 비밀의 라이프 사이클을 관리하는 대신, 비밀을 관리해야 한다.

CI/CD pipeline에서 하드 코딩된 비밀을 포함하는 3 단계의 보안 위험을 보여주는 다이어그램입니다.

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

CI/CD 시스템은 평범한 방식으로 실패합니다. 셸 명령어는 확장된 변수를 출력하고, 빌드가 실패하면 예외에 비밀을 포함하거나 디버깅 단계에서 환경 덤프를 기록합니다. 또한, Git 저장소에 파일이 포함될 수 있습니다. 저장소가 이전에 완전하지 않은 Git 저장소를 상속받았기 때문입니다. .env.production _sensitive한 값은 안전한 저장소에 저장하고 pipeline의 권한을 좁게 유지하세요. 빌드 작업은 해당 목적에 필요한 값만 받을 수 있어야 하며, 로그는 그 값을 가립니다. 생성된 자바스크립트, 네이티브 리소스, Electron 아카이브, 및 소스 맵을 포함하여 의도치 않은 포함을 검토하세요. 원격으로 전달된 구성 파일의 체크섬 또는 서명은 도난을 감지하는 데 도움이 될 수 있지만, 클라이언트가 볼 수 있는 값을 비밀로 만드는 것은 아닙니다. .gitignore.

분석 또는 다른 sensitive한 데이터를 처리하는 팀은 ELECTE의 AI 분석에 대한 보안 백서를 사용하여 별도의 리소스를 사용할 수 있습니다.

보안은 릴리스 속도와 공존해야 합니다. 보안은 릴리스 속도와 공존해야 합니다. 보안은 릴리스 속도와 공존해야 합니다.

보안 백서

생산 환경의 비밀 키를 안전하게 관리하는 패턴은 저장, 전송 및 저장 시 암호화, 최소 권한 접근, 및 회전입니다. mutable public endpoint의 경우, 안전한 패턴은 다릅니다. endpoint는 버전화된 런타임 문서를 통해 전달, 사용 전에 검증, 그리고 잘못된 값이 닫히도록 제한될 수 있습니다.

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

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

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

The CI/CD Capacitor 관리 방법 __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

그것들을

에 저장하세요. 그러나 비공개 인증서를 저장하지 마세요. Capacitor local environment setup guide 생산 앱은 스테이징 서비스 인증서를 재사용하지 않아야 합니다.

__CAPGO_KEEP_0__ 로컬 환경 설정 가이드

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

// 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))
  }),
})

renderer에서 다시 객체를 검증하세요. 브릿지는 공개 런타임 값을 노출해야 하며, 비밀 저장소 토큰이나 특권 파일 시스템 기능은 절대 노출하지 마세요.

Aspect	Capacitor	Capacitor
Electron	Main configuration boundary	자연스러운 Native 프로젝트와 웹 자산
Main process, preload, and renderer	안전한 클라이언트 값	공개된 엔드포인트 및 플래그
프리로드를 통해 전달된 공개된 엔드포인트 및 플래그	앱 번들에서 제외하세요	패키지된 아카이브에서 제외하세요
일반적인 실패	자연 동기화 후 빌드 값이陈舊해짐	`process.env` 렌더러에서 사용할 수 없음
런타임 업데이트 경로	서명된 웹 번들 또는 원격 구성	서명된 웹 번들 또는 제어된 애플리케이션 업데이트

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

Simplifying Targeted Updates and Rollbacks with Capgo

__CAPGO_KEEP_0__

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

A comparison chart showing traditional app configuration workflows versus instant updates and rollbacks using Capgo platform.

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__에 대한 플랫폼 규칙을 우회하지 않으며, 비밀을 안전하게 배포하지 않습니다. 그러나 호환 가능한 웹 레이어 구성에 대한 수정 시간을 줄입니다.

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

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

결과는 다음과 같습니다.

개발 단계에서 빌드 및 버전을 검증합니다.
테스트된 콘텐츠를 스테이징으로 승격합니다.
제품 채널 업데이트 승인합니다.
수용률과 실패를 모니터링합니다.
구성 동작이 잘못되면 채널을 되돌립니다.

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

환경 구성 감사 목록

매JOR 릴리스 전에 및 pipeline 변경 후에 이 감사 목록을 실행합니다.

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

환경 설정 감사 체크리스트

설정 감사는 모든 프로덕션 설정 값의 소유자, 원본, 범위 및 롤백 절차를 식별할 수 있는 사람만이 완료할 수 있습니다.

Capgo는 CapacitorJS 및 Electron 앱에 대한 서명된 라이브 업데이트를 제공하며, 대상 채널 및 버전 롤백을 포함하여 호환되는 자바스크립트, CSS, 구성 및 자산 변경에 대한 대상 채널 및 버전 롤백을 제공합니다. 팀이 환경 업데이트 관리를 통제하면서 재빌드 사이클을 줄이고 싶다면 Capgo를 방문하세요. Capgo 및 CI/CD 프로세스와 함께 평가하세요.

현대 앱의 환경 설정

드립은 무해한 예외로 시작합니다

생산 앱이 환경 설정으로 깨질 때의 이유

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

배포 시점에 빌드 시간 설정이 생성되는 문제:

네 가지 주요 구성 패턴 비교

12-Factor 패턴 1, 12-Factor 환경 변수

__CAPGO_KEEP_0__

패턴 3, 런타임 구성

네 번째 패턴, 전용 비밀 관리

보안 및 CI/CD의 중요하지 않은 implication

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

보안 백서

Capacitor와 Electron에서 환경 설정 구현

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

Capacitor native configuration

__CAPGO_KEEP_0__ 로컬 환경 설정 가이드

Simplifying Targeted Updates and Rollbacks with Capgo

환경 구성 감사 목록