1. 소개
At Rapido Cloud (www.rapido.cloud)에서 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 배포 프로세스를 통과하는 것보다 모바일 앱 배포를 훨씬 더 간단하고 빠르게, 유연하게 만들 수 있는 약속으로 저를 매료했습니다. 저는 과거에 웹 앱에 집중하여 모바일 앱을 배포한 적이 없으며, 이 모바일 앱은 저의 첫 번째 배포입니다.
I는 애플 테스트 플라이트에 앱을 성공적으로 배포하기 위해 필요한 학습 곡선을 두려워했지만, 쉽게 앱을 배포할 수 있었다. 나중에 CapacitorUpdater를 사용하여 업데이트를 배포하는 데 Capgo 시간을 훨씬 더 줄일 수 있었다.
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 IIonic. 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. 내 branching 및 release 모델, 그리고 semantic-release가 어디에 들어가는지
So 이제 내 배포가 Capgo 서버에 정상적으로 작동하고 있으므로, 이 과정을 자동화하고 CI/CD pipeline에 통합해야 한다.
이것은 내 branching 및 release 모델이 어떻게 구성되는지 설명한다.
모든 애플리케이션, 즉 모바일, 웹 또는 Salesforce :
- 개발은 branching
feature/...에서 수행된다.main그리고mainmerge된다. 이 branch는 대부분의 개발 branch의 기준이 되며, 유지보수 및 특정 기능을 위한 커스터마이즈된 배포 외에는 다른 branch와는 다르다. (이것에 대한 자세한 내용은 아래에 설명한다.) - 배포는 릴리스 branch에서 트리거됩니다. 릴리스 branch에서 트리거되는 배포는 다음과 같습니다 : prerelease branch (
productionetc.) 및 고객 또는 컨텍스트에 맞는 branch도 사용할 수 있습니다.alpha,beta,nightly배포는 pull request가 deployment branch로 merge될 때 트리거됩니다. - tag 트리거된 배포를 사용하지 않습니다. semantic release는 태그를 관리하고 나머지 모든 것을 관리하기 때문입니다. Gitlab Flow는 다음과 같습니다.
Gitlab Flow
https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022 semantic-release의 동작 방식에 대한 주의사항 :
A side-note on how semantic-release works :
In __CAPGO_KEEP_0__ branch에서 semantic-release가 트리거되면, 자동으로 이 branch의 새로운 버전 번호를 계산합니다. 이 버전 번호는 branch의 이전 태그의 버전 번호와 branch에 전달된 수정 사항 또는 기능에 따라 달라집니다. 수정 사항은 새로운 패치 버전을 생성하며, 기능은 새로운 마이너 버전을 생성합니다. 또한 prerelease alpha, beta, etc.를 포함한 버전 번호를 자동으로 포함합니다.
Semantic release는 conventional commits (see https://www.conventionalcommits.org/en/about)에 따라 정의된 수정 사항과 기능을 그룹화하여 커밋 로그를 생성합니다. semantic release에 구성된대로입니다.
또한 semantic release는 git (Github, 나의 경우) 병합된 pull request와 관련된 이슈에 댓글을 달아 태그와 릴리즈에 연결합니다. 마지막으로, 이 Github 릴리즈에서 소스 code, 바이너리 등 필요한 asset를 첨부합니다. CHANGELOG.md4. semantic release와 __CAPGO_KEEP_0__에서 branch, release/prerelease, channel
Capgo에서 semantic release를 사용하고 싶은 것은 다음과 같습니다.
semantic release가 Capgo 배포에 대해 다음을 수행하길 원합니다.
semantic release가 버전 번호를 생성하길 원합니다.
Capgo은 Conventional Commits standard-version 의 버전을 개발하고 문서화했습니다. 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) repos. They have documented on their blog the version scheme used by Capgo in their deployemnts (https://capgo.app/blog/how-version-work-in-capgo/https://__CAPGO_KEEP_0__.app/blog/how-version-work-in-__CAPGO_KEEP_1__/)JavaScript 번들은 'standard' semver 'Semantic Versioning' ( semantic-release https://semver.org
)을 따릅니다. 이것은 또한 (물론입니다!)이것은 또한 __CAPGO_KEEP_0__의 배포에서 사용하는 버전 체계에 대해 블로그에 문서화했습니다 (https://__CAPGO_KEEP_0__.app/blog/how-version-work-in-__CAPGO_KEEP_1__/). semantic-release 확대적으로.
저는 또한 semantic release가 다채로운 채널에서 앱 배포를 생성하도록 만들고 싶습니다.
위에서 설명한 것처럼, prerelease 버전을 branch 등에서 배포해야 합니다. alpha, beta, nightly 예를 들어, customer-specific 버전을 branch 등에서 배포해야 합니다. production-customer-jones, production-customer-doe등.
Capgo은 '채널' 기능을 제공하는데, 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.
이 버전 번호는 explicit하게 문서화되지 않았지만 Capgo에서 지원하고 있으므로, 저는 semantic release의 채널과 prerelease를 사용하여 __CAPGO_KEEP_1__ 채널을 사용하여 앱의 버전을 생성할 것입니다.
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 To __CAPGO_KEEP_0__ 업로드 옵션을 얻으십시오. 그 중에서 사용할 것은 다음과 같습니다.
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 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에서 list된 merge에 대해, semantic release는 배포를 트리거합니다.
branchesrepository의 secrets에 CAPGO_APIKEY 업데이트 CAPGO_APPID 여기.
semantic release의 동작은 configuration file에서 설정됩니다.
.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:branchesbranch (name), mapped to the Capgo channel (channelchannel (prerelease)으로 mapping하고 prerelease version number의 호출 방법을 설정합니다. 예를 들어,branch.prerelease = "development"semantic release가 생성한 version number은x.y.z-development.n- branch에 배포됩니다.
alpha그리고 branch는 모두 __CAPGO_KEEP_0__ 채널에 앱을 배포하지만, 버전 번호의 prerelease 이름이 다릅니다.alpha-nocapgo개발자 branch에 대한 배포alpha또는 - 모두 __CAPGO_KEEP_0__ 채널에 배포됩니다.
dev-rupert모두 __CAPGO_KEEP_0__ 채널에 배포됩니다. 버전 번호의 prerelease 키워드가 같습니다.dev-paul: semantic release의 첫 번째 단계에서 __CAPGO_KEEP_0__에 대한 올바른 접근 권한이 있는지 확인합니다. __CAPGO_KEEP_1__ __CAPGO_KEEP_2__에 대한 인증 확인을 추가하는 것을 기대합니다.developmentchannel on Capgo, all with the samedevelopmenthttps://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format
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: __CAPGO_KEEP_0__https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator: __CAPGO_KEEP_2__CHANGELOG.md@semantic-release/git: 이 애플리케이션의 Ionic 빌드와 semantic release 작업에 의해 업데이트된 파일을 커밋하세요 (package.json,CHANGELOG.md: __CAPGO_KEEP_0__ 릴리스에 __CAPGO_KEEP_0__ 파일을 첨부하세요ios/App/App.xcodeproj/project.pbxproj: 이 2 개의 명령어를 사용하여 앱 빌드를 준비하고 (@semantic-release/github) __CAPGO_KEEP_0__ 서버에 앱 번들을 효과적으로 배포하세요 (CHANGELOG.md앱 버전 번호를 계산하고 증가시키는 방법에 대한 설명이나 changelog, Github 태그 또는 릴리스를 생성하는 방법에 대한 설명은 없습니다. : semantic release가 기본적으로 모든 것을 처리하며 최소한의 구성으로 작동합니다.@semantic-release/execXCode Cloud를 사용하여 새로운 바이너리를 빌드합니다.prepareCmd) and then to effectively build deploy the app bundle to the Capgo servers (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를 사용하여 이 branch에서 변경이 발생할 때 빌드를 자동화합니다 (예를 들어, 이 branch에서 XCode Cloud를 사용하여 빌드를 자동화합니다.
XCode Cloud를 사용하여 이 branch에서 변경이 발생할 때 빌드를 자동화합니다 (예를 들어, 이 branch에서 XCode Cloud를 사용하여 빌드를 자동화합니다.
- XCode Cloud를 사용하여 이 branch에서 변경이 발생할 때 빌드를 자동화합니다 (예를 들어, 이 branch에서 XCode Cloud를 사용하여 빌드를 자동화합니다.
production) - XCode Cloud를 사용하여 이 branch에서 변경이 발생할 때 빌드를 자동화합니다 (예를 들어, 이 branch에서 XCode Cloud를 사용하여 빌드를 자동화합니다.
CHANGELOG.md파일이 업데이트되었습니다. 이 버전은 semantic release가 생성한 각 버전마다 업데이트됩니다. - 다른 branch에서 빌드를 트리거하여 각 채널에 대한 배포를 시뮬레이션할 수 있습니다. XCode Cloud에서 빌드를 구성할 때마다, 나는 __CAPGO_KEEP_0__의 값을 수동으로 환경 변수로 설정합니다.
branch.channel설정된 값입니다.releaserc.json(네, 이것은 수동 복제입니다.) 만약 내가 원한다면, 나는 이전에 언급한 것과 같이 커스텀 고객 애플리케이션을 배포하기 위해 커스텀 릴리즈 branch에서 각 커스텀 고객 애플리케이션에 대한 다른 AppStore 애플리케이션을 배포할 수 있습니다.
XCode Cloud에서 Capgo 채널을 사용하여 앱 바이너리를 빌드합니다.
7. 결론
결론을 내리자면, 나는 Capgo CapacitorUpdater를 내 표준 semantic release pipeline에 통합할 수 있었고, 14일 무료试用 기간 내에 빠르게 통합할 수 있었으며, 결과는 다음과 같습니다.
- semantic release는 자동으로 Capgo 서버와 호환되는 버전 번호를 생성합니다.
- semantic release는 Capgo 애플리케이션 번들을 자동으로 배포하며, Capgo 채널도 사용합니다.
- 이것은 XCode Cloud에서 애플리케이션 바이너리를 빌드하는 데 적합합니다.
다음 단계
I는 현재 이 앱의 개발 단계에 있습니다. iOS용으로 테스트 플라이트를 통해 빠르게 테스트자에게 제공할 것입니다. Capgo의 힘을 고려하여, 테스트를 위해 AppStore에 무료 버전의 앱을 배포할 것입니다. 테스트 중에는 Capgo을 정기적으로 업데이트할 것입니다. 그 다음으로, AppStore에 또 다른(유료) 버전의 앱을 배포하고, 또 다른 레코드 아래에 배포할 것입니다. 또한 테스트 중에는 Capgo를 정기적으로 업데이트할 것입니다.
Capgo에 대한 더 나은 빌드 전 검증을 추가하여, 내 semantic release 구성에 prerequisities를 추가하길 바랍니다. bundle upload 내가 Ionic + Angular + __CAPGO_KEEP_0__로 개발한 미래의 모바일 앱에 대해, 정리된, 간단하고 reproducible한 semantic release pipeline을 가지고 있습니다.
I now have a clean, simple an reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.
22년 이상 Salesforce에 대한 경험을 가지고 있습니다. 고객과 사용자, 파트너 및 통합자, 아키텍트, 개발자, 비즈니스 분석가 및 컨설턴트로 Salesforce에 대한 경험을 가지고 있습니다. 또한 13년 동안 프랑스의 성공적인 Salesforce SI 파트너인 Altius Services의 COO 및 CTO로 공동 설립 및 공동 관리했습니다. 그리고 나서 새로운 모험을 시작하여 Salesforce 솔로 프레너로서 Rapido Cloud의 제품을 제공하기 위해
링크드인에서 나를 찾으세요. https://linkedin.com/in/rbarrow Rapido Cloud의 Salesforce 제품을 확인하세요.
https://www.rapido-companion.app __CAPGO_KEEP_0__.
__CAPGO_KEEP_1__ __CAPGO_KEEP_2__ 및 https://www.rapido.cloud (개발 중입니다.).
Capgo CapacitorUpdater를 사용하여 How Rapido Cloud가 Semantic Release를 관리하는 것부터 계속하세요.
live update delivery를 계획하고 싶다면 __CAPGO_KEEP_0__ Live Updates와 연결하세요. live update delivery를 위한 product workflow는 Capgo Live Updates에서 확인하세요. Overview Capgo Live Updates for the product workflow in Capgo Live Updates, Keep going from How Rapido Cloud manage Semantic Release with __CAPGO_KEEP_0__ CapacitorUpdater If you are using If you are using __CAPGO_KEEP_0__ 구현 세부 사항에 대해 업데이트 동작 __CAPGO_KEEP_0__ 구현 세부 사항에 대해, 그리고 업데이트 유형 __CAPGO_KEEP_0__ 구현 세부 사항에 대해.
