1. 소개
Rapido Cloud (www.rapido.cloud)에서 저는 Salesforce 고객사들이 Salesforce Mobile SDK 또는 Salesforce Mobile Publisher를 사용하는 복잡한 절차를 거치지 않고, 자체 브랜드를 적용한 모바일 앱을 쉽게 배포할 수 있도록 모바일 애플리케이션을 개발하고 있습니다.
저는 Ionic 8, Angular 18, TypeScript, Capacitor 그리고 이제는 Capgo CapacitorUpdater까지, 널리 쓰이는 컴포넌트와 도구로 구성된 현대적이고 "표준적인" 플랫폼에서 이 모바일 앱을 개발했습니다. 이런 구성은 Lightning Web Components 같은 Salesforce 플랫폼 특유의 기술을 관리하고 싶지 않은 클라이언트에게 훨씬 다루기 쉽습니다. 또한 저에게도 Ionic + Angular 모바일 앱 개발자와 유지보수 담당자를 채용하기가 더 쉽고 비용도 저렴합니다.
이 글에서는 저의 설계와 선택, 구현을 설명합니다. 이것들이 Capgo과 함께 semantic-release 모든 배포를 Github Actions로 자동 관리하는 아주 성공적이고 간단한 방법이 되게 합니다. 이 모든 것은 Capgo CapacitorUpdater의 14일 무료 체험 기간 동안 설계하고 테스트하고 문서화했습니다.
2. 왜 Capgo를 사용할까요? 왜 semantic-release를 사용할까요?
Capgo CapacitorUpdater는 표준 Apple AppStore/Google PlayStore 배포 과정보다 모바일 앱 배포를 훨씬 더 단순하고 빠르고 유연하게 해준다는 점에 끌렸습니다. 그동안 주로 Salesforce Experience Cloud에서 웹 앱을 개발해 왔기에, 이번이 스토어에 출시하는 저의 첫 번째 모바일 애플리케이션입니다.
성공적으로 출시할 수 있을지 학습 곡선이 걱정스러웠지만, 앱을 Apple TestFlight에 올리는 건 꽤 쉬웠습니다. 그 후 Capgo CapacitorUpdater로 업데이트를 훨씬 빠르게 배포할 수 있었습니다.
저의 첫 번째 요구사항이자 테스트 케이스는 Ionic에서 권장하는 Nexus 모바일 브라우저를 통한 모바일 에뮬레이터나 시뮬레이터에서 테스트하는 대신, 실제 제 휴대폰에서 실제 모바일 앱으로 앱을 배포해 직접 테스트하는 것이었습니다. 제 앱은 Geolocation이나 사진 갤러리, 카메라 접근 같은 네이티브 기능을 사용하기 때문입니다. Capacitor 모바일 앱을 테스트해 본 경험이 없어서 모든 것이 제대로 작동할지 확신할 수 없었습니다. 실제 환경에서 실제 앱을 테스트하는 것만큼 좋은 방법은 없죠!
그래서 Capgo CapacitorUpdater 덕분에 소스 code에 새로운 기능이나 수정 사항을 저장한 지 단 1분 만에 제 모바일에서 실시간으로 앱을 업데이트할 수 있었습니다. 정말 안심됐고, 유연하며 설정도 간편했습니다!
3. 브랜치 및 릴리스 모델과 semantic-release 활용법
이제 Capgo 서버로의 배포가 정상적으로 작동하니, 이를 자동화해 CI/CD 파이프라인에 통합해야 합니다.
제가 브랜치와 릴리스 모델을 구성하는 방식입니다
모바일, 웹, Salesforce 등 모든 애플리케이션에 대해:
- 개발은 다음에서 이루어집니다
feature/...분기된 브랜치main, 그리고 다음으로 머지됩니다main대부분의 개발 브랜치의 기준이 되는 브랜치입니다. 유지보수나 특정 커스텀 배포를 위한 기능 브랜치는 제외됩니다(자세한 내용은 아래 참조) - 배포가 트리거됩니다 릴리스 브랜치에서 다음과 같을 수 있습니다:
production, 프리릴리스 브랜치(alpha,beta,nightly등) 및 커스텀 배포를 위한 고객별 또는 컨텍스트별 브랜치 - pull request가 배포 브랜치에 병합될 때 배포가 트리거됩니다. semantic release가 태그와 나머지 작업을 관리해 주므로 태그 기반 배포는 사용하지 않습니다.
기본적으로 Gitlab Flow 방식입니다:
Gitlab Flow - 출처 https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
semantic-release 작동 방식에 대한 참고 사항:
배포 브랜치에서 semantic-release가 트리거되면, 해당 브랜치의 이전 태그 버전과 전달된 수정 사항 또는 기능에 따라 새 버전 번호를 자동으로 계산합니다. 수정 사항은 patch 버전을, 기능은 minor 버전을 생성합니다. 또한 prerelease도 자동으로 포함됩니다. alpha, beta, 등이 버전 번호에 포함됩니다.
Semantic release는 커밋에서 changelog를 생성하고, conventional commits에 정의된 대로 fix와 feature를 그룹화합니다(참조: https://www.conventionalcommits.org/en/about) 및 semantic release에서 설정한 대로.
또한 git(Github, 제 경우)의 머지된 pull request와 관련 issue 모두에 태그와 release에 연결하는 코멘트를 남겨 업데이트합니다. 마지막으로 이번 Github release에서는 소스 code, 필요 시 바이너리 등 CHANGELOG.md등의 에셋을 첨부합니다.
4. semantic release 및 Capgo에서의 브랜치, release/prerelease, 채널
그래서 Capgo 배포를 위해 semantic release가 하길 원하는 작업은 다음과 같습니다.
semantic release가 버전 번호를 생성하도록 하고 싶습니다.
Capgo는 “Conventional Commits” 도구의 자체 버전을 개발하고 문서화했습니다. standard-version fork한 레포지토리와 함께 standard-version (https://github.com/Cap-go/standard-version, 그리고 자체 capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) 및 capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) 레포지토리입니다. 이들은 블로그에 Capgo가 배포에서 사용하는 버전 체계를 문서화했습니다 (https://capgo.app/blog/how-version-work-in-capgo/). JavaScript bundle은 “standard” semver “Semantic Versioning” (https://semver.org)을 semantic-release 역시 따릅니다 (당연히!)
정말 다행이고 안심이 됩니다. 저는 semantic-release 아주 많이 사용하고 있거든요.
또한 semantic release가 다양한 채널에 앱 배포를 생성하도록 만들고 싶습니다.
앞서 언급했듯이, 다음과 같은 브랜치에서 prerelease 버전을 배포해야 합니다. alpha, beta, nightly 등등, 그리고 다음과 같은 브랜치에서는 고객별 버전도 배포해야 합니다. production-customer-jones, production-customer-doe등의 에셋을 첨부합니다.
Capgo는 semantic release가 지원하는 기능과 정확히 같은 “channels” 기능을 제공하기 때문에, 이 둘을 함께 연동할 수 있어 기대가 큽니다. 이는 XCode Cloud에서 관리하는 브랜치별 빌드와도 잘 맞습니다(자세한 내용은 아래 참조).
semantic release가 prerelease에서 생성하는 Semver 버전 번호는 다음과 같습니다. 1.0.0-alpha.1이 브랜치에서 빌드가 이어지면 빌드 번호가 다음과 같이 증가합니다. 1.0.0-alpha.2, 등입니다. 명시적으로 문서화되어 있지는 않지만 Capgo가 이런 버전 번호를 지원하며, 이는 저에게 매우 반가운 소식입니다. 저는 semantic release의 channels와 prerelease를 활용해 Capgo 채널로 앱 버전을 만들 계획입니다.
5. Capgo를 사용해 애플리케이션을 릴리스하려면 어떻게 해야 하나요?
앱 번들을 Capgo에 자동으로 배포하려면 Capgo CLI 명령어를 사용해야 합니다. bundle upload다음 명령어를 입력하세요. npx @capgo/cli@latest bundle upload --help 다양한 upload 옵션을 볼 수 있습니다. 그중에서 다음 옵션을 사용하겠습니다:
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- CHANNEL은 배포하려는 Capgo 채널입니다 (예:
alpha) - VERSION은 semantic release에 의해 생성됩니다 (예:
1.0.0-alpha.1) - CAPGO_APIKEY는 Capgo에서 제공되며, CI/CD 파이프라인 로그인을 고유하게 식별하는 데 사용됩니다
- CAPGO_APPID는 Capgo에서 제공되며, 애플리케이션을 고유하게 식별하는 데 사용됩니다 (예:
com.mystartup.mysuperapp)
6. semantic-release와 Capgo CapacitorUpdate 설정
결국, 이 모든 것이 어떻게 하나로 이어지는 걸까요?
semantic release와 Github Actions로 빌드된 앱 번들 버전
Github Actions를 이용한 semantic-release 자동화
semantic release의 장점은 배포 자동화가 Github Action 워크플로우 형태로 매우 간단하다는 점입니다. 다른 CI/CD 플랫폼에서도 매우 유사하게 구성됩니다.
# ./github/workflows/release.yml
name: Release
on:
workflow_dispatch:
push:
branches: [alpha, alpha-nocapgo, dev-rupert] # <--- adapt this
env:
CAPGO_APPID: com.mystartup.mysuperapp # <--- adapt this
CAPGO_APIKEY: ${{ secrets.CAPGO_APIKEY }}
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: 24
cache: "npm"
- run: npm install
- run: npx semantic-release
env:
DEBUG: true
GITHUB_TOKEN: ${{ github.token }}이것은 NodeJS 환경을 설치한 후 semantic release를 호출합니다.
에 나열된 브랜치에 merge할 때마다 branches, semantic release가 배포를 트리거합니다.
설정 CAPGO_APIKEY 을 리포지토리의 secrets에 설정하세요.
업데이트 CAPGO_APPID 여기에서 확인하세요.
semantic release의 동작은 다음에서 설정됩니다. .releaserc.json 설정 파일입니다.
아래는 제 설정과 설명입니다:
// .releaserc.json
{
"branches": [
{
"name": "release",
"channel": "production"
},
{
"name": "alpha",
"channel": "alpha",
"prerelease": "alpha"
},
{
"name": "alpha-nocapgo",
"channel": "alpha",
"prerelease": "alpha-nocapgo"
},
{
"name": "dev-rupert",
"channel": "development",
"prerelease": "development"
},
{
"name": "dev-paul",
"channel": "development",
"prerelease": "development"
}
],
"ci": true,
"debug": true,
"dryRun": false,
"repositoryUrl": "https://github.com/RupertBarrow/mysuperapp",
"verifyConditions": ["@semantic-release/github"],
"plugins": [
[
"@semantic-release/commit-analyzer",
{
"preset": "angular",
"releaseRules": [
{ "type": "breaking", "release": "major" },
{ "type": "feat", "release": "minor" },
{ "type": "fix", "release": "patch" },
{ "type": "ci", "release": "patch" },
{ "type": "doc", "release": "patch" },
{ "type": "docs", "release": "patch" },
{ "type": "refactor", "scope": "core-*", "release": "minor" },
{ "type": "refactor", "release": "patch" },
{ "scope": "no-release", "release": false }
]
}
],
"@semantic-release/release-notes-generator",
["@semantic-release/changelog", { "changelogFile": "CHANGELOG.md" }],
[
"@semantic-release/git",
{
"assets": ["package.json", "CHANGELOG.md", "ios/App/App.xcodeproj/project.pbxproj"],
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
}
],
["@semantic-release/github", { "assets": ["CHANGELOG.md"] }],
[
"@semantic-release/exec",
{
"prepareCmd": "npm run build",
"publishCmd": "npm add -D @capgo/cli && npx @capgo/cli bundle upload --channel ${branch.channel} --apikey $CAPGO_APIKEY --bundle ${nextRelease.version} --bundle-url $CAPGO_APPID"
}
]
]
}branches:branches브랜치 설정을 지정합니다 (name)를 Capgo 채널에 매핑하고 (channel) 사전 릴리스 버전 번호를 어떻게 부를지 정의합니다 (prerelease). 예를 들어,branch.prerelease = "development"인 경우, semantic release가 생성하는 버전 번호는x.y.z-development.n- 에 배포하는
alpha및alpha-nocapgo브랜치 모두 앱을alpha채널에 배포하지만, 버전 번호의 사전 릴리스 이름은 다릅니다 - 개발자 브랜치에 배포하는
dev-rupert또는dev-paul둘 다developmentCapgo의 채널에 배포되며, 모두 동일한development버전 번호에 prerelease 키워드를 포함합니다
verifyConditions: semantic release의 첫 단계에서 Github에 대한 올바른 접근 권한을 확인합니다. 추후 여기에 Capgo CLI 인증 체크를 추가할 예정입니다@semantic-release/commit-analyzer: 표준 semantic release 작업 - 문서 참고 (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator: changelog 파일을CHANGELOG.md@semantic-release/git: Ionic 앱 빌드 및 semantic release 작업으로 업데이트된 다음 파일들을 커밋합니다 (package.json,CHANGELOG.md및ios/App/App.xcodeproj/project.pbxproj- 아직 Android 빌드는 하지 않습니다)@semantic-release/github:CHANGELOG.md파일을 Github 릴리스에 자산으로 첨부합니다@semantic-release/exec: 이 두 명령어로 앱 빌드를 준비하세요 (prepareCmd) 그리고 앱 번들을 Capgo 서버에 실제로 빌드 및 배포하세요 (publishCmd)
버전 번호 계산 및 증분 방식, changelog 생성, Github 태그 또는 릴리스 생성 등에 대해 설정을 설명할 필요가 없다는 점을 눈치채실 것입니다. semantic release가 최소 설정으로 기본적으로 모두 처리합니다.
XCode Cloud를 이용한 새로운 바이너리 빌드
이 모든 것을 XCode Cloud와 통합하여 애플리케이션 바이너리의 새 버전을 빌드하는 것은 간단합니다 (아직 Google Play에 배포하지는 않았지만, 그 빌드도 비슷할 것입니다) :
- 사용하려는 브랜치(예: )에 변경 사항이 있을 때 빌드되도록 XCode Cloud 프로세스를 설정했습니다
production) - 이 브랜치에서 XCode Cloud가 빌드되도록 설정한 것은
CHANGELOG.md파일이 업데이트될 때만입니다. semantic release가 각 버전을 생성한 후 이 파일이 업데이트됩니다 - 다양한 채널에 대한 배포를 시뮬레이션하기 위해 서로 다른 브랜치에서 빌드를 트리거할 수 있습니다. 브랜치마다 다른 XCode Cloud 빌드 구성에서 환경 변수를 다음과 같은 값으로 직접 설정합니다.
branch.channel에 설정된releaserc.json(네, 수동으로 중복한 것입니다) 그리고 원한다면, 앞서 언급했듯이 커스텀 릴리스 브랜치에서 배포한 각 고객용 애플리케이션마다 다른 AppStore 애플리케이션을 배포할 수도 있습니다.
Capgo 채널을 사용한 XCode Cloud 앱 바이너리 빌드
7. 마치며
결론적으로, 14일 트라이얼 기간 안에 빠르게 Capgo CapacitorUpdater를 표준 semantic release 파이프라인에 통합할 수 있어 매우 만족스럽고, 결과는 다음과 같습니다.
- bundle 버전 번호는 semantic release에서 자동으로 생성되며 Capgo 서버와 호환됩니다
- semantic release가 Capgo 애플리케이션 bundle을 자동으로 배포하고 Capgo 채널도 활용합니다
- 이는 애플리케이션 바이너리의 XCode Cloud 빌드와 잘 맞아떨어집니다
다음 단계
현재 이 앱은 개발 단계에 있습니다. 곧 TestFlight(iOS)를 통해 테스터들에게 공개할 예정입니다. Capgo의 강력함을 고려하면, 테스트용 무료 버전을 AppStore에 배포해 테스트 기간 동안 Capgo로 정기적으로 업데이트할 것입니다. 그다음 별도의 레코드로 유료 버전을 AppStore에 배포하고, 이 역시 Capgo로 정기적으로 업데이트할 것입니다.
Capgo 사전 요구 사항에 대한 더 나은 빌드 전 검증을 bundle upload semantic release 설정에 추가하고 싶습니다.
이제 Ionic + Angular + Capacitor로 개발할 향후 모바일 앱을 위한 깔끔하고 단순하며 재현 가능한 semantic release 파이프라인을 갖추게 되었습니다.
작성자 - Rupert Barrow
저는 고객이자 사용자, 파트너이자 통합자, 아키텍트, 개발자, 비즈니스 분석가, 컨설턴트로서 Salesforce에서 22년 넘게 경험을 쌓았습니다. 프랑스의 성공적인 Salesforce SI 파트너인 Altius Services를 공동 창립하고 13년간 COO 및 CTO로 공동 운영한 뒤, 이제는 Salesforce 솔로프레너로서 제 Rapido Cloud 제품과 함께 새로운 도전을 시작했습니다.
LinkedIn에서 저를 찾으실 수 있습니다: https://linkedin.com/in/rbarrow.
저희 Salesforce 서비스는 다음에서 확인하실 수 있습니다: https://www.rapido-companion.app 및 https://www.rapido.cloud (개발 중).
How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater에서 이어서 보기
사용 중이라면 Rapido Cloud가 Capgo CapacitorUpdater로 Semantic Release를 관리하는 방법 live update 배포를 계획하려면, 다음과 연결하세요 Capgo Live Update Capgo Live Updates의 제품 워크플로우를 보려면, 개요 Overview의 구현 상세를 보려면, 기능 Features의 구현 상세를 보려면, 업데이트 동작 Update Behavior의 구현 세부 사항은 다음과 같고, 업데이트 유형 Update Types의 구현 세부 사항은 다음과 같습니다.
