프로젝트를 열면 build:ios:dev, build:android:qa, build:staging, build:release, build:prod, 그리고 몇몇 nobody가 조작하고 싶지 않은 shell 스크립트가 있습니다. 그 다음 누군가가 말합니다. “클라이언트에게 오늘까지 스테이징 빌드를 만들 수 있나요?” 만약 당신이 중급 모바일 개발자라면, 이 요청은 종종 매우 모호하게 느껴집니다. 어떤 설정을 사용해야 하나요? 어떤 인증 정보를 사용해야 하나요? 어떤 백엔드가 필요합니까? 어떤 배포 경로를 사용해야 하나요?
이러한 혼란은 빌드 유형을 평평한 목록으로 다루는 데서 비롯됩니다. 아니다. 그것들은 워크플로입니다. 각 빌드는 특정 문제를 해결하기 위해 특정 위치에서 사용됩니다. 사용자의 장치와 laptop 사이의 위치.
빌드는 단순히 컴파일된 앱이 아닙니다. 특정 목적, 대상 audience, 및 환경을 위해 assembled된 앱의 버전입니다. 일부 빌드는 디버깅을 도와주기 위해 존재합니다. 일부 빌드는 QA가 안전하게 문제를 발생시키도록 도와줍니다. 일부 빌드는 릴리스 엔지니어링이 신뢰할 수 있는 아티팩트를 생성할 수 있도록 도와줍니다. 일부 빌드는 제품 팀이 변경 사항을 덜 위험하게 배포할 수 있도록 도와줍니다.
당신의 로컬 환경이 아직 불안정한 상태라면, 먼저 적절한 Capacitor 로컬 환경 설정을 통해 이를 해결하세요. 빌드 복잡성이 예측할 수 있게 되면, 그 다음에 빌드 유형에 대한 설명을 시작할 수 있습니다.
목차
- 소프트웨어 빌드의 세계를 풀어헤치기
- 빌드 스펙트럼: 로컬 vs CI 빌드
- 핵심 빌드 맛집 Debug vs Release
- 빌드 매핑을 분배 환경으로
- Code 인증의 중요성
- CI/CD와 업데이트 채널을 이용한 릴리즈 조정
- 최신 빌드 워크플로우를 위한 베스트 프랙티스
소프트웨어 빌드의 세계를 단단히하는 방법
가장 흔한 실수는 빌드 이름이 모든 이야기를 담고 있다고 가정하는 것입니다. 그것은 그렇지 않습니다. staging 예를 들어, 다른 저장소에서는
__CAPGO_KEEP_0__이 스테이징 API를 향한 릴리즈 플래버를 의미할 수 있습니다.
다른 저장소에서는
- Local builds 개발자에게 빠르게 움직여 도움을 주는 것.
- CI builds 팀의 공유된 진실의 근거를 만듭니다.
- Debug and release flavors 앱이 컴파일되고 도구화되는 방식을 정의합니다.
- Distribution builds 앱이 누구에게 전달되고 어떻게 전달되는지 정의합니다.
- Signed builds 플랫폼이 아티팩트를 신뢰할지 결정합니다.
- Channel-based updates 설치 후 변경이 어떻게 이동하는지 결정합니다.
이것들은 경쟁하는 카테고리가 아닙니다. 그들은 쌓입니다.
‘스테이징 빌드’는 일반적으로 단일한 것이 아닙니다. 그것은 일반적으로 맛, 환경, 서명, 배포 방법의 combination입니다.
이것이 두 팀이 모두 ‘베타 빌드’가 필요하다고 말할 수 있는 이유입니다. 완전히 다른 artifact를 의미합니다.
이것은 모바일에서 가장 중요합니다. Native compilation, secrets, provisioning, app store tracks, tester access, environment config, rollback 모두 일치해야 합니다. 하나의 부분이 느슨하면 릴리즈 프로세스가 민감한 지식이 됩니다. 그런 다음 한 엔지니어가 휴가에 가면 nobody가 깨끗하게 릴리즈할 수 없습니다.
이것을 잘 처리하는 팀들은 더 많은 스크립트를 기억하지 않습니다. 그들은 빌드 타입을 품질 게이트로 정의합니다. 각 게이트는 다른 종류의 위험을 낮춥니다: 깨진 code, 잘못된 config, 나쁜 서명, 나쁜 롤아웃, 나쁜 복구.
빌드 스펙트럼: 로컬 빌드 vs CI 빌드
로컬 빌드는 당신이 만드는 버전입니다. CI 빌드는 팀이 신뢰할 수 있는 버전입니다.
이것은 명백합니다. 그러나 많은 빌드의 고통은 팀이 두 가지를 혼동할 때 시작됩니다. alguien이 ‘내 컴퓨터에서 작동한다’고 증명하면 branch가 CI에서 실패합니다. 로컬 환경은 암시적으로 캐시된 의존성, 수동으로 편집된 파일, 서명 자산이 자동화에 포함되지 않은 경우에 의존합니다.
로컬 빌드는 개인적, 빠르고 버려질 수 있습니다. 즉시 질문에 답하기 위해 사용합니다.
A focused man working on his laptop in a modern office, studying local versus CI development.
화면이 렌더링 될 수 있나요? 네이티브 플러그인이 초기화되나요? Gradle 또는 Xcode 변경이 컴파일을 중단했나요? 로깅을 높여서 충돌을 재현할 수 있나요?
좋은 로컬 빌드는 속도보다 절차를 우선합니다. 종종 더 느슨한 체크, 자세한 로그, 개발자 토글, 임시 인스트루먼트를 포함합니다. 그건 괜찮습니다. 빠른 feedback를 제공하는 것이 그 역할입니다.
그러나 로컬 빌드를 더 중요한 것으로 홍보하는 것은 잘못된 것입니다. 로컬 빌드는 한 대의 노트북에서 성공적으로 컴파일된 경우에만 릴리즈 아티팩트가 될 수 없습니다.
CI 빌드
CI 빌드는 속도 때문에 느립니다. CI 빌드는 개인 기기 상태를 제거하고 빌드 프로세스를 반복 가능하게 만듭니다.
CI가 건강할 때, 그것은 세 가지 일을 잘합니다:
- 새로부터 빌드합니다: 프로젝트가 숨겨진 로컬 가정 없이 컴파일 될 수 있는지 증명합니다.
- 팀 수준 체크를 실행합니다: 유닛 테스트, linting, 패키징 규칙은 항상 같은 장소에서 발생합니다.
- 추적 가능한 아티팩트를 생성합니다: 팀은 빌드를 커밋, 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 그것들이 존재하는 이유는 개발자와 사용자가 반대되는 것을 필요로하기 때문입니다..
Debug 플래버는 개발자에게 중요한 정보를 제공합니다. Release 플래버는 사용자가 제품을 사용할 수 있도록 합니다.
__CAPGO_KEEP_1__
__CAPGO_KEEP_2__
__CAPGO_KEEP_3__ __CAPGO_KEEP_4__, __CAPGO_KEEP_5__, __CAPGO_KEEP_6____CAPGO_KEEP_7__ __CAPGO_KEEP_8__ __CAPGO_KEEP_9__ __CAPGO_KEEP_10__ __CAPGO_KEEP_11__ 성능 결과에 대한 명확한 결과를 내는 접근 방식으로, 건설 사양 유형의 분해.
실제로, 디버그 빌드는 다음과 같은 것들을 원하는 경우가 많습니다.
- 읽기 쉬운 디버그 정보: 스택 추적, 콘솔 출력 및 오류를 찾는데 도움이 되는 심볼.
- 개발자 편의성: 모킹 스위치, 테스트 메뉴 및 사용자에게 적합하지 않은 기능 Switch.
- 저항이 적은 반복: 빠른 설치 및 실행 주기가 더 중요한 것보다 패키지의 완성도.
디버그 빌드는 "나쁜" 빌드가 아닙니다. 목적을 위해 설계된 빌드입니다.
릴리스 빌드
Release 빌드는 실제 장치에서 작동하는 빌드입니다. 그게 우선순위를 즉시 바꿔줍니다.
이제 패키지完整성, 시작 동작, 보안 태세, 작은 페이로드, 그리고 예측 가능한 런타임 특성에 관심이 갑니다. 또한 검사 또는 부정사용의 의도치 않은 진입점이 적게 되기를 원합니다.
트레이드 오프는 간단합니다. 디버그 빌드가 더 쉽게 검사되도록 하는 모든 것이 프로덕션에서 릴리스 빌드가 적절하지 않도록 만듭니다.
팀과 함께 사용하는 결정 경계는 다음과 같습니다:
| 맛 | 추천 | 최적화 |
|---|---|---|
| 디버그 | 개발, 로컬 테스트, 문제 재현 | 可視성 및 반복 속도 |
| 릴리스 | 베타 배포, 스토어 제출, 프로덕션 롤아웃 | 안정성, 성능, 신뢰 |
팀이 여전히 잘못하는 이유
혼동의 가장 큰 원인은 '환경'과 '맛'을 혼동하는 것입니다.
빌드는 릴리즈 맛이 스테이징 서비스에 포인트 될 수 있습니다.그것은 QA에서 일반적이기 때문입니다. 비프로덕션 데이터와 프로덕션과 같은 동작을 원하기 때문입니다. 빌드는 디버그 맛이 개발 서비스에 포인트 될 수 있습니다. 일상적인 코딩을 위해입니다. 그것들은 다른 축입니다.
스크립트의 많은 양이 팀이 패키지 이름에 모든 가능한 combination을 인코딩하는 대신에 매트릭스를 문서화하지 않아서 생기는 것입니다.
사용자 대면 동작을 테스트하는 비개발자에게 릴리즈 맛을 배달하세요. 엔지니어링 작업과 의도적인 디버깅을 위해 디버그 맛을 유지하세요.
그것은 많은 부차적인 복잡성을 제거합니다.
빌드 매핑을 배포 환경에 매핑합니다.
대부분의 빌드 종류에 대한 토론은 너무 일찍 끝나게 됩니다. 로컬, 디버그, 릴리스에 대해 설명하고, 더 어려운 질문인 빌드가 어디로 가는지에 대해 무시합니다.
빌드의 목적지에 따라 빌드가 포함해야 하는 내용, 빌드가 어떻게 서명되어야 하는지, 빌드가 누구에게 전달되어야 하는지에 대한 질문이 달라집니다.
실용적인 빌드 워크플로는 여러 환경을 거쳐야 하며, 각 환경은 다른 사용자와 위험에 대한 tolerance을 가지고 있습니다. Capacitor 앱을 개발하는 경우, 개발 환경과 운영 환경의 앱 동작을 구분하는 것이 도움이 됩니다. Capacitor에서 개발 환경과 운영 환경의 앱 동작을 구분하는 것이 도움이 됩니다. 왜냐하면 많은 '빌드 오류'가 실제로는 환경 매핑 오류일 수 있기 때문입니다.밤과 개구리
이것들은 엔지니어, QA, 또는 내부 그룹에 대한 작은 그룹이 rough edges를 tolerate할 수 있는 early warning 빌드입니다.
밤 빌드는 일반적으로 일정에 따라 생성되거나 최신 메인 branch 상태에서 생성됩니다. 개구리 빌드는 더 넓은 롤아웃 전에 narrow audience에 노출됩니다. 나는 이들을 stability의 약속이 아닌 학습 도구로 다룹니다.
이것들은 다음 질문에 답할 때 유용합니다:
모듈 간에 branch가 통합되는지 여부
- 특정 디바이스 패밀리의 native dependency 업그레이드가 특정 장치 패밀리를 깨트렸는지 여부
- 내부 테스터가 더 넓은 베타 노출 이전에 regresion을 감지할 수 있는지 여부
- __CAPGO_KEEP_0__
__CAPGO_KEEP_0__은 완성된 소프트웨어를 기대하는 사람들에게 카나리 빌드를 제공하는 것은 잘못된 접근입니다. 노이즈 피드백을 받고, 정상적인 churn을 릴리즈 문제로 부르는 오해를 피할 수 없습니다.
스테이징 및 베타
이 시점에서 제품 품질이 엔지니어링의 편의보다 더 중요해집니다.
스테이징 또는 베타 빌드는 실제 사용자가 받을 것과 비슷한 느낌을 주어야 합니다. 일반적으로 이는 릴리즈 버전의 맛을 내야 하며, 가능한 경우 프로덕션과 같은 설정을 사용하고, 플랫폼 도구인 TestFlight 또는 Google Play 테스트 트랙을 통해 제어된 배포를 해야 합니다.
이 시점에서 대상이 바뀝니다.
- QA는 회귀, 워크플로우 및 수락 기준을 검증합니다.
- 제품 매니저는 실제 사용자 흐름에서 행동을 검토합니다.
- 외부 테스터는 사용성, 장치 지원 및 에지 케이스를 검증합니다.
- 지원 또는 성공 팀은 미래의 변경 사항을 미리 보아야 합니다.
이러한 오류는 베타를 “debug 빌드”로만 생각하는 것입니다. 테스터가 실제 사용자 흐름을 평가하고 있다면, 릴리즈와 같은 조건이 필요합니다.
개인 배포 빌드
어떤 앱은 공개 스토어 사용자에게 절대 배포되지 않거나, 좁은 그룹에 먼저 도달해야 하는 경우가 있습니다.
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
소프트웨어 빌드 유형 및 특성
| 빌드 유형 | 대상 | 구성 | 배포 방법 |
|---|---|---|---|
| 로컬 개발자 | 개인 개발자 | 일반적으로 디버그, 빠른 반복, 로컬 환경 설정 | 직접 로컬 머신에서 설치 |
| CI 검증 | 엔지니어링 팀 | 반복 가능한 자동 빌드, 공유된 체크 | CI artifact 저장소 |
| 일일 빌드 또는 Canary | 내부 테스터, 선택된 팀원 | 초기 통합 상태, 제한된 롤아웃 | 내부 배포 도구 |
| 스테이징 또는 베타 | QA, 제품, 외부 테스터 | 일반적으로 릴리즈와 같은 비공개 환경 매핑 | 테스트 플라이트, 플레이 테스트 트랙, 개인 링크 |
| 어드혹 또는 기업 | 내부 직원, 고객, 제한된 그룹 | 제어된 구성, 목적지별 서명 | 개인 배포 채널 |
| 생산 | 공개 사용자 | 최종 릴리즈 구성, 저장할 수 있는 서명 | 애플 스토어 또는 구글 플레이 |
정확한 빌드 유형은 사용자가 감수할 수 있는 위험의 수준에 맞는 유형입니다. 대부분의 릴리즈 오류는 팀이 그 정렬을 생략했을 때 발생합니다.
Code 서명의 중요성
모바일에서 빌드 파일 자체만으로는 의미가 없습니다. 플랫폼은 신뢰할 수 있는 출처에서 왔으며 생성 후 nobody가 변경하지 않았다는 것을 증명해야 합니다. 그 증명은 code 서명.
빌드가 완벽하게 컴파일되었지만 설치, 업로드, 또는 실행이 올바르게 작동하지 않았던 경우가 있으셨나요? 서명이 문제였을 가능성이 높습니다.
서명이 실제로 증명하는 것은
모바일 팀에게는 code 서명이 세 가지 일을 합니다.
- 인증: 앱을 개발자 또는 조직과 연결시킵니다.
- 완전성: 서명이 이루어진 이후에 앱이 손상되지 않았는지 증명합니다.
- 권한: 특히 애플 플랫폼에서, 앱이 어디서 실행되고 어떻게 실행되는지 제어합니다.
개발자들이 혼란스럽게 생각하는 세 번째 점은 서명이 단순히 식별만 하는 것이 아님을 알려줍니다. 서명은 또한 권한을 의미합니다.
서명은 동일한 앱 code에 따라 다른 서명 자료를 요구할 수 있습니다. 예를 들어, 앱을 장치에서 실행하거나 테스터에게 배포하거나 내부적으로 배포하거나 스토어에 제출하고 싶다면.
서명이 목적지에 따라 어떻게 변하는지
이러한 정신 모델은 프로세스를 지속적으로 유지하는 데 도움이 됩니다: 서명은 배포에 따라 변합니다..
국내 개발자 설치는 한 세트의 식별 정보와 권한을 사용합니다. 테스트 플라이트를 통해 전송된 베타 빌드는 다른 것을 사용합니다. 내부 배포 경로에는 다시 다른 프로필이 필요할 수 있습니다. 공개 스토어 릴리스에는 자신의 서명 기대치와 검토 가능한 패키징이 있습니다.
그것이为什么 “빌드를 다시 서명하라”는 작은 요청이 거의 아니라는 것입니다. 서명이 변경되면, 아티팩트의 허용된 목적지도 함께 변경될 수 있습니다.
엄격한 설정은 일반적으로 다음과 같습니다:
- CI에서 서명 자산을 저장합니다: 개인 노트북에 저장하지 마십시오.
- 목적지에 따라 분리된 구분: 개발, 개인 테스트, 기업, 스토어 릴리스.
- 회전 및 접근 제어: 특히 계약자 또는 여러 제품 팀이 인프라를 공유할 때.
- 감사성: 당신은 어떤 PIPELINE이 어떤 서명 식별자를 사용했는지 알아야 합니다.
당신의 팀이 웹 업데이트를 내장 앱 Capacitor 내에서 배포한다면, 두 번째 서명层를 고려해야 할 것입니다. 이 개요는 Capacitor 업데이터 code 서명에 대한 종단-to-종단 보안 업데이트 패키지의 신뢰성과 네이티브 바이너리 신뢰성을 분리하는 것이 유용하다.
서명 문제는 일반적으로 암호학에서 오지 않는다. unclear 소유권, 수동 처리 및 빌드 PIPELINE이 적용된 IDENTITY를 숨기는 것이 문제이다.
서명 자료를 프로덕션 인프라 처럼 다루어야 한다. 그게 정확히 그것이다.
CI/CD 및 업데이트 채널과 함께 릴리스를 조율하는 방법
팀이 성숙할 때, 문제는 빌드의 유형을 알지 못하는 것이 아니다. 그들은 인간의 추측 없이 조율하는 것이다.
그것은 CI/CD에 속한다.
pipeline은 빌드 계약이다.
신뢰할 수 있는 pipeline은 매번 동일한 질문에 답해야 한다.
- 이 빌드는 무엇을 위해 존재하는가
- 어떤 버전을 사용하는가
- 받는 환경 변수
- 통과해야 하는 테스트
- 적용되는 서명 식별자
- 아티팩트가 전달되는 곳
기술적 사양의 구조는 좋은 기술 사양의 특징을 반영합니다. 기술 사양이 잘 구성되어야 하는 이유는 다음과 같습니다. 목적과 범위, 기능 요구 사항, 설계 요구 사항, 기술 표준, 테스트 요구 사항, 배포 요구 사항, 유지 보수 또는 유지 관리 요구 사항 기술 사양 설명서에 설명된 것과 같습니다.그 동일한 규칙은 CI/CD를 더 쉽게 이해할 수 있게 합니다. pipe line은 스크립트의 모음이 아닌 실행 가능한 릴리즈 정책이 됩니다.
실제로 pipe line은 엔지니어가 수동으로 실행하는 것이 아닌 pipe line이 결정해야 합니다. branch 규칙, 태그, 승인 단계, 서명 컨텍스트, 배포 대상이 모두 인코딩되어야 합니다.
성공한 방법:
- branch 기반 의도: main, release branches, and tags는 다른 워크플로우를 트리거합니다.
- Explicit artifact naming: flavor, environment, 및 target은 출력에서 표시됩니다.
- Promotion 대신 재구축-수동으로: 유효한 artifact를 이동시키기보다는 ad hoc로 재생성하는 대신.
일관적으로 실패하는 것은 “한 개의 유연한 스크립트” 접근 방식입니다. 여기서 모든 사람들이 커스터마이즈된 플래그를 전달하고 스토어 또는 테스터가 필요로 하는 것과 일치하는지 기대합니다.
채널은 바이너리가 배포된 후에 제어를 추가합니다.
자연어 빌드는 여전히 coarse-grained입니다. 한 번 릴리스가 스토어에 배포되면, Capacitor 앱 내부의 웹 콘텐츠를 변경하는 것은 항상 새로운 바이너리를 다시 빌드하는 것이 아닙니다.
업데이트 채널이 유용한 곳입니다. 채널은 설치된 프로덕션 바이너리 내부의 사용자 서브셋에 웹 자산 업데이트를 대상으로 할 수 있습니다. Capacitor 팀의 경우, 하나의 옵션은 Capgo, 이 signed web bundles를 대상 채널에 게시하여 자바스크립트, CSS, 복사본, 구성, 및 자산 변경을 푸시할 수 있습니다. native shell을 매번 다시 빌드할 필요가 없습니다.
실용적인 패턴은 다음과 같습니다:
- CI/CD에서 바이너리 빌드: 자연어 앱을 생성, 서명, 배포합니다.
- 채널 assignments: 사용자 또는 환경을 베타, 스테이징, 프로덕션, 또는 고객 특정 스트림으로 맵핑합니다.
- 선택적 롤아웃: 웹 변경 사항을 한 그룹에 보내기 전에 더 넓은 노출을 기다리지 않고.
- 롤백 경로: 스토어 리뷰를 기다리지 않고 나쁜 업데이트를 비활성화하거나 되돌립니다.
그 모델을 아직 설정하지 않았다면, __CAPGO_KEEP_0__에서 업데이트 채널을 생성하고 삭제하는 walkthrough에 대해 이 안내서를 참조하세요. creating and deleting update channels in Capacitor 채널의 동작을 아직 본 적이 없다면, 짧은 데모가 도움이 될 것입니다.
이 데모는 채널을 사용하는 방법을 보여줍니다.
이러한 전략적 전환은 많은 모바일 팀이 필요합니다. 빌드 유형은 단순히 아티팩트만이 아닙니다. 그들은 제어점입니다. CI/CD는 바이너리가 생성되는 방법을 제어하고 채널은 설치 후 변경 사항이 노출되는 방법을 제어합니다.
현대 빌드 워크플로의最佳 관행
건전한 빌드 시스템은 의견이 있습니다. 개발자가 릴리스 동작을 임의로 개선할 수 없습니다.
강력한 설정 중에서 공유하는 몇 가지 습관이 있습니다.
- 분리된 축을 분명히 하십시오. 맛, 환경, 서명 대상 및 배포 대상이 하나의 모호한 레이블에 묻히지 않도록 하십시오.
- CI가 팀에 대면하는 아티팩트를 생성하십시오. 개발용 빌드는 이해관계자에 대한 신뢰를 위한 것이 아닙니다.
- 릴리스와 같은 조건에서 테스트하십시오. QA 및 베타 테스터는 실제 앱과 가능한 한 가깝게 동작하는 것을 보아야 합니다.
- 서명 자산을 노트북에서 분리하십시오. 비밀은 제어된 인프라에 narrow 접근 권한을 가진 곳에 속해야 합니다.
- __CAPGO_KEEP_0__ 이름을 사람이 읽을 수 있는 이름으로 지정하십시오. 파일이 어떤 용도로 사용되는지 몇 초 안에 식별할 수 없다면 이름이 나쁘다.
- 재현보다 승진을 선호하십시오. 유효성 검사를 통과한 artifact는 workflow를 통해 이동시키기 보다는 수동으로 다시 만드는 대신 재현하지 말라.
- 출시 전에 롤백을 설계하십시오. 롤백 저장은 느리고 운영 비용이 많이 듭니다. Capacitor 업데이트를 위한 웹层 롤백은 훨씬 빠를 수 있지만, 채널과 정책을 미리 계획해야만 합니다.
가장 큰 마음의 변화는 이렇습니다: '어떤 빌드 스크립트를 실행해야 하나?'라는 질문 대신 '이 단계에서 관리해야 하는 위험은 무엇인가?'라는 질문을 하십시오. 이 질문은 더 나은 빌드 시스템을 만듭니다.
workflow가 그런 질문에 명확하게 답한다면, 릴리즈 프로세스는 더 쉽게 운영할 수 있고, 감사할 수 있고, 한 명의 주니어 엔지니어가 올바른 주문어를 기억해야 하는 것에 의존하지 않습니다.
팀이 Capacitor 앱을 배포하고 릴리즈 워크플로에 대한 더 chặt한 제어가 필요하다면 Capgo을 평가하는 것이 그 스택에 포함되는 것이 가치가 있습니다. Capgo 앱 내의 웹 자산에 대한 목표된 실시간 업데이트를 처리하고, 서명된 번들을 지원하며, 채널 기반 롤아웃 및 롤백 제어를 지원하여, 더 빠른 수정을 필요로 할 때 원본 빌드 PIPELINE을 교체하지 않고도 유용합니다. Capacitor에 의해 작성되었습니다.
