프로젝트를 열면 build:ios:dev, build:android:qa, build:staging, build:release, build:prod, 그리고 몇 개의 shell 스크립트 nobody가 조작하고 싶어하지 않습니다. 그 다음 누군가가 말합니다, “클라이언트에게 스테이징 빌드를 마감일까지 만들 수 있나요?” 만약 당신이 중급 모바일 개발자라면, 이 요청은 종종 매우 모호하게 느껴집니다. 어떤 설정을 사용해야 하나요? 어떤 인증 식별자를 사용해야 하나요? 어떤 백엔드를 사용해야 하나요? 어떤 배포 경로를 사용해야 하나요?
이러한 혼란은 일반적으로 빌드 종류를 평평한 목록으로 다루는 데서 비롯됩니다. 아니다. 그것들은 워크플로입니다. 각 빌드는 특정 문제를 해결하기 위해 특정 위치에서 사용자의 장치에 있는 위치 사이에 존재합니다.
빌드는 단순히 컴파일된 앱이 아닙니다. 그것은 목적, 대상 audience, 및 환경에 맞춰 조립된 앱 버전입니다. 일부 빌드는 디버깅을 도와주기 위해 존재합니다. 일부 빌드는 QA가 안전하게 깨지도록 도와주기 위해 존재합니다. 일부 빌드는 릴리스 엔지니어링이 신뢰할 수 있는 아티팩트를 생성할 수 있도록 도와주기 위해 존재합니다. 일부 빌드는 제품 팀이 변경 사항을 덜 위험하게 배포할 수 있도록 도와주기 위해 존재합니다.
만약 당신의 로컬 설정이 아직도 시작하기 전에 불안정하게 느껴진다면, 먼저 올바른 Capacitor 로컬 환경 설정을 사용하여 그 문제를 해결하세요. 빌드 복잡성은 예측 가능한 기본 도구가 있는 경우 더 쉽게 이해됩니다.
목차
- 소프트웨어 빌드의 세계를 풀어헤치기
- 빌드 스펙트럼: 로컬 vs CI 빌드
- 기본 빌드 맛집 Debug vs Release
- 빌드 매핑을 분배 환경으로
- Code 서명의 крит적 역할
- CI/CD와 업데이트 채널을 이용한 릴리즈 조정
- Modern 빌드 워크플로우의最佳 관행
소프트웨어 빌드의 세계를 단단히 하기
가장 흔한 실수는 빌드 이름이 모든 이야기를 전달한다고 가정하는 것입니다. 하지만 그렇지 않습니다. staging 이 단어는 다른 저장소에서 "스테이징 API를 향한 릴리스 맛"을 의미할 수 있고, 다른 저장소에서는 "테스트 가능한 QA 아티팩트에 대한 모의 결제"를 의미할 수 있고, 다른 저장소에서는 "개인적으로 배포되는 프로덕션에 서명된 빌드"를 의미할 수 있습니다.
이것이 왜 팀이 엉켜있는지 이유입니다. 레이블은 빌드가 수행하는 작업을 이해하는 경우에만 유용합니다.
빌드의 유형에 대한 유용한 방법은 다음과 같습니다:
- 로컬 빌드 개발자를 빠르게 움직여 줄 수 있는 도움을 줄 수 있습니다.
- CI 빌드 팀의 공유된 진실을 만들 수 있습니다.
- Debug 및 릴리즈 플래버 앱이 컴파일되고 측정되는 방법을 정의합니다.
- 배포 빌드 앱을 받을 사람과 어떻게 받을 것인지 정의합니다.
- 서명된 빌드 플랫폼이 아티팩트를 신뢰할지 결정합니다.
- 채널 기반 업데이트 설치 후 변경 사항이 어떻게 이동할지 결정합니다.
그것들은 경쟁하는 범주가 아닙니다. 그들은 쌓입니다.
‘스테이징 빌드’는 거의 단일한 것이 아닙니다. 일반적으로 맛, 환경, 서명, 배포 방법의 combination입니다.
이것이 두 팀이 모두 ‘베타 빌드’가 필요하다고 말할 수 있는 이유입니다. 완전히 다른 artifact를 의미합니다.
이것은 모바일에서 가장 중요합니다. 각 단계가 마찰을 일으키기 때문입니다. 네이티브 컴파일, 비밀, 배포, 앱 스토어 트랙, 테스터 접근, 환경 설정, 롤백 모두 일치해야 합니다. 하나의 부분이 느슨하면 릴리스 프로세스가 민감한 지식이 됩니다. 그때 한 엔지니어가 휴가에 가면 nobody가 깨끗하게 배포할 수 없습니다.
이러한 팀은 스크립트를 더 기억하지 않습니다. 빌드 유형을 품질 게이트로 정의합니다. 각 게이트는 다른 종류의 위험을 낮춥니다: 깨진 code, 잘못된 설정, 나쁜 서명, 나쁜 롤아웃, 나쁜 복구.
빌드 스펙트럼 Local vs CI Builds
Local 빌드는 개인용 빌드입니다. CI 빌드는 팀이 신뢰할 수 있는 빌드입니다.
이것은 명백한 것처럼 보이지만, 많은 빌드 고통이 팀이 두 가지를 혼용할 때 시작됩니다. alguien이 ‘내 컴퓨터에서 작동한다’고 증명한 후 branch가 CI에서 실패할 때, implicitly 지역 환경이 cached dependency, manually edited file, 또는 signing asset가 automation에 들어가지 않았기 때문입니다.
로컬 빌드
Local 빌드는 개인용, 빠른, 그리고 버려질 수 있는 빌드입니다. 즉시 질문에 답하기 위해 사용합니다.
화면이 렌더링 될 수 있나요? 네이티브 플러그인이 초기화되나요? Gradle 또는 Xcode 변경이 컴파일을 중단했나요? 로깅을 높여서 충돌을 재현할 수 있나요?
좋은 로컬 빌드는 속도보다 절차를 우선합니다. 종종 느슨한 체크, 자세한 로그, 개발자 스위치, 임시 인스트루먼트를 포함합니다. 그건 괜찮습니다. 그것의 역할은 빠른-feedback입니다.
그러나 로컬 빌드를 더 중요한 것처럼 홍보하는 것은 잘못된 것입니다. 로컬 빌드는 한 대의 노트북에서 성공적으로 컴파일된 경우에만 릴리즈 아티팩트가 될 수 없습니다.
CI 빌드
CI 빌드는 속도 때문에 느립니다. CI 빌드는 개인 머신 상태를 변수로 제거하고 빌드 프로세스를 반복 가능하게 만듭니다.
CI가 건강할 때, 그것은 세 가지 일을 잘합니다:
- 새로 빌드하기: 그것은 프로젝트가 숨겨진 로컬 가정 없이 컴파일 될 수 있는지 증명합니다.
- 팀 수준 체크를 실행하기: 유닛 테스트, 린팅, 패키징 규칙은 항상 같은 장소에서 발생합니다.
- 추적 가능한 아티팩트를 생성하기: 팀은 빌드를 커밋, branch, pipeline run과 연결할 수 있습니다.
그것이 왜 나는 워크샵-공장 analogy를 좋아하는지 이유입니다. 你的 laptop은 반복을 위해 벤치입니다. CI는 프로세스가 실제인지 증명하는 assembly line입니다.
만약 팀이 여전히 스크립트가 어디서 실행되는지 수동으로 결정하고 있다면, 자동화에서 논리를 중앙화하세요. 실제 참고 자료는 __CAPGO_KEEP_0__ Actions를 사용하여 개발자와 프로덕션 빌드를 관리하는 이 안내서입니다. managing dev and prod builds with GitHub Actions.
만약 QA, 제품, 또는 지원이 아티팩트를 필요로 한다면, 그것은 개발자의 머신에서 아니라 CI에서 가져와야 합니다. 그것을 받아들이면 나머지 빌드 라이프 사이클이 더 쉬워집니다. Flavor 선택, 서명, 환경 주입, 그리고 배포는 모두 팀의 누구도 검사할 수 있는 pipeline에 속해야 합니다.
핵심 빌드 플레버 Debug vs Release
빌드에 사용되는 레이블이 많지만, 그 이름 아래에 두 가지 플레버가 가장 중요합니다:
debug release and release.
그것들은 개발자와 사용자가 반대되는 것을 필요로하기 때문입니다.
Debug Build
Debug Build는 인간이 동작을 검사하는 데 도움이 됩니다. 일반적으로 더 많은 메타데이터를 유지하고, 문제를 숨기지 않는 공격적인 최적화 방식을 피하며, 디버깅을 용이하게 합니다.
There's a useful analogy from construction specs. prescriptive, performance, proprietary, and reference-standard build types, 및 debug build은 잘 맞춰진다. prescriptive 분석을 위한 정확한 도구와 방법을 지정하기 때문에 빌드 방법은 분석에 사용되는 도구와 방법을 지정하는 접근 방식입니다. 반면에 릴리스 빌드는 성능 성능을 최적화하기 위한 접근 방식으로, 건설 사양 유형의 분해.
실제로 debug build는 다음과 같은 것들을 포함합니다:
- 읽기 쉬운 디버그 정보: 스택 추적, 콘솔 출력 및 오류를 찾는데 도움이 되는 심볼.
- 개발자 편의성: 모의 스위치, 테스트 메뉴 및 사용자에게 적합하지 않은 기능 Switch.
- 저항이 적은 반복: 빠른 설치 및 실행 주기가 더 중요합니다.
디버그 빌드는 "나쁜" 빌드가 아닙니다. 목적을 위해 설계되었습니다.
릴리즈 빌드
Release builds는 실제 기기에서 작동하는 데 사용됩니다. 그로 인해 우선순위가 즉시 변경됩니다.
이제 패키지完整성, 시작 동작, 보안 포지션, 작은 페이로드 및 예측 가능한 런타임 특성에 관심이 있습니다. 또한 검사 또는 부정사용을 위한 의도하지 않은 진입점이 적어야 합니다.
거래의 균형은 간단합니다. 디버그 빌드가 더 쉽게 검사되도록 하는 모든 것이 프로덕션에서 릴리스 빌드가 적절하지 않도록 만듭니다.
팀과 함께 사용하는 결정 경계는 다음과 같습니다:
| Flavor | Best for | 이것을 최적화합니다 |
|---|---|---|
| Debug | 개발, 로컬 테스트, 문제 재현 | visibility 및 반복 속도 |
| Release | 베타 배포, 스토어 제출, 프로덕션 론칭 | 안정성, 성능 및 신뢰성 |
왜 팀이 여전히 이것을 틀리게 하는가
혼동의 가장 큰 원인은 '환경'과 '맛'을 혼동하는 것이다.
빌드는 릴리즈 맛이 스테이징 서비스를 향하는 빌드이다.그것은 QA에서 일반적이다. 왜냐하면 비프로덕션 데이터와 프로덕션과 같은 동작을 원하기 때문이다. 빌드는 디버그 맛이 개발 서비스를 향하는 빌드이다. 일상적인 코딩을 위해. 그것은 다른 축이다.
많은 스크립트의 난잡함은 팀이 모든 가능한 combination을 패키지 이름에 인코딩하는 대신 매트릭스를 문서화하지 않기 때문이다.
사용자 대면 동작을 테스트하는 비개발자에게 릴리즈 맛을 배포할 때. 디버그 맛은 엔지니어링 작업과 의도적인 디버깅에 사용하라.
그것은 하나의 규칙이 많은 부차적인 복잡성을 제거한다.
빌드와 배포 환경 매핑
지속적인 빌드에 대한 토론은 종종 너무 일찍 끝나게 됩니다. 개발자들은 로컬, 디버그, 릴리즈 빌드에 대해 설명하고, 더 어려운 질문인 빌드가 어디로 가는지에 대해 무시합니다.
빌드의 목적지는 빌드가 포함해야 하는 내용, 빌드가 어떻게 서명되어야 하는지, 빌드가 누구에게 전달되어야 하는지에 영향을 줍니다.
실용적인 빌드 워크플로는 여러 환경을 거치며, 각 환경은 다른 사용자와 위험에 대한 tolerance를 가지고 있습니다. Capacitor 앱을 개발하는 경우, 개발과 운영 앱의 동작을 구분하는 것이 도움이 됩니다. 개발과 운영 앱의 동작을 구분하는 것은 Capacitor에서 중요합니다.빌드 버그는 실제로 환경 매핑 오류로 인해 발생하는 경우가 많습니다.
밤과 개구리
이것들은 엔지니어, QA, 또는 내부 그룹에 대한 작은 오디언스에게 노출되는 빌드입니다. 이들은 불완전한 모양을 tolerate하는 사람들에게 제공됩니다.
밤 빌드는 일정에 따라 생성되거나 최신 메인 branch 상태에서 생성됩니다. 개구리 빌드는 더 넓은 롤아웃 전에 좁은 오디언스에게 노출됩니다. 나는 이들을 안정성의 약속이 아닌 학습 도구로 다룹니다.
이것들은 다음과 같은 질문에 답할 때 유용합니다:
- 모듈 간에 branch가 통합되는지 여부
- 특정 장치 패밀리의 native dependency 업그레이드가 특정 장치 패밀리를 깨트렸는지 여부
- 내부 테스터가 더 넓은 베타 노출 전에 회귀를 감지할 수 있는지 여부
사람들은 완성된 소프트웨어를 기대하기 때문에 카나리 빌드를 제공하는 것은 실패한다. noisy feedback이 발생하고, 정상적인 churn을 릴리즈 문제로 부르는 오해가 생긴다.
Staging 및 beta
이 시점에서 제품 품질이 엔지니어링의 편의보다 더 중요해진다.
스테이징 빌드나 베타 빌드는 실제 사용자들이 받을 것과 비슷한 느낌을 주어야 한다. 일반적으로 릴리즈 버전의 맛을 내고, 가능한한 프로덕션과 같은 설정을 사용하고, 플랫폼 도구인 TestFlight 또는 Google Play 테스트 트랙을 통해 제어된 배포를 해야 한다.
이 시점에서 대상이 바뀐다:
- QA 팀은 회귀, 워크플로우 및 승인 기준을 검증한다.
- 제품 매니저는 실제 사용자 흐름을 평가하는 동안 유사한 환경에서 동작을 검토한다.
- 외부 테스터는 사용성, 장치 지원 및 에지 케이스를 검증한다.
- 지원 또는 성공 팀은 미래의 변경 사항을 미리 예상한다.
이러한 오류는 베타를 “debug 빌드”로만 생각하는 것이다. 테스터가 실제 사용자 흐름을 평가한다면 릴리즈와 같은 조건이 필요하다.
Private 배포 빌드
어떤 앱은 공공 스토어 사용자에게 절대 배포되지 않거나 더 좁은 그룹에 먼저 도달해야 하는 경우가 있다.
이것은 고객 전용 빌드, 내부 직원 앱, 규제된 워크플로우, field 운영 도구 및 기업 전용 배포를 포함합니다. 이들은 종종 앱을 설치할 수 있는 사람과 백엔드에 연결할 수 있는 사람에 대한 엄격한 제어가 필요합니다.
이것은 이름이 위험해지는 곳입니다. 팀들은 종종 “기업 빌드”라고 말하지만 실제로는 여러 가지 다른 것을 의미합니다:
- privately signed 내부 앱
- 스토어에 배포된 앱에 내부 전용 접근 제어
- 고객 전용 브랜딩된 아티팩트
- 주주에 대한 검토를 위해 스테이징 릴리스 후보
이것들은 다른 운영 모델입니다. pipeline과 이름에서 분리하세요.
Production
제품 빌드는 사용자에게 공개된 약속입니다. 앱 스토어, 플레이 스토어 또는 사용자에게 승인된 채널로 이동합니다.
이 시점에서 빌드는 재미없어야 합니다. 그것은 칭찬입니다.
제품 빌드는 재현 가능해야 하며, 올바르게 서명되어야 하며, 릴리스 조건에서 테스트되어야 하며, 롤백 계획과 연결되어야 합니다. 마지막 순간的手수작업 편집, 기계에 특정한 HACK, 또는 “다음 빌드에서 고쳐질 것”의 compromis를 원하지 않습니다.
이것은 한눈에 볼 수 있는 버전입니다.
소프트웨어 빌드 유형 및 특성
| 빌드 유형 | 대상 | Configuration | 구성 |
|---|---|---|---|
| 배포 방법 | 지역 개발자 | 개인 개발자 | 일반적으로 디버그, 빠른 반복, 로컬 환경 설정 |
| 직접 로컬 머신에서 설치 | CI 검증 | 엔지니어링 팀 | CI artifact storage |
| 밤이나 카나리 | 내부 테스터, 선택된 팀원 | 내부 테스트 환경, 제한된 배포 | 내부 배포 도구 |
| 스테이징 또는 베타 | QA, 제품, 외부 테스터 | 일반적으로 릴리즈와 같은 비공개 환경 매핑 | 테스트 플라이트, 플레이 테스트 트랙, 개인 링크 |
| 어드혹 또는 기업 | 내부 직원, 고객, 제한된 그룹 | 제어된 구성, 목적지에 특화된 서명 | 개인 배포 채널 |
| 제품 | 공개 사용자 | 최종 릴리즈 구성, 저장소 준비 서명 | 애플 스토어 또는 구글 플레이 |
올바른 빌드 유형은 사용자의 위험 감수 능력에 맞는 유형입니다. 대부분의 릴리즈 오류가 발생하는 이유는 팀이 그에 대한 조정을 생략했기 때문입니다.
Code 서명의 결정적 역할
모바일에서 빌드 파일 자체는 별로 의미가 없습니다. 플랫폼은 빌드가 신뢰할 수 있는 출처에서 왔으며 생성 후 nobody가 변경하지 않았다는 것을 증명해야 합니다. 그 증명은 code 서명.
빌드가 완벽하게 컴파일되었지만 설치, 업로드 또는 실행이 올바르게 작동하지 않은 경우 서명이 문제였을 것입니다.
__CAPGO_KEEP_0__가 실제로 증명하는 것은 무엇입니까?
code
- 인증 앱을 개발한 개발자 또는 조직과 연결시킵니다.
- 정확성 앱이 서명된 이후에 손상되지 않았는지 증명합니다.
- 권한 특히 애플 플랫폼에서, 앱이 어디서 실행되고 어떻게 실행되는지 제어합니다.
이 세 번째 점이 많은 개발자들을 혼란스럽게 합니다. 서명은 단순히 식별만 하는 것이 아닙니다. 또한 권한도 있습니다.
따라서 동일한 앱 code이 로컬 디바이스에서 실행, 테스터에게 배포, 내부 배포, 또는 스토어에 제출하는 경우에 따라 서명 매체가 다를 수 있습니다.
서명이 목적지에 따라 어떻게 변하는지
이것이 프로세스를 지속적으로 유지하는 정신 모델입니다: 서명은 배포에 따라 변합니다..
개발자 설치는 한 세트의 사용자 계정과 권한을 사용합니다. 테스트 플라이트를 통해 전송된 베타 빌드는 다른 계정과 권한을 사용합니다. 내부 배포 경로에는 다시 다른 프로필이 필요할 수 있습니다. 공개 스토어 릴리스에는 자신의 서명 기대치와 검토 가능한 패키징이 있습니다.
이것이 '빌드를 다시 서명하라'는 작은 요청이 거의 될 수 없는 이유입니다. 서명이 변경되면, 아티팩트의 허용된 목적지도 함께 변경될 수 있습니다.
disciplined한 설정은 일반적으로 다음과 같습니다:
- CI에서 서명 자산을 저장하지 마세요: 개인 노트북에 저장하지 마세요.
- 목적지에 따라 분리하세요: 개발, 개인 테스트, 기업, 스토어 릴리스.
- 회전 및 접근 제어: 특히 계약자 또는 여러 제품 팀이 인프라를 공유할 때.
- 감사성: pipeline이 사용한 서명 식별자를 알 필요가 있습니다.
If your team ships web updates inside a Capacitor app, there’s a second signing layer to think about as well. This overview of Capacitor 업데이터 code 서명 업데이트 패키지의 신뢰성을 업데이트 패키지의 신뢰성으로 분리하는 것은 __CAPGO_KEEP_0__ 업데이터 __CAPGO_KEEP_1__ 서명이 유용합니다.
서명 문제는 일반적으로 암호화에서 오지 않습니다. 서명 물질의 불명확한 소유권, 수동 처리 및 업데이트 채널이 적용된 항목을 숨기는 빌드 PIPELINE에서 오는 것입니다.
서명 물질을 프로덕션 인프라와 같이 다루세요. 그게 정확히 무엇인지요.
CI/CD와 업데이트 채널을 이용한 릴리스 조정
팀이 성숙할 때, 빌드의 종류를 알기 위한 것이 문제가 아니라, 그들을 조정하는 것이 인간의 추측 없이 문제가 됩니다.
CI/CD에서 그 조정을 담당해야 합니다.
pipeline은 빌드 계약입니다.
신뢰할 수 있는 pipeline은 매번 동일한 질문에 답해야 합니다.
- 이 빌드는 무엇을 위해 존재하는가
- 이 빌드는 어떤 버전을 사용하는가
- 어떤 환경 변수를 받는지
- 어떤 테스트를 통과해야 하는지
- 어떤 인증 정보를 적용하는지
- 어떤 위치로 artifact가 전달되는지
그 구조는 좋은 기술 사양을 반영한다. 완전한 사양에는 목적과 범위, 기능 요구 사항, 설계 요구 사항, 기술 표준, 테스트 요구 사항, 배포 요구 사항 및 유지 보수 또는 유지 관리 요구 사항이 포함되어야 한다. 이 기술 사양 안내서에서 설명한 것과 같이. 그 동일한 discipline은 CI/CD가 더 쉽게 이해할 수 있게 만든다. pipeline은 스크립트의 묶음이 아닌 실행 가능한 릴리스 정책이 된다. 기술 사양 안내서성공한 방법:
Branch-Driven Intent:
이것이 작동합니다.
- Branch-Driven Intent: main, release branches, and tags는 다른 워크플로우를 트리거합니다.
- Explicit artifact naming: flavor, environment, 및 target은 출력에서 표시됩니다.
- Promotion 대신 rebuild-by-hand: 유효한 artifact를 이동하여 재생성하지 않도록 합니다.
What 항상 실패하는 것은 'one flexible script' 접근 방식입니다. 여기서 모든 사람들은 커스터마이즈된 플래그를 전달하고 스토어 또는 테스터가 필요로 하는 것과 일치하는지 기대합니다.
채널은 바이너리가 배포된 후에 제어를 추가합니다.
자연스러운 빌드는 여전히 coarse-grained입니다. 한 번 릴리스가 스토어에 배포되면 웹 콘텐츠를 Capacitor 앱 내부에서 변경하는 경우 항상 새로운 바이너리를 다시 빌드할 필요가 없습니다.
업데이트 채널이 유용해집니다. 이들은 웹 자산 업데이트를 설치된 프로덕션 바이너리 내부의 사용자 서브셋에 적용할 수 있습니다. Capacitor 팀의 경우 하나의 옵션은 Capgo__CAPGO_KEEP_0__
실용적인 패턴은 다음과 같습니다.
- CI/CD에서 바이너리 빌드: 자연스럽게 네이티브 앱을 생성, 서명, 배포합니다.
- 채널 assignments: 사용자 또는 환경을 베타, 스테이징, 프로덕션, 또는 고객 전용 스트림과 매핑합니다.
- 선택적 롤아웃: 웹 변경 사항을 한 그룹에 보내기 전에 더 광범위한 노출을 기다리지 않습니다.
- 롤백 경로: 스토어 리뷰를 기다리지 않고 나쁜 업데이트를 비활성화하거나 되돌리십시오.
모델을 설정하지 않았나요? __CAPGO_KEEP_0__에서 업데이트 채널을 생성하고 삭제하는 방법에 대한_walkthrough_이 모델을 구체화합니다. Capacitor에서 업데이트 채널을 만들고 삭제하는 방법 __CAPGO_KEEP_0__
__CAPGO_KEEP_0__
이것은 모바일 팀이 필요로 하는 전략적 전환입니다. 빌드 유형은 단순한 artifact만이 아닙니다. 그들은 제어점입니다. CI/CD는 바이너리가 생성되는 방법을 제어하고 채널은 설치 후 변경 사항이 노출되는 방법을 제어합니다.
현대 빌드 워크플로우의最佳 관행
건전한 빌드 시스템은 의견이 있습니다. 개발자가 릴리스 동작을 임의로 변경할 수 없습니다.
강력한 설정 중에서私は 몇 가지 습관을 공유합니다:
- 분리된 축을 명확하게 정의하십시오: 맛, 환경, 서명 대상, 배포 대상이 하나의 모호한 레이블에 묻히지 않도록 하십시오.
- CI가 팀에 대면하는 artifact를 생성하십시오: 개발용 빌드는 스테이크 홀더의 신뢰를 위한 것이 아닙니다.
- 릴리스와 같은 조건에서 테스트하십시오: QA 및 베타 테스터는 실제 앱과 가장 가깝게 동작하는 것을 보게되어야 합니다.
- 서명 자산을 노트북에서 유지하지 마십시오: 비밀은 제어된 인프라에 narrow access를 가진 곳에 있어야 합니다.
- 이름을 사람이 읽을 수 있는 이름으로 지정하세요: 파일이 몇 초 안에 어떤 용도로 사용되는지 알 수 없다면 이름이 잘못된 것입니다.
- 유효성을 검증한 아티팩트를 앞으로 이동시키세요. 다시 빌드하는 대신. 릴리즈 전 롤백을 디자인하세요.
- 롤백은 저장소에서 느리고 운영적으로 무거운 편입니다. __CAPGO_KEEP_0__ 업데이트를 위한 웹 레이어 롤백은 훨씬 빠를 수 있지만, 채널과 정책을 미리 계획해야 합니다. store rollback is slow and operationally heavy. Web-layer rollback for Capacitor updates can be much faster, but only if you planned the channels and policies first.
워크플로가 그 질문을 깨끗하게 대답한다면 릴리즈 프로세스는 더 쉬운 운영, 더 쉬운 감사, 그리고 더 적은 한 명의 고급 엔지니어가 올바른 주문어를 기억해야 하는 것에 의존하지 않습니다.
팀이 __CAPGO_KEEP_0__ 앱을 배포하고 릴리즈 워크플로에 대한 더 긴밀한 제어를 원한다면
Capacitor Capgo Capacitor 앱 내부의 웹 자산에 대한 목표된 라이브 업데이트를 처리하고, 서명된 번들을 지원하며, 채널 기반 롤아웃 및 롤백 제어를 제공하여, 원본 빌드 PIPELINE을 대체하지 않고 더 빠른 수정을 필요로 할 때 유용합니다.
