1. 소개
Rapido Cloud (www.rapido.cloud)에서 Salesforce 고객을 위한 모바일 애플리케이션을 개발하고 있습니다. 이 애플리케이션은 Salesforce 고객이 자신의 브랜드를 가진 모바일 애플리케이션을 쉽게 배포할 수 있도록 해 주며, Salesforce Mobile SDK 또는 Salesforce Mobile Publisher를 사용하는 어려운 루프를 피할 수 있습니다.
이 앱은 현대적인 표준 플랫폼에 널리 사용되는 컴포넌트와 도구를 포함하여 Ionic 8, Angular 18, TypeScript, Capacitor 및 현재 Capgo CapacitorUpdater를 사용하여 개발되었습니다. 이들은 Salesforce 플랫폼의 Lightning Web Components와 같은 특정 사항을 관리하지 않으려는 고객들을 위해 더 간단하게 관리되며, 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를 사용하여 업데이트를 더 빠르게 배포할 수 있었습니다.
My first requirement and test case was to deploy for myself to test my app as a real mobile app on my own phone, instead of testing in a mobile emulator or in a simulator via the Nexus mobile browser suggested by Ionic. That’s because my app uses native features such as Geolocation or accessing the Photo Gallery and Camera. Not having the past experience of testing a Capacitor mobile app, I wasn’t sure if everything was going to work properly : nothing better than to test the real app, in real conditions !
So Capgo CapacitorUpdater helped me update my application on my mobile, live, 1 minute after saving a new feature or fix in my source code : so relieving, and so flexible, and easy to set up !
3. 나의 branch 및 릴리즈 모델, 그리고 semantic-release가 어디에 들어가는지
So now I have my delivery to Capgo servers working correctly, I need to automate this and fit it into my CI/CD pipeline.
This is how I organize my branching and release model
For every application, whether mobile, web or Salesforce :
- 개발은 branch로 나뉘어
feature/..., 그리고 그들은mainintomainreference로 가장 많은 개발 branch에 - 외 trừ 유지보수 및 특정 기능을 위한 custom delivery (이하에 대해 더 자세히 설명하겠습니다.)에 대해서는 유지됩니다. deployment은 trigger됩니다. 릴리즈 branch에서 예를 들어 :
productionprerelease branch (alpha,beta,nightly등) 및 고객 또는 컨텍스트에 맞는 branch를 사용하여 커스터마이즈된 배포를 위해 - 배포는 pull request가 deployment branch에 병합될 때 트리거됩니다. 나는 태그 트리거 배포를 사용하지 않습니다. 왜냐하면 semantic release가 태그와 나머지 모든 것을 관리하기 때문입니다. Gitlab Flow는 다음과 같습니다.
Gitlab Flow
https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022 semantic-release에 대한 한 가지 주의사항 :
deployment branch에서 semantic-release가 트리거될 때, semantic-release는 이 branch의 이전 태그의 버전 번호와 제공된修정 또는 기능에 따라 이 branch에서 자동으로 새로운 버전 번호를 계산합니다.修정은 새로운 패치 버전을 만들며, 기능은 새로운 마이너 버전을 만듭니다. 또한 prerelease를 자동으로 포함합니다.
__CAPGO_KEEP_0__ alpha, beta, 버전 번호 등.
Semantic release는 커밋으로부터 릴리스 노트를 생성하며, conventional commits ( conventional commits에 대한 자세한 내용은 https://www.conventionalcommits.org/en/about 에서 확인할 수 있습니다.)에 정의된修정 및 기능을 그룹화합니다. 또한 semantic release는 git (__CAPGO_KEEP_0__, 나의 경우) 병합된 pull request 및 관련된 이슈에 릴리스 태그 및 릴리스에 대한 링크를 포함하는 댓글을 업데이트합니다. 마지막으로, 이 __CAPGO_KEEP_1__ 릴리스에서는 소스 __CAPGO_KEEP_2__, 필요시 바이너리와 같은 자산을 첨부합니다., 버전 번호 등.
It will also update all your git (Github, in my case) merged pull requests and related issues with comments linking them to the tag and release. Finally, in this Github release, it will attach assets such as source code, binaries if necessary, CHANGELOG.mdCapgo의 __CAPGO_KEEP_0__ 배포에 대해 semantic release가 수행해야 하는 작업은 다음과 같습니다.
Capgo는 Capgo에서 개발하고 문서화한 "Conventional Commits"의 "표준 버전"을 fork한 repo를 가지고 있습니다.
https://Capgo.com/Cap-go/standard-version
https://www.conventionalcommits.org/en/about
https://Capgo.com/Cap-go/standard-version standard-version __CAPGO_KEEP_0__ 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/). 자바스크립트 번들을 위한 버전 체계는 ‘standard’ semver ‘Semantic Versioning’ (https://semver.org)을 따릅니다. semantic-release 그것도 당연히 따라합니다.
그래서 그게 좋고, 나에게는 큰 편리함입니다. 왜냐하면 나는 semantic-release __CAPGO_KEEP_1__
I also want semantic release to generate app deployments on different channels
As mentioned above, I need to deploy prerelease version from branches such as alpha, beta, nightly 등, 고객 전용 버전을 위한 branch도 필요합니다. production-customer-jones, production-customer-doe등
Capgo은 “channels” 기능을 제공하는데, semantic release도 지원하기 때문에 함께 사용하기를 기대합니다. 이 기능은 XCode Cloud가 관리하는 다른 branch 빌드와도 잘 맞습니다.
Semantic release가 prerelease에서 생성하는 Semver 버전 번호는 다음과 같습니다. 1.0.0-alpha.1이 branch에서 빌드가 계속되면 빌드 번호가 1.0.0-alpha.2, etc. Although not documented explicitly, these version numbers are supported by Capgo, which is great news for me : I will use semantic release channels and prerelease to generate versions of my app with Capgo channels.
이러한 버전 번호는 Capgo에서 지원하고 있으므로, 나는 semantic release의 channel과 prerelease를 사용하여 __CAPGO_KEEP_1__ channel을 사용하여 앱의 버전을 생성할 것입니다.
To automate deployment of your app bundles to Capgo, you need to use the Capgo CLI command bundle upload__CAPGO_KEEP_0__에 앱 배포를 자동화하기 위해서는 __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ 명령어를 사용해야 합니다. npx @capgo/cli@latest bundle upload --help 타입을 입력하여 업로드 옵션을 확인할 수 있습니다. 그 중에서 다음 옵션을 사용하겠습니다.
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- Capgo 채널은 배포하고자 하는 Capgo 채널입니다 (예를 들어
alpha) - __CAPGO_KEEP_0__ 버전은 semantic release가 생성합니다 (예를 들어
1.0.0-alpha.1) - CAPGO_APIKEY는 Capgo에서 제공하는 CI/CD pipeline 로그인에 고유한 식별자를 제공합니다
- 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를 호출하는 것입니다.
branch에 목록된 모든 머지에 대해 CI/CD 플랫폼에서 수행됩니다 branchessemantic release는 배포를 트리거합니다.
설정 CAPGO_APIKEY repository의 비밀을 설정합니다.
업데이트 CAPGO_APPID 여기.
semantic release의 동작은 설정 파일에서 결정됩니다.
아래는私の 설정입니다. .releaserc.json branch의 설정 (
// .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)을 __CAPGO_KEEP_0__ 채널 (name), mapped to the Capgo channel (channel)으로 매핑합니다. 예를 들어,prerelease)이 설정되어 있다면 semantic release가 생성하는 버전 번호는branch.prerelease = "development"가 됩니다.x.y.z-development.n- 배포를
alpha배포alpha-nocapgobranch는 __CAPGO_KEEP_0__ 채널에 모두 배포되며, 버전 번호의 prerelease 이름이 다릅니다.alphadeveloper branch에 대한 배포는 __CAPGO_KEEP_0__ 채널에 모두 배포되며, 버전 번호의 prerelease 이름이 다릅니다. - developer branch에 대한 배포는 __CAPGO_KEEP_0__ 채널에 모두 배포되며, 버전 번호의 prerelease 이름이 다릅니다.
dev-rupert또는dev-paul__CAPGO_KEEP_0__ 채널에 모두 배포되며, 버전 번호의 prerelease 이름이 같습니다.development: semantic release의 첫 번째 단계에서 Capgo에 대한 올바른 접근 권한이 있는지 확인합니다. __CAPGO_KEEP_1__ __CAPGO_KEEP_2__에 대한 인증 확인을 나중에 추가하길 바랍니다.development: semantic release의 표준 기능입니다. 자세한 내용은 문서를 참조하세요 (
verifyConditions: in the first stage of semantic release, it checks that it has the correct access to Github. I hope to add an authentication check for the Capgo CLI here later@semantic-release/commit-analyzer: 변경 로그 파일을 생성합니다.: github에서 업데이트된 Ionic 빌드와 semantic release 작업에 의해 업데이트된 파일을 커밋합니다.)@semantic-release/release-notes-generator: __CAPGO_KEEP_0__에서 업데이트된 Ionic 빌드와 semantic release 작업에 의해 업데이트된 파일을 커밋합니다.CHANGELOG.md@semantic-release/git: __CAPGO_KEEP_0__에서 업데이트된 Ionic 빌드와 semantic release 작업에 의해 업데이트된 파일을 커밋합니다.package.json,CHANGELOG.md그리고 안드로이드를 위해 빌드하지 않습니다.ios/App/App.xcodeproj/project.pbxproj: __CAPGO_KEEP_0__ 릴리스에 __CAPGO_KEEP_0__의 자산으로 파일을 첨부하세요@semantic-release/github: 앱 빌드 준비를 위해 이 2개의 명령어를 사용하세요 (CHANGELOG.md) 그리고 앱 번들을 Github 서버로 효과적으로 빌드 배포하세요 (@semantic-release/exec__CAPGO_KEEP_0__ 서버에 앱 번들을 배포합니다.prepareCmd버전 번호를 계산하고 증가시키는 방법에 대한 설명이나 changelog, Capgo 태그 또는 릴리스를 생성하는 방법에 대한 설명이 없습니다. : semantic release가 기본적으로 모든 것을 처리하며 최소한의 설정만 필요합니다.publishCmd)
You will notice that their is no fiddling around with explaining how we want the version number to be calculated and incremented, how we need to generate a changelog, a Github tag or release, etc. : everything is handled by default by semantic release, with minimal configuration.
XCode Cloud와 통합하여 애플리케이션 바이너리의 새로운 버전을 빌드하는 것은 간단합니다 (Google Play로 배포하지 않지만, 그 빌드는 비슷해야 합니다) :
XCode Cloud 프로세스를 설정하여 특정 branch에서 변경이 발생할 때 빌드를 자동화합니다 (예를 들어, 이 branch에서 XCode Cloud를 빌드할 때만 __CAPGO_KEEP_0__ 파일이 업데이트되면 빌드를 자동화합니다.
- __CAPGO_KEEP_0__ 파일이 업데이트되면 빌드를 자동화합니다.
production) - semantic release가 생성한 각 버전마다 __CAPGO_KEEP_0__ 파일이 업데이트됩니다.
CHANGELOG.md__CAPGO_KEEP_0__ 파일이 업데이트되면 빌드를 자동화합니다. - 다양한 branch에서 빌드를 트리거하여 다른 채널에 대한 배포를 시뮬레이션할 수 있습니다. XCode Cloud에서 빌드하는 각 구성에서, 나는 __CAPGO_KEEP_0__의 값을 가진 환경 변수를 수동으로 설정합니다.
branch.channel__CAPGO_KEEP_0__를 설정합니다.releaserc.json(네, 이것은 수동 복제입니다) 그리고 나서, 만약에 내가 싶다면, 나는 이전에 언급된 것과 같이 각 커스텀 고객 애플리케이션을 배포하는 커스텀 릴리즈 branch에서 다른 AppStore 애플리케이션을 배포할 수 있습니다.
XCode Cloud에서 Capgo 채널로 앱 바이너리를 빌드합니다.
7. 결론
결론을 내리자면, 나는 Capgo CapacitorUpdater를 내 표준 의미론적 릴리즈 pipeline에 통합할 수 있었고, 14일의 시험 기간 동안 빠르게 통합할 수 있었으며, 결과는 다음과 같습니다.
- semantic release는 의미론적 릴리즈가 자동으로 Capgo 서버와 호환되는 버전 번호를 생성합니다.
- semantic release는 Capgo 애플리케이션 번들을 자동으로 배포하며, Capgo 채널도 사용합니다.
- 이것은 앱 바이너리 XCode Cloud 빌드와 잘 맞습니다.
다음 단계
나는 현재 이 앱의 개발 단계에 있습니다. 나는 TestFlight (iOS용)으로 빠르게 테스터에게 앱을 제공할 것입니다. Capgo의 힘을 고려하여, 나는 테스트를 위해 AppStore에 무료 버전의 앱을 배포할 것입니다. 테스트 중에는 Capgo로 자주 업데이트될 것입니다. 그리고 나서, 나는 AppStore에 또 다른 (유료) 버전의 앱을 배포할 것입니다. 또 다른 레코드에서 배포하고, 테스트 중에는 Capgo로 자주 업데이트될 것입니다.
Capgo을 더 나은 빌드 전 검증으로 추가하여 내 semantic release 구성에 bundle upload 기본 조건을 넣기를 바랍니다.
Ionic + Angular + Capacitor로 개발된 미래의 모바일 앱에 대해 내 semantic release pipeline이 깨끗하고 간단하며 reproducible합니다.
작가 - Rupert Barrow
Salesforce에 대해 22년 이상의 경험을 가지고 있습니다. 고객과 사용자, 파트너와 통합자, 아키텍트, 개발자, 비즈니스 분석가 및 컨설턴트로 다양한 역할을 수행했습니다. Altius Services의 공동 설립자이자 13년 동안 COO와 CTO로 공동 관리했습니다. 프랑스에서 성공적인 Salesforce SI 파트너로 hoạt động한 후, 새로운 모험을 시작하여 Salesforce 솔로 프레너로서 Rapido Cloud의 제품을 제공합니다. 링크드인에서 나를 찾으세요.
https://linkedin.com/in/rbarrow Rapido Cloud의 Salesforce 제품을 확인하세요..
https://www.rapido-companion.app and https://www.rapido-companion.app https://www.rapido.cloud (개발 중입니다.)
