프로젝트를 열면 build:ios:dev, build:android:qa, build:staging, build:release, build:prod, 그리고 몇 개의 쉘 스크립트가 nobody가 조심스럽게 만든 것을 발견합니다. 그 후에 alguien이 말합니다. “오늘 저녁까지 클라이언트에게 스테이징 빌드를 만들 수 있나요?” 만약 당신이 중급 모바일 개발자라면, 그 요청은 매우 모호하게 느껴집니다. 어떤 설정을 사용해야 하나요? 어떤 서명 식별자를 사용해야 하나요? 어떤 백엔드를 사용해야 하나요? 어떤 배포 경로를 사용해야 하나요?
그런 혼란은 일반적으로 빌드 유형을 평평한 목록으로 다루는 데서 비롯됩니다. 그들은 아니다. 그들은 워크플로입니다. 각 빌드는 사용자의 장치와 laptop 사이의 특정 문제를 해결하기 위해 존재하는 특정 목적을 위해 존재합니다.
빌드는 단순히 컴파일된 앱이 아닙니다. 그것은 특정 목적, 특정 청중, 특정 환경을 위해 앱을 조립한 버전입니다. 일부 빌드는 디버그를 도와주기 위해 존재합니다. 일부 빌드는 QA가 안전하게 깨지도록 도와줍니다. 일부 빌드는 릴리스 엔지니어링이 신뢰할 수 있는 아티팩트를 생성할 수 있도록 도와줍니다. 일부 빌드는 제품 팀이 변경 사항을 덜 위험하게 배포할 수 있도록 도와줍니다.
로컬 설정이 아직도 불안정한 느낌이 들면, 그 전에 __CAPGO_KEEP_0__ 로컬 환경 설정을 제대로 하세요. Capacitor local environment setup목차
소프트웨어 빌드 세계를 풀어헤치기
- 빌드 스펙트럼 로컬 vs CI 빌드
- 로컬 빌드
- 디버그 빌드
- 배포 환경에 빌드를 매핑하는 방법
- Code 서명의 중요성
- CI/CD와 업데이트 채널을 이용한 릴리스 관리
- __CAPGO_KEEP_0__
__CAPGO_KEEP_0__
제일 흔한 실수는 빌드 이름이 모든 이야기를 담고 있다고 가정하는 것입니다. 그렇지 않습니다. staging 이 빌드 이름이 "배포 버전이 스테이징 API를 향한 것"을 의미할 수 있습니다. 다른 저장소에서는 "디버그 가능한 QA 아티팩트에 모의 결제"를 의미할 수 있고, 세 번째 저장소에서는 "개인적으로 배포된 프로덕션 빌드"를 의미할 수 있습니다.
이러한 이유로 팀이 엉켜 있습니다. 빌드 이름이 유용한 것은 빌드가 수행하는 작업을 이해할 때 뿐입니다.
빌드의 유형에 대한 유용한 방법은 다음과 같습니다:
- 개인 개발자가 빠르게 움직이는 데 도움이 되는 로컬 빌드 팀이 공유하는 소스 코드의 공정한 진실을 만드는 CI 빌드
- CI 빌드와 로컬 빌드의 차이점은 무엇입니까? CI 빌드는 팀이 공유하는 소스 코드의 공정한 진실을 만드는 반면, 로컬 빌드는 개인 개발자가 빠르게 움직이는 데 도움이 됩니다.
- Debug 및 릴리스 플래버 앱이 컴파일되고 인스트루먼트되는 방식을 정의합니다.
- 배포 빌드 앱을 받고 어떻게 받는지 정의합니다.
- 서명 빌드 플랫폼이 아티팩트를 신뢰할지 결정합니다.
- 채널 기반 업데이트 설치 후 변경 사항이 어떻게 이동하는지 결정합니다.
그것들은 경쟁하는 카테고리가 아닙니다. 그것들은 쌓입니다.
‘스테이징 빌드’는 거의 항상 단일한 것이 아닙니다. 일반적으로 플래버, 환경, 서명, 배포 선택의 combination입니다.
그것이 왜 두 팀이 모두 ‘베타 빌드’가 필요하다고 말할 수 있는지 이유입니다. 그리고 그것은 완전히 다른 아티팩트를 의미합니다.
이것은 모바일에서 가장 중요합니다. 왜냐하면 모든 단계가 마찰을 증가시기 때문입니다. 네이티브 컴파일, 비밀, 프로비전, 앱 스토어 트랙, 테스터 접근, 환경 구성, 롤백 모두가 일치해야 합니다. 만약 하나의 부분이 느슨하면 릴리스 프로세스가 민감한 지식이 됩니다. 그리고 한 엔지니어가 휴가에 가면 nobody가 깨끗하게 배포할 수 없습니다.
이 팀은 스크립트를 더 많이 기억하지 않습니다. 그들은 빌드 유형을 품질 게이트로 정의합니다. 각 게이트는 다음과 같은 다른 종류의 위험을 낮춥니다: code이 깨진 경우, 잘못된 구성, 잘못된 서명, 잘못된 롤아웃, 또는 잘못된 복구.
빌드 스펙트럼 - 로컬 빌드 vs CI 빌드
로컬 빌드는 자신이 만든 버전입니다. CI 빌드는 팀이 신뢰할 수 있는 버전입니다.
그것은 명백한 소리 같지만, 많은 빌드 고통이 시작될 때 팀이 두 가지를 혼동할 때 발생합니다. alguien이 “내 컴퓨터에서 작동한다”고 증명하면 branch가 CI에서 실패하는 이유는 로컬 환경이 암시적으로 캐시된 의존성, 수동으로 편집된 파일, 또는 서명 자산이 자동화에 포함되지 않은 경우에 있습니다.
로컬 빌드
로컬 빌드는 개인적, 빠르고 버려집니다. 즉시 질문에 대한 답변을 위해 사용합니다.
화면이 렌더링되나요? 네이티브 플러그인이 초기화되나요? Gradle 또는 Xcode 변경이 컴파일을 중단했나요? 로깅을 높여서 재생산할 수 있는 충돌이 있나요?
좋은 로컬 빌드는 속도보다 의식에 우선합니다. 종종 느슨한 검사, 자세한 로그, 개발자 토글, 임시 인스트루먼테이션을 포함합니다. 그건 괜찮습니다. 그 JOB은 빠른 feedback를 제공합니다.
그것이 작동하지 않는 것은 로컬 빌드를 더 중요한 것으로 승격하는 것입니다. 로컬 빌드는 컴파일이 성공적으로 한 컴퓨터에서만 성공했기 때문에 릴리즈 아티팩트가 될 수 없습니다.
CI 빌드
CI 빌드는 느리게 실행되는 이유가 있습니다. 그들은 개인 컴퓨터 상태를 제거하고 빌드 프로세스를 반복 가능하게 만듭니다.
CI가 건강할 때, 그것은 세 가지 일을 잘합니다:
- 새로 시작해서 다시 빌드합니다: 프로젝트가 숨겨진 지역 가정 없이 컴파일 될 수 있는지 증명합니다.
- 팀 수준의 체크를 실행합니다: 유닛 테스트, linting, 패키징 규칙은 항상 같은 장소에서 발생합니다.
- 추적 가능한 아티팩트를 생성합니다: 팀은 빌드를 커밋, branch, pipeline 실행과 연결할 수 있습니다.
그것이 왜 나는 워크샵-공장 analogy를 좋아하는지 이유입니다. 랩탑은 반복을 위해 작업대입니다. CI는 프로세스가 실제인지 증명하는 assembly line입니다.
만약 팀이 여전히 자동화에서 스크립트를 어디서 실행할지 수동으로 결정하고 있다면, 그 논리를 중앙화하세요. 실제 참고 자료는 __CAPGO_KEEP_0__ Actions를 사용하여 개발 및 프로덕션 빌드 관리하는 이 안내서입니다. managing dev and prod builds with GitHub Actions.
__CAPGO_KEEP_0__ QA, 제품, 또는 지원이 아티팩트를 필요로 한다면, 그것은 CI에서 오는 것이어야 합니다. 개발자의 머신에서 오는 것이 아닙니다.
그것을 받아들이면, 빌드 라이프 사이클의 나머지 부분이 더 쉬워집니다. Flavor 선택, 서명, 환경 주입, 배포는 모두 팀의 누구도 검토할 수 있는 pipeline에 속해야 합니다.
Core Build Flavors Debug vs Release
빌드에 사용되는 많은 레이블이 있지만, 그 이름 밑에 두 가지 맛이 가장 중요합니다: debug 및 release.
그것들은 개발자와 사용자가 반대되는 것을 필요로하기 때문입니다.
Debug build는 인간이 행동을 검사하는 것을 도와주는 것입니다. 일반적으로 더 많은 메타데이터를 유지하고, 문제를 숨기지 않는 공격적인 최적화가 더 쉬운 디버깅을 제공합니다.
건설 규격에서 유용한 비유가 있습니다. 규격은 일반적으로
Specifications commonly fall into prescriptive, 성능, proprietary, and reference-standard types, and a debug build maps neatly to a prescriptive approach because it dictates exact tools and methods for analysis, while a release build maps to a performance approach focused on the required outcome, as outlined in 이 건설 사양 유형의 분해.
실무에서, 디버그 빌드는 다음 것과 같은 것을 원합니다:
- Readable diagnostics: 오류를 찾는데 도움이 되는 스택 추적, 콘솔 출력 및 심볼.
- Developer affordances: 개발자용 toggle, 테스트 메뉴 및 사용자에게 적합하지 않은 기능 switch.
- Low-friction iteration: 빠른 설치 및 실행 주기가 패키지의 완성도보다 더 중요합니다.
Debug builds are not “bad.” They’re purpose-built.
디버그 빌드는 “나쁜” 빌드가 아니며, 특정 목적을 위해 설계된 빌드입니다.
Release builds
Release builds는 실제 장치에 배포된 빌드입니다. 이는 우선순위를 즉시 변경합니다.
Release builds는 실제 장치에 배포된 빌드입니다. 이는 우선순위를 즉시 변경합니다. 이제 패키지完整성, 시작 동작, 보안 태세, 작은 패키지 크기, 예측 가능한 런타임 특성에 관심이 있습니다. 또한 검사 또는 부정위용의 의도하지 않은 진입점이 적게되기를 원합니다.
Release builds는 실제 장치에 배포된 빌드입니다. 이는 우선순위를 즉시 변경합니다. 이제 패키지完整성, 시작 동작, 보안 태세, 작은 패키지 크기, 예측 가능한 런타임 특성에 관심이 있습니다. 또한 검사 또는 부정위용의 의도하지 않은 진입점이 적게되기를 원합니다. 이 trade-off은 간단합니다. 디버그 빌드가 더 쉽게 검사되도록 하는 모든 것이 릴리스 빌드가 프로덕션에 적합하지 않도록 만듭니다. 팀과 함께 사용하는 결정 경계는 다음과 같습니다.
| 맛 | 개발에 가장 적합한 환경 | 최적화하는 부분 |
|---|---|---|
| Debug | 개발, 로컬 테스트, 문제 재현 | 비주얼성과 반복 속도 |
| Release | 베타 배포, 스토어 제출, 프로덕션 론칭 | 안정성, 성능, 신뢰 |
팀이 여전히 잘못하는 이유
혼동의 가장 큰 원인은 '환경'과 '맛'을 섞는 것입니다.
빌드가 배포 버전이 스테이징 서비스를 향해 포인트됩니다. 그게 QA에서 일반적으로 필요한 이유입니다. 프로덕션과 같은 동작을 비프로덕션 데이터와 함께 원하는 것입니다. 빌드는 또한. 비프로덕션 데이터와 함께 프로덕션과 같은 동작을 원하는 경우 QA에서 일반적으로 사용하는 스테이징 서비스를 향한 버전입니다. 빌드는 또한 개발 서비스를 향한 버전입니다. 개발자들이 일상적인 코딩을 위해 사용합니다. 그들은 다른 축입니다. 팀이 패키지 이름에 모든 가능한 combination을 인코딩하는 대신 매트릭스를 문서화하지 않으면 스크립트 sprawl의 많은 원인이 됩니다.
사용자 대면 동작을 테스트하는 비개발자들이 배포 버전을 배포할 때입니다. 개발자들이나 의도적인 디버깅을 위해 개발 버전을 유지하세요.
이 규칙이 많은 부차적인 복잡성을 제거합니다.
배포를 분배 환경에 매핑하는 것
빌드의 종류에 대한 토론을 하는 대부분의 토론은 너무 일찍 멈추게 됩니다. 지역, 디버그, 배포를 설명하고, 더 어려운 질문인 빌드가 어디로 가는지에 대한 질문을 무시합니다.
빌드의 목적지로 가는 곳이 빌드가 포함해야 하는 내용, 빌드가 어떻게 서명되어야 하는지, 빌드가 누구에게 전달되어야 하는지에 영향을 줍니다.
실용적인 빌드 워크플로는 여러 환경을 거쳐야 하며, 각 환경은 다른 청중과 위험에 대한 용납 범위가 다릅니다. __CAPGO_KEEP_0__ 앱을 개발하고 있다면, 개발과 프로덕션 앱 동작을 __CAPGO_KEEP_0__에서 분리하는 것이 도움이 됩니다.
Capacitor 앱을 개발하고 있다면, 개발과 프로덕션 앱 동작을 Capacitor에서 분리하는 것이 도움이 됩니다. development and production app behavior in Capacitor이러한 ‘빌드 버그’는 실제로 환경 매핑 오류일 때가 많습니다.
밤과 카나리아
이것은 엔지니어, QA, 또는 작은 내부 그룹이 rough edges를 tolerate할 수 있는 사람들에게 제공되는 초기 경고 빌드입니다.
밤 빌드는 일반적으로 일정에 따라 생성되거나 최신 메인 branch 상태에서 생성됩니다. 카나리아 빌드는 더 넓은 롤아웃 전에 좁은 대중에게 의도적으로 노출됩니다. 나는 이들을 학습 도구로 다루며 안정성에 대한 약속으로 다루지 않습니다.
이것들은 다음 질문에 답할 때 유용합니다:
- branch가 모듈 간에 깨끗하게 통합되나요?
- native dependency 업그레이드가 특정 장치 패밀리에서 문제를 일으키나요?
- 내부 테스터가 더 넓은 베타 노출 이전에 회귀를 감지할 수 있나요?
이것들은 다음 질문에 답할 때 유용합니다:
Staging과 베타
이 시점에서 제품 품질이 엔지니어링 편의보다 더 중요합니다.
Staging 또는 베타 빌드는 실제 사용자가 받을 것과 유사해야 합니다. 일반적으로 이는 릴리스 맛, 가능한 경우 프로덕션과 같은 구성, 플랫폼 도구인 TestFlight 또는 Google Play 테스트 트랙을 통해 제어된 배포를 의미합니다.
The audience shifts here:
- QA는 회귀, 워크플로우 및 수락 기준을 검증합니다.
- 제품 매니저는 실제적인 셸에서 동작을 검토합니다.
- 외부 테스터는 사용성, 장치 지원 및 경계 사례를 검증합니다.
- 지원 또는 성공 팀은 미래의 변경 사항을 미리 보게 됩니다.
오류는 베타를 “debug 빌드”로만 간주하는 것입니다. 테스터가 실제 사용자 흐름을 평가하고 있다면, 릴리스와 같은 조건이 필요합니다.
개인 배포 빌드
일부 앱은 공공 스토어 사용자에게 전혀 가지지 않거나 narrower 그룹에 먼저 도달해야 하는 경우가 있습니다.
이것은 클라이언트 전용 빌드, 내부 직원 앱, 규제 워크플로우, field 운영 도구 및 enterprise-only 배포를 포함합니다. 이들은 설치할 수 있는 사용자 및 백엔드에 접근하는 사용자에 대한 엄격한 제어가 필요합니다.
이것은 이름이 위험해지는 곳입니다. 팀은 종종 “기업 빌드”라고 말하지만 실제로는 여러 가지 다른 것을 의미합니다:
- privately signed 내부 앱
- 스토어 배포 앱에 내부 전용 접근 제어를 사용하는 앱
- 고객 전용 브랜딩된 아티팩트
- 제품 출시 전의 후보 버전
운영 모델이 다르다. pipeline과 이름을 분리하여 유지하십시오.
제품 출시
제품 출시 버전은 사용자에게 공개되는 약속입니다. 앱 스토어, 플레이 스토어, 또는 사용자에게 승인된 채널로 배포됩니다.
이제 빌드는 평범해야 합니다. 그것은 칭찬입니다.
제품 출시 버전은 재현 가능해야 하며, 올바르게 서명되어야 하며, 릴리스 환경에서 테스트되어야 하며, 롤백 계획과 연결되어야 합니다. 마지막 순간的手수작업 편집, 기계에 특화된 HACK, 또는 "다음 빌드에서 수정하겠습니다."의 약속은 원하지 않습니다.
간단한 버전입니다.
소프트웨어 빌드 유형 및 그 특성
| 빌드 유형 | 대상 | 구성 | 배포 방법 |
|---|---|---|---|
| 지역 개발자 | 개인 개발자 | 일반적으로 로컬 환경에서 디버깅, 빠른 반복, 로컬 환경 설정 | 로컬 머신에서 직접 설치 |
| CI 검증 | 엔지니어링 팀 | 반복 가능한 자동 빌드, 공유 검사 | CI 아티팩트 저장소 |
| 야간 또는 캐니 | 내부 테스터, 선택된 팀원 | 초기 통합 상태, 제한된 롤아웃 | 내부 배포 도구 |
| 테스트 환경 | QA, 제품, 외부 테스터 | 일반적으로 릴리즈와 비슷한, 비공개 환경 매핑 | 테스트 플라이트, 플레이 테스트 트랙, 개인 링크 |
| 어드혹 또는 기업 | 내부 직원, 고객, 제한된 그룹 | 제어된 구성, 목적지 특정 서명 | 개인 배포 채널 |
| 운영 | 공개 사용자 | 최종 릴리즈 구성, 스토어 준비 서명 | App Store 또는 Google Play |
__CAPGO_KEEP_0__의 적절한 빌드 유형은 사용자가 위험에 대한 용납 범위와 일치하는 유형입니다. 대부분의 릴리즈 오류는 팀이 그 정렬을 생략했을 때 발생합니다.
Code 인증의 중요 역할
모바일에서 빌드 파일 자체만으로는 의미가 없습니다. 플랫폼은 신뢰할 수 있는 출처에서 왔으며 생성 후 nobody가 변경하지 않았다는 것을 증명해야 합니다. 그 증명은 code 인증.
컴파일이 완벽했지만 설치, 업로드, 또는 실행이 올바르게 작동하지 않은 빌드가 있었던 적이 있나요? 인증이 문제였을 가능성이 높습니다.
__CAPGO_KEEP_0__ 인증이 실제로 증명하는 것
모바일 팀에게서 code 인증은 세 가지 일을 합니다.
- 가ENU성: 앱을 개발자 또는 조직과 연결시킵니다.
- 완전성: 이것은 증명서가 서명된 이후로도 변조되지 않았는지 증명하는 데 도움이 됩니다.
- 인증: 특히 Apple 플랫폼에서, 이 또한 앱이 어디서 실행되고 어떻게 실행되는지 제어합니다.
그第三점이 많은 개발자들을 혼란스럽게 만드는 이유입니다. 서명은 단순히 신분만을 나타내는 것이 아닙니다. 또한 허가도 포함됩니다.
따라서 동일한 앱 code은 개발자가 로컬에서 실행하거나 테스터에게 배포하거나 내부 배포하거나 스토어에 제출하는 것에 따라서도 다른 서명 자료를 요구할 수 있습니다.
서명이 목적지에 따라 어떻게 변하는지
이것이 프로세스를 지속적으로 유지하는 정신 모델입니다: 서명은 배포에 따라 변합니다..
로컬 개발자 설치는 하나의 신분과 허가 집합을 사용합니다. 테스트 플라이트를 통해 전송된 베타 빌드는 다른 것을 사용합니다. 내부 배포 경로는 다시 다른 프로파일을 요구할 수 있습니다. 공개 스토어 릴리스에는 자신의 서명 기대와 검토 호환 가능한 패키징이 있습니다.
그것이 때문에 “빌드를 다시 서명하라”는 거의 항상 작은 요청이 아닙니다. 서명이 변하면, 증명서가 허용하는 목적지가 변할 수 있습니다.
엄격한 설정은 일반적으로 다음과 같습니다:
- CI에서 서명 자산을 저장합니다: 개인 노트북에서 사용하지 않습니다.
- 목표에 따라 분리된 구분: 개발, 사내 테스트, 기업, 스토어 릴리즈.
- 회전 및 접근 제어: 특히 계약자 또는 여러 제품 팀이 인프라를 공유할 때.
- 감사성: 팀이 웹 업데이트를 __CAPGO_KEEP_0__ 앱 내에서 배포할 때, 두 번째 서명层를 고려해야 하는 경우도 있습니다. 이 __CAPGO_KEEP_1__ 서명 업데이트기 __CAPGO_KEEP_0__ 업데이트기용 끝-to-끝 보안 개요는
If your team ships web updates inside a Capacitor app, there’s a second signing layer to think about as well. This overview of end-to-end security for Capacitor updater code signing 서명된 항목을 프로덕션 인프라와 같이 다루세요. 그게 정확히 그것입니다.
개발, 사내 테스트, 기업, 스토어 릴리즈.
__CAPGO_KEEP_0__
CI/CD와 업데이트 채널을 이용한 릴리스 조정
팀이 성숙해지면, 빌드의 종류를 알기 위한 문제가 아니라, 그들을 조정하는 문제가 됩니다. 그 조정을 인간의 추측력 없이 수행해야 합니다.
CI/CD에서 그 조정을 수행해야 합니다.
pipeline은 빌드 계약입니다.
신뢰할 수 있는 pipeline은 매번 동일한 질문에 답해야 합니다.
- 이 빌드는 무엇을 위해 생성되었는지
- 어떤 버전을 사용하는지
- 받은 환경 변수는 무엇인지
- 통과해야 하는 테스트는 무엇인지
- 적용되는 서명 식별자는 무엇인지
- 빌드 결과물은 어디로 전달되는지
That structure mirrors a good technical specification. A well-formed spec should include 목적과 범위, 기능 요구 사항, 설계 요구 사항, 기술 표준, 테스트 요구 사항, 배달 요구 사항 및 유지 보수 또는 유지 관리 요구 사항, 기술 사양 설명서에서 처럼 설명되어 있습니다.그 동일한 discipline은 CI/CD가 더 쉽게 이해할 수 있게 해주는데 pipeline이 script의 바구니에서 벗어나 실행 가능한 릴리스 정책이 되기 때문입니다.
실제로, pipeline이 결정해야 하며, 엔지니어가 수동으로 실행하지 않아야 합니다.
Branch rules, tags, approval steps, signing context, and deployment targets should all be encoded.
- 성공한 방법: Branch-driven intent:
- main, release branches, and tags가 다른 워크플로우를 트리거합니다. Explicit artifact naming:
- flavor, environment, and target이 출력에 표시됩니다. __CAPGO_KEEP_0__
한 번에 여러 플래그를 전달하는 '한 개의 유연한 스크립트' 접근 방식은 모든 스토어 또는 테스터가 필요한 플래그와 일치하는 것을 기대하는 것입니다.
채널은 바이너리 배포 후에 제어를 추가합니다.
네이티브 빌드는 여전히 coarse-grained입니다. 한 번 릴리스가 스토어에 배포되면, Capacitor 앱 내부의 웹 콘텐츠를 변경하는 것은 항상 새로운 바이너리를 다시 빌드하는 것이 아닙니다.
업데이트 채널이 유용해집니다. 채널은 설치된 프로덕션 바이너리 내부에서 사용자 또는 환경을 대상으로 웹 자산 업데이트를 푸시할 수 있게 해줍니다. Capacitor 팀의 경우, 하나의 옵션은 Capgo가 있습니다. 이 옵션은 signed 웹 번들을 대상 채널에 게시하여 자바스크립트, CSS, 복사본, 구성, 및 자산 변경을 푸시할 수 있습니다. 네이티브 셸을 매번 다시 빌드할 필요가 없습니다.
실용적인 패턴은 다음과 같습니다:
- CI/CD에서 바이너리 빌드: 네이티브 앱을 생성, 서명, 및 배포합니다.
- 채널 assignments: 사용자 또는 환경을 베타, 스테이징, 프로덕션, 또는 고객 특정 스트림에 매핑합니다.
- 선택적인 출시: 웹 변경 사항을 한 그룹에 보내기 전에 더 광범위한 노출을 기다리지 않습니다.
- 롤백 경로: 스토어 리뷰를 기다리지 않고 나쁜 업데이트를 비활성화하거나 되돌리기.
그 모델을 아직 설정하지 않았다면, creating and deleting update channels in Capacitor __CAPGO_KEEP_0__
이것은 채널이 작동하는 방식을 만드는 짧은 데모입니다.
모바일 팀이 필요로 하는 전략적 전환입니다. 빌드 타입은 단순히 아티팩트만이 아닙니다. CI/CD는 바이너리가 생성되는 방법을 제어합니다. 채널은 설치 후 변경 사항이 노출되는 방법을 제어합니다.
현대 빌드 워크플로우의最佳 관행
건전한 빌드 시스템은 의견이 있습니다. 개발자가 릴리스 동작을 임의로 변경할 수 없습니다.
강력한 설정 중에서私は 공통점을 발견했습니다. 몇 가지 습관을 공유합니다.
- __CAPGO_KEEP_0__: 각 축을 분명하게 구분하십시오:
- 맛, 환경, 서명 대상 및 배포 대상이 하나의 모호한 레이블에 섞여 있지 않도록 하십시오. CI가 팀에 대면하는 아티팩트를 생성하십시오:
- 개발용 빌드는 이해관계자에 대한 신뢰를 위한 것이 아닙니다. 릴리즈와 같은 조건에서 테스트하십시오:
- QA 및 베타 테스터는 실제 앱과 가장 가깝게 동작하는 것을 보게 하십시오. 서명 자산을 노트북에서 제거하십시오:
- 비밀은 제어된 인프라에 narrow access를 가지는 곳에 속해야 합니다. 아티팩트를 사람으로 읽을 수 있도록 이름을 지어야 합니다:
- 누군가가 파일이 무엇인지 몇 초 안에 식별할 수 없다면 이름이 나쁘다. 프로모션보다 재생성을 선호하십시오:
- Design rollback before launch: Capacitor rollback은 느리고 운영상 부담이 크다. 웹-layer rollback은 Capacitor 업데이트가 훨씬 빠를 수 있지만, 채널과 정책을 미리 계획해야만 한다.
가장 큰 마음의 변화는 이것이다: '어떤 빌드 스크립트를 실행해야 하나?' 라고 묻지 말라. '이 단계에서 어떤 위험을 관리하고 있는가?' 라고 묻자. 그 질문은 더 나은 빌드 시스템을 만든다.
워크플로가 그 질문에 명확하게 답한다면, 릴리즈 프로세스는 더 쉽게 운영할 수 있고, 더 쉽게 감사할 수 있고, 한 명의 주니어 엔지니어가 올바른 주문어를 기억해야 하는 것에 의존하지 않게 된다.
Capacitor 앱을 배포하는 팀이 릴리즈 워크플로에 대한 더 chặt한 제어가 필요하다면 Capgo 는 그 스택의 일부로 평가할 만한 가치가 있다. Capacitor 앱 내부의 웹 자산에 대한 목표된 라이브 업데이트를 처리하고, 서명된 번들을 지원하며, 채널 기반 롤아웃 및 롤백 제어를 지원하여, 원래 네이티브 빌드 PIPELINE을 교체하지 않고도 더 빠른 수정이 필요할 때 유용하다.
