최신 앱을 위한 환경 설정

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

그런 실패는 이상하지 않습니다. 환경 설정 배포에 특정한 설정, 예를 들어 API 엔드포인트, 기능 플래그, 데이터베이스 인증서, 세 번째 키와 같은 것을 애플리케이션 code에서 분리하는 것입니다. Capacitor와 Electron 앱에서 분리는 더 어려울 수 있습니다. 왜냐하면 웹 자산이 네이티브 컨테이너 내부에 패키징되기 때문입니다. 그래서 설정 오류는 서명된 아티팩트의 일부가 될 수 있고 서버에서 변경할 수 있는 값이 아닙니다.

더 깊은 문제는 설정 드리프트개발, 테스트, 운영 환경 간 점진적인 분기. 개발자는 하나의 .env 개발과 프로덕션 간의 차이를 이해하는 팀은 명백한 오류를 피할 수 있지만 드리프트는 운영 모델이 필요합니다. 단순히 파일 이름 규칙을 개선하는 것만으로는 충분하지 않습니다. differences between development and production in Capacitor apps __CAPGO_KEEP_2__와 Electron 앱에서 분리는 더 어려울 수 있습니다.

실무적인 질문은 간단합니다: 여러 환경에 동일한 코드베이스를 어떻게 배포할 수 있고, 매번 환경 설정 변경 시 재빌드, 재서명, 또는 네이티브 앱 제출을 반복할 수 없을까요?

목차

• 환경 설정이 프로덕션 앱을 망치게 하는 이유
  • 해로운 예외부터 시작된다
  • 빌드 시 환경 설정이 릴리즈 병목 현상을 만든다
• 네 가지 주요 환경 설정 패턴을 비교한다
  • 패턴 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로 간주하지 말고 배포 입력으로 다루세요.

production 환경에서 충분히 유사한 스테이징 환경이 통합 문제를 노출하고 여전히 격리 된 엔드포인트, 자격 증명 및 데이터를 사용해야 합니다. 환경이 분리되면 스테이징이 유용한 연습이 더 이상되지 않습니다. 릴리스는 한 세트의 가정에 대해 모든 테스트를 통과하고 다른 세트의 가정에 대해 즉시 실패할 수 있습니다.

빌드 시 구성은 릴리스 병목 현상을 생성합니다.

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

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

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

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

1. 애플리케이션 논리환경 구성
2. 비밀 자료애플리케이션 논리는 환경에 관계없이 동일해야 합니다.
3. 환경 구성은 엔드포인트, 플래그 및 비_sensitive 런타임 동작을 선택합니다.환경 설정은 제어된 저장소에 속하며 필요할 때만 주입되어야 합니다.

이 분리는 이탈을 드러내고 또한 프로덕션에서 다른 행동을 보인다면, 프로덕션의 입력을 비교하여 code을 비난하지 말라고 팀에게 명확한 답을 주는 것입니다.

네 가지 주요 환경 설정 패턴을 비교합니다.

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

12-Factor 환경 변수 패턴 1

12-Factor 모델은 환경 설정을 환경에 따라 입력하는 것으로 대신 hardcoded 애플리케이션 상태로 다루지 않습니다. 서버 프로세스, 컨테이너, CI 작업과 같은 경우 자연스럽게 작동합니다. 서비스는 시작 시 값을 읽을 수 있고 동일한 아티팩트를 여러 배포에서 사용할 수 있습니다.

클라이언트 측 앱은 모델을 복잡하게 만듭니다. 브라우저 자바스크립트에 의해 참조되는 값은 결국 클라이언트에 제공되어야 하므로, 환경 변수를 통해 도착한 값만으로 비밀로 다루면 안됩니다. 공개 API 원본 또는 기능 플래그는 빌드 타임 Substitution을 사용할 수 있지만 의미 있는 권한을 가진 자격 증명은 반대할 수 있는 클라이언트 배ंडल에 배송되어서는 안됩니다.

Capacitor 및 Electron의 경우 이 패턴은 빌드 오케스트레이션 및 공개 환경 설정보안을 위한 비밀을 보호하는 것이 아니고, conceptual overhead가 낮지만, runtime mutability가 제한적일 수 있다. 다른 배포層이 존재하지 않는다면.

두 번째 패턴, 환경별 빌드

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

약점은 artifact 분산이다. 세 빌드는 다른 동작을 포함할 수 있다. 특히 조건부 컴파일 또는 플랫폼 특정 스크립트가 pipe라인에 포함될 때, 설정만 다를 뿐이다. 각 구성 변경은 다른 빌드를 생성하고, 서명, notarization, 스토어 처리, 또는 수동 릴리즈 조정과 같은 동작을 트리거할 수 있다.

롤백도 artifact 배포와 관련된다. 이전 버전의 바이너리로 롤백할 수 있지만, 사용자는 이미 다른 버전을 설치할 수 있고, 롤백 경로는 배포 채널에 따라 달라진다.

세 번째 패턴, 런타임 구성

런타임 구성은 mutable 값을 native artifact 외부로 이동한다. 애플리케이션은 런타임에 구성 문서를 가져오거나, 이전에 전달된 문서를 로컬 캐시에서 읽는다. 이 방식은 애플리케이션 code을 변경하지 않고도 엔드포인트와 플래그를 수정할 수 있다.

트레이드 오프는 새로운 스타트업 의존성이 필요합니다. remote configuration service 가 unavailable 일 때, 앱은 안전한 캐시, bounded timeout, 그리고 알려진 fallback 정책이 필요합니다. fallback 은 절대 잘못된 환경을 가리키면 안됩니다. 문서의 schema 를 검증하고, 적절한 경우 소스 인증을 하며, 앱이 적용한 configuration 버전을 기록해야 합니다.

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

4. 패턴, 전용 비밀 관리

HashiCorp Vault 및 AWS Secrets Manager와 같은 플랫폼은 sensitive backend material을 제어하기 위해 설계되었습니다. 그들은 access 정책, audit 트레일, 암호화, rotation 워크플로우를 지원합니다. 따라서 서버 사이드 서비스가 secret store에 인증할 수 있는 경우, 사용자에게 credential을 노출하지 않고 secret을 관리할 수 있습니다.

그들은 클라이언트-비밀 문제를 해결하지 못합니다. 장치의 소유자만이 장치의 내용을 검토할 수 있는 경우, secret이 모바일 또는 데스크톱 클라이언트로 전달될 수 있습니다. 클라이언트 앱은 공개할 수 있는 값만 받을 수 있어야 하며, 특권된 작업은 백엔드 뒤에 남아야 합니다.

단일 앱에 작업하는 팀이 간헐적인 릴리즈를 진행할 경우, 환경별 빌드와 엄격한 검증을 시작할 수 있습니다. 병렬 스테이징 및 프로덕션 작업을 진행하는 성장하는 팀은 런타임层를 사용하여 아티팩트 분기화를 줄일 수 있습니다. 고속 릴리즈 팀은 immutable 애플리케이션 번들, 런타임 구성, 백엔드 인증서를 위한 비밀 관리자를 combination하여 사용해야 합니다. Capacitor feature flag 구현 지침이 런타임 layer에 포함되어, 플래그가 scope, audited, client로 노출될 수 있는 안전한지 확인되어야 합니다.

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

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

공개 식별자와 클라이언트 측 설정은 비밀과 다릅니다. 모바일 API 키가 애플리케이션을 식별하기만 하면, 제공자가 그것을 기대하고 제한된 사용을 하는 경우에는 번들에 포함할 수 있습니다. 데이터베이스 인증 정보, 서명 비밀, 특권 토큰 또는 제한되지 않은 서비스 인증 정보는 같은 곳에 안전하지 않습니다. OWASP SAMM은 의무를 분리하거나 프로덕션 비밀을 암호화하여 레포지토리에 비밀을 보호하지 않도록 방지하고 그 생애주기를 관리하는 것이 좋습니다. 이로 인한 사고를 기다리지 않고.

pipeline에서 구성이 누출되는 곳

CI/CD 시스템은 평범한 방식으로 실패합니다. 셸 명령어가 확장 변수를 출력하거나 빌드가 실패하여 비밀을 예외에 포함하거나 디버깅 단계에서 환경 덤프를 기록하는 등. A .env.production 파일도 버전 제어에 포함될 수 있습니다. 레포지토리가 완전하지 않은 경우에. .gitignore.

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

분석 또는 다른 sensitive 데이터를 처리하는 팀은 ELECTE의 별도의 리소스를 사용할 수 있습니다. AI 분석을 위한 보안 백서 보다 광범위한 데이터 보호 책임을 검토할 때.

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

생산 시크릿의 보안 패턴은 제어된 저장, 전송 및 저장 중 암호화, 최소 권한 접근, 및 회전입니다. mutable public endpoint의 경우 보안 패턴은 다릅니다. endpoint는 버전화된 런타임 문서를 통해 전달되고, 사용 전에 검증되고, 그리고 잘못된 값이 닫힌 경우에만 제한됩니다.

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

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

• 소스 제어: 구성 파일과 안전한 예시를 커밋하고, 라이브 시크릿은 커밋하지 마십시오.
• 빌드 단계: 만들어야 하는 artifact를 생성하기 위해 필요한 값만 주입하고, 로그에서 시크릿 확장을 방지하십시오.
• 배포 단계: 인증된, 관찰 가능한 채널을 통해 환경에 따라 런타임 번들을 적용하십시오.
• 회전 단계: 정기적으로 정의된 일정에 따라 백엔드 인증서를 취소하고 교체하고, 즉시 무효화할 수 있는 경로를 제공합니다.

The Capacitor 팀의 CI/CD 비밀 관리 관행 __CAPGO_KEEP_0__ 팀의 CI/CD 비밀 관리 관행은 명시적인 항목 목록과 함께 pair될 때 가장 유용합니다. 변수 하나당, 공개 또는 민감한 항목인지, 소유주가 누구인지, 어떤 환경에서 사용하는지, 그리고 변경이 원본 재빌드가 필요할 때인지 문서화합니다.

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

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

정의하고 유효성 검사하는 하나의 계약

Vite와 함께, 클라이언트 노출 변수는 일반적으로 VITE_ prefix. 그 prefix는 보안 경계가 아닌 가시성 신호입니다.

// 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'],
  }
}

Call loadConfig() 개발자 도구에서 앱플로우를 사용하는 경우, 앱플로우와 카프고를 비교하고 migrate하는 단계입니다.

애플리케이션 시작 시에 발생합니다. 값이 누락된 경우, 명확한 오류를 출력하고 지역 엔드포인트를 선택하지 않도록 합니다. 단일 결정은 생산 오류 경로의 큰 클래스를 방지합니다. .env.staging로컬 작업을 위해, Vite는 적절한 파일을 선택할 수 있습니다. .env.production로컬 빌드는

Capacitor 원시 설정

를 사용합니다. CI 작업은 개발자가 로컬에서 사용한 것을 상속하는 대신, 명시적으로 모드를 설정해야 합니다. capacitor.config.ts__CAPGO_KEEP_0__ 네이티브 구성

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

네이티브 프로젝트는 종종 환경에 따라 식별자, 서비스 파일, 또는 플러그인 설정이 필요합니다. 이러한 값을

The Capacitor 로컬 환경 설정 가이드 팀이 지역 모드를 표준화할 수 있지만, 저장소는 명시적인 계약과 CI 검증이 필요합니다.

Electron은 프로세스 경계가 필요합니다.

Electron의 렌더러는 Node.js의 메인 프로세스와 다릅니다. 보안이 강화된 애플리케이션에서, process.env 렌더러에서 객체를 다시 검증하십시오. 브리지는 공개 런타임 값만 노출해야 하며, 비밀 저장소 토큰이나 특권 파일 시스템 기능은 절대 노출하지 않아야 합니다.

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

Aspect

가장 일반적인 구현 오류는 가정하는 것입니다 .env 파일들은 자동으로 비공개됩니다. 번들러는 생성된 자바스크립트에 해당 값을 포함할 수 있으며 패키징 단계에서는 파일 자체를 포함할 수 있습니다. 최종 아티팩트를 검사하는 대신 소스树만 검사하는 것보다 더 좋습니다.

Capgo를 사용하여 목표 업데이트 및 롤백을 단순화합니다.

disciplined 빌드 타임 설정도 운영적으론 어려운 단계를 남깁니다. 공개 엔드포인트가 릴리즈 후에 변경되면 네이티브 앱은 여전히 이전 값을 포함할 수 있습니다. 새로운 바이너리를 재빌드하고 배포하는 것은 웹层만 변경되는 경우 과도한 작업입니다.

Capgo의 라이브 업데이트 모델은 이 단계를 채우기 위해 목표 채널 개발, 스테이징 및 프로덕션과 같은 배포 계층에 대한 채널입니다. 팀은 변경된 환경에 맞는 signed 자바스크립트, CSS, 구성 또는 자산 번들을 해당 채널에 게시할 수 있습니다. 네이티브 셸은 설치된 채로 앱이 다음 런칭 시 호환 가능한 업데이트 적용합니다.

예상치 못한 프로덕션 API 엔드포인트가 변경되면 팀은 구성 소스 업데이트, 웹 번들을 빌드하고 프로덕션 채널에 게시할 수 있습니다. 네이티브 스토어 릴리즈를 기다리지 않고 시간을 절약할 수 있습니다. 중요한 경계는 여전히 유지됩니다: 이 접근 방식은 네이티브 code에 대한 플랫폼 규칙을 우회하지 않으며 비밀을 안전하게 배포하지 않습니다. 웹 레이어 구성만 변경하는 경우 시간을 절약할 수 있습니다.

채널은 환경 소유권을 명확하게 합니다.

채널은 환경에 매핑되어야 하며, 개발자 개인의 선호도에 매핑되어서는 안 됩니다. 개발자 테스터는 개발 콘텐츠를, 스테이징 사용자는 스테이징 콘텐츠를, 그리고 프로덕션 사용자는 프로덕션에 승인된 번들을 받습니다. CI는 해당 빌드 및 검증 단계가 완료된 후 적절한 번들을 게시할 수 있습니다.

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

결과는 다음과 같습니다:

1. 개발 버전의 번들을 빌드하고 검증하세요.
2. 테스트된 콘텐츠를 스테이징으로 승격하세요.
3. 프로덕션 채널 업데이트 승인하세요.
4. 수용률과 실패를 모니터링하세요.
5. 채널이 잘못된 구성으로 동작하는 경우 채널을 롤백하세요.

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

환경 구성 감사 목록

이 감사는 매JOR 릴리스 전에 그리고 pipeline 변경 후에 실행해야 합니다.

• 아티팩트를 검사하세요: 커밋된 파일, 생성된 자바스크립트, 네이티브 리소스, 소스 맵, 또는 Electron 아카이브에 비밀 정보가 나타나지 않는지 확인하세요.
• 분리된 환경: 개발, 스테이징, 및 프로덕션 환경이 DISTINCT 엔드포인트, 식별자, 및 승인된 키를 사용하는지 확인하세요.
• 입력 보호: 모든 .env 변형은 무시되며 .env.example 필요한 스키마를 문서화합니다.
• CI 검토: pipeline가 개발자의 로컬 머신에 의존하지 않고 제어된 저장소에서 값을 주입하는지 확인하세요.
• 회복 테스트: 실시간 구성이 필요한 값이 누락된 경우 빠르게 실패하고, 호환 가능한 업데이트 rollback이 native shell을 재구성하지 않고 수행될 수 있는지 확인합니다.

감사는 완료되면 누군가가 모든 프로덕션 구성 값의 소유주, 원천, 범위 및 롤백 절차를 식별할 수 있어야 합니다.

Capgo은 CapacitorJS 및 Electron 앱에 대한 서명된 라이브 업데이트, 대상 채널 및 호환 가능한 자바스크립트, CSS, 구성 및 자산 변경에 대한 버전 롤백을 제공합니다. 팀이 환경 업데이트 관리를 통한 재구성 주기를 줄이려면 Capgo을 방문하고 Capgo 그것을 팀의 기존 CI/CD 프로세스와 함께 평가하세요.