Rapido Cloud가 Capgo CapacitorUpdater와 함께 세마틱 릴리즈를 어떻게 관리하는가?

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 및 Capgo Actions를 사용하여 모든 배포를 자동으로 관리하는 __CAPGO_KEEP_1__ CapacitorUpdater의 설계, 선택 및 구현에 대한 설명입니다. 이 모든 것이 __CAPGO_KEEP_1__ CapacitorUpdater의 14일 무료试用 기간 동안 설계, 테스트 및 문서화되었습니다. semantic-release a very successful no-brainer for managing all deployments automatically via Github Actions. All this was designed, tested and documented during the nice 14-day free trial period of Capgo CapacitorUpdater.

2. Capgo 사용의 이유. semantic-release 사용의 이유

Capgo CapacitorUpdater는 애플리케이션 배포를 훨씬 더 간단하고 빠르게, 유연하게 처리할 수 있는 약속으로 나에게 끌렸습니다. 이전에는 웹 앱에 집중하여 Salesforce Experience Cloud에서 개발했습니다. 이번에는 앱 스토어에 애플리케이션을 푸시하는 첫 번째 모바일 애플리케이션입니다.

배포를 위한 학습 곡선에 대한 두려움을 가지고 있었지만, 애플 테스트 플라이트에 앱을 올리는데 성공했습니다. 그 후에 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 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 !

Capgo CapacitorUpdater는 앱을 업데이트하는 데 도움이 되었으며, 소스 code에서 새로운 기능이나 수정을 저장한 후 1분 만에 앱을 업데이트할 수 있었습니다.

3. Branching 및 Release 모델, 그리고 semantic-release가 어디에 들어갈 것인지

Capgo 서버에 배포를 성공적으로 완료한 후, 배포를 자동화하고 CI/CD pipeline에 통합해야 합니다.

이것은 나의 branch 및 release 모델을 어떻게 구성하는지 보여줍니다.

모바일, 웹 또는 Salesforce를 위한 모든 애플리케이션에 대해 :

개발 는 feature/... branch main에서 수행됩니다. main 그리고 그들은
maintenance 및 특정 기능을 위한 custom 배송에 대한 것 외에 개발 branch의 대부분은 reference로 production배포는alpha, beta, nightlyrelease branch에서 트리거됩니다.
__CAPGO_KEEP_0__는 pull request에 의해 트리거됩니다. __CAPGO_KEEP_0__는 태그에 의해 트리거되는 배포를 사용하지 않습니다. semantic release는 태그와 나머지 모든 것을 관리하기 때문입니다.

__CAPGO_KEEP_0__는 Gitlab Flow의 기본입니다.

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__ - source https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

__CAPGO_KEEP_0__에 대한 한 가지 주의사항 : semantic-release가 작동하는 방식

배포 branch에서 semantic-release가 트리거되면, 이전 태그의 버전 번호와 전달된 수정 사항 또는 기능에 따라 자동으로 새로운 버전 번호를 계산합니다. 수정 사항은 새로운 패치 버전을 생성하고, 기능은 새로운 마이너 버전을 생성합니다. 또한 prerelease alpha, beta, etc.를 버전 번호에 자동으로 포함합니다.

semantic-release는 conventional commits(see https://www.conventionalcommits.org/en/about)를 참조하여 커밋에서 changelog를 생성합니다. 그룹화된 수정 사항과 기능은 semantic release에서 정의된 conventional commits에 따라 그룹화됩니다. __CAPGO_KEEP_0____CAPGO_KEEP_0__는 conventional commits(see https://www.conventionalcommits.org/en/about)를 참조하여 커밋에서 changelog를 생성합니다. 그룹화된 수정 사항과 기능은 semantic release에서 정의된 conventional commits에 따라 그룹화됩니다.

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, etc. CHANGELOG.md4. Branches, releases/prereleases, channels in semantic release and in __CAPGO_KEEP_0__

4. Branches, releases/prereleases, channels in semantic release and in Capgo

So what I want semantic release to do for Capgo deployments is the following.

Capgo는 'Conventional Commits' 도구의 버전을 개발하고 문서화했습니다.

https://Capgo.com/Cap-go/standard-version standard-version https://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-standard-version standard-version (https://github.com/Cap-go/__CAPGO_KEEP_1__-plugin-standard-versionhttps://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-plugin-standard-version capacitor-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionhttps://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-plugin-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 번들을 위한 '표준' semver 'Semantic Versioning' (https://semver.org)이 따릅니다. 이것은 당연히도. semantic-release 이것은 훌륭하고, 나에게는 큰 편안함입니다. 나는 __CAPGO_KEEP_1__를 많이 사용합니다.

또한, semantic release가 다채널에 앱 배포를 생성하도록 하려면. semantic-release 위에서 언급한 것처럼, 나는 prerelease 버전을 branch (

예를 들어, etc.

)에서 배포해야 합니다. 또한, 고객 전용 버전을 branch ( alpha, beta, nightly 예를 들어, etc. 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. 이 버전 번호는 Capgo에 의해 지원되며, 이는 저에게 매우 좋은 소식입니다. 저는 semantic release의 채널과 prerelease를 사용하여 Capgo 채널의 버전을 생성할 것입니다.

5. Capgo을 사용하여 애플리케이션을 릴리즈하는 방법은 무엇입니까?

앱 번들을 Capgo으로 자동으로 배포하려면 Capgo CLI 명령어를 사용해야 합니다. bundle upload타입 npx @capgo/cli@latest bundle upload --help 업로드 옵션을 얻으려면

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. 내 의미론적 릴리스 + Capgo CapacitorUpdate 설정

마지막으로, 이것은 어떻게 모두가 맞물려 있는 것일까요?

Github Actions을 사용하여 의미론적 릴리스와 함께 빌드된 앱 번들 버전

Github Actions을 사용하여 의미론적 릴리스와 함께 빌드된 앱 번들 버전

Github Actions을 사용한 의미론적 릴리스 자동화

의미론적 릴리스의 아름다움은 배포 자동화, 즉 Github 액션 워크플로우의 형태가 매우 간단합니다. 다른 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 환경을 설치하고 의미론적 릴리스를 호출하는 것입니다.

branch에 나열된 모든 머지에 대해, semantic release는 배포를 트리거합니다. 설정 branchesrepository의 비밀에 업데이트 CAPGO_APIKEY 여기. CAPGO_APPID semantic release의 동작은 __CAPGO_KEEP_0__ 액션 워크플로우의 설정에 의해 결정됩니다.

semantic release의 동작은 __CAPGO_KEEP_0__ 액션 워크플로우의 설정에 의해 결정됩니다. .releaserc.json __CAPGO_KEEP_0__ 파일입니다. 아래 설정은 나의 설정입니다.

// .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__ branch (name)의 설정을 지정하고 (Capgo 채널 (channel)과 prerelease 버전 번호가 호출되는 방식)입니다. 예를 들어, prereleasesemantic release가 생성하는 버전 번호는 branch.prerelease = "development"개발자에게 배포하는 x.y.z-development.n
- 개발자에게 배포하는 alpha개발자에게 배포하는 alpha-nocapgo 개발자에게 배포하는 alpha개발자에게 배포하는
- 개발자에게 배포하는 dev-rupert개발자에게 배포하는 dev-paul will both deploy to the developmentCapgo 채널에 모두 배포합니다. development버전 번호의 prerelease 키워드가 동일합니다.
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_1__ __CAPGO_KEEP_2__에 대한 인증 체크를 추가하길 바랍니다.https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
@semantic-release/release-notes-generator https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format CHANGELOG.md
@semantic-release/git : 변경 로그 파일을 생성합니다.package.json, CHANGELOG.md : Ionic 빌드와 의미론적 릴리스 작업으로 업데이트된 파일을 커밋합니다. ios/App/App.xcodeproj/project.pbxproj 그리고
@semantic-release/github - 아직 안드로이드 빌드를 하지 않았습니다. CHANGELOG.md : Github 릴리스에 Github 파일을 첨부합니다.
@semantic-release/exec: 앱 빌드 준비를 위해 이 2 개의 명령어를 사용하세요 (prepareCmd) 그리고 Capgo 서버에 앱 번들을 효과적으로 빌드 및 배포하세요 (publishCmd)

버전 번호를 계산하고 증가시키는 방법에 대한 설명이나 변경 로그를 생성하는 방법, Github 태그 또는 릴리스를 생성하는 방법에 대한 설명은 없습니다. : 모든 것이 semantic release에 의해 기본적으로 처리되며 최소한의 구성으로 처리됩니다.

XCode Cloud에서 새로운 바이너리를 빌드합니다.

XCode Cloud와 통합하여 애플리케이션 바이너리 버전의 새로운 빌드를 간단하게 할 수 있습니다 (Google Play로 배포하지 않았지만, 그 빌드는 유사한 빌드일 것입니다) :

XCode Cloud 프로세스를 설정하여 특정 branch에서 변경이 발생할 때 빌드를 트리거하도록 설정했습니다 (예를 들어, production)
이 branch에서, XCode Cloud는 파일이 업데이트될 때만 빌드를 트리거하도록 설정했습니다. 이 파일은 semantic release가 생성한 각 버전 후에 업데이트됩니다. CHANGELOG.md 다른 branch에서 빌드를 트리거하여 각 채널에 대한 배포를 시뮬레이션할 수 있습니다. 각 XCode Cloud 빌드 구성에서, 나는 __CAPGO_KEEP_0__에 설정된 값을 수동으로 환경 변수로 설정했습니다. (네, 이건 수동 복제입니다) 그리고 만약에 원한다면, 나는 이전에 언급한 것과 같이 각 커스터마이즈드 릴리스 branch에서 커스터마이즈드 고객 애플리케이션에 대한 다른 AppStore 애플리케이션을 배포할 수 있습니다.
XCode Cloud에서 __CAPGO_KEEP_0__ 채널에 앱 바이너리를 빌드합니다. branch.channel releaserc.json

Building app binaries on XCode Cloud with Capgo channels

XCode Cloud에서 Capgo 채널을 사용하여 앱 바이너리를 빌드합니다.

7. 결론

결론적으로, 14일 무료试用 기간 내에 Capgo CapacitorUpdater를 내장된 의미론적 릴리스 PIPELINE에 통합할 수 있었고, 그 결과는 다음과 같습니다.

bundle 버전 번호는 의미론적 릴리스가 자동으로 생성하고 Capgo 서버와 호환됩니다.
semantic release는 Capgo 애플리케이션 번들을 자동으로 배포하며, Capgo 채널도 사용합니다.
이것은 앱 바이너리 XCode Cloud 빌드와 잘 맞습니다.

다음 단계

현재 이 앱의 개발 단계에 있습니다. 테스트를 위해 iOS에서 테스트 플라이트를 통해 빠르게 앱을 제공할 예정입니다. Capgo의 강력함을 고려하여, 무료 버전의 앱을 AppStore에 배포할 예정이며, 테스트 중에는 Capgo로 정기적으로 업데이트할 예정입니다. 그 후에 또 다른 (유료) 버전의 앱을 AppStore에 배포할 예정이며, 다른 레코드에서 배포하고, 테스트 중에는 Capgo로 정기적으로 업데이트할 예정입니다.

Capgo의 더 나은 전처리 검증을 위해 내장된 의미론적 릴리스 구성에 추가할 예정입니다. bundle upload __CAPGO_KEEP_0__을 사용하여 Ionic + Angular로 개발하는 미래의 모바일 앱에 대한 의미론적 릴리스 PIPELINE을 깨끗하고 간단하게 reproducible하게 만들었습니다.

I now have a clean, simple an reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.

Building app binaries on XCode Cloud with __CAPGO_KEEP_0__ channels

22년 이상 Salesforce 경험을 보유하고 있습니다. 고객과 사용자, 파트너 및 통합자, 아키텍트, 개발자, 비즈니스 분석가 및 컨설턴트로 다양한 역할을 수행했습니다. 저는 프랑스의 성공적인 Salesforce SI 파트너인 Altius Services의 공동 설립자이자 COO 및 CTO로 13년 동안 경영했습니다. 새로운 모험을 시작하기 위해 Salesforce 솔로 프레너로서의 경력을 시작했습니다. Rapido Cloud 링크드인에서 저를 찾으실 수 있습니다.

https://linkedin.com/in/rbarrow Rapido Cloud의 Salesforce 제품을 확인하실 수 있습니다..

https://www.rapido-companion.app https://www.rapido.cloud (개발 중) 저는 Rupert Barrow