Rapido Cloud가 Capgo CapacitorUpdater와 semantic release를 어떻게 관리하는가

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_KEEP_1__ CapacitorUpdater를 사용하는 내 설계, 선택 및 구현에 대해 설명합니다. semantic-release 자동화된 모든 배포를 관리하는 쉬운 방법으로 Github Actions를 사용했습니다. 모든 것이 Capgo CapacitorUpdater의 14일 무료试用 기간 동안 설계, 테스트 및 문서화되었습니다.

2. Capgo을 사용하는 이유는 무엇입니까? semantic-release를 사용하는 이유는 무엇입니까?

Capgo CapacitorUpdater는 앱 배포를 더 간단하고 빠르게, 유연하게 할 수 있는 약속으로 나를 매료했습니다. 앱 스토어(Apple AppStore, Google PlayStore)에서 배포하는 표준 프로세스보다.

앱을 스토어에 푸시하는 것은 처음이었습니다. 이전에는 웹 앱을 개발했으며 Salesforce Experience Cloud에서 개발했습니다. 배포를 자동화하는 Capgo CapacitorUpdater가 나를 매료했습니다.

배포를 자동화하는 Capacitor CapacitorUpdater를 사용하여 업데이트를 더 빠르게 배포할 수 있었습니다. 배포를 자동화하는 Capacitor CapacitorUpdater를 사용하여 업데이트를 더 빠르게 배포할 수 있었습니다.

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 및 release 모델, 그리고 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 :

개발 은/는 feature/... 에서 수행되며 mainbranch가 분기 main , 그리고
은/는 으로 merge된다. 이는 대부분의 개발 branch의 기준이 되며, 유지보수 및 특정 기능을 위한 커스터마이즈된 배포 외에는 다른 branch와 다르다 (이것에 대한 자세한 내용은 아래 참조). 어떤 경우에는 : production, 특정 릴리즈 branch (alpha, beta, nightly, etc.) 및 고객 또는 컨텍스트에 맞는 branch도 사용할 수 있습니다.
배포는 pull request가 deployment branch에 merge될 때 트리거됩니다. 태그 트리거 배포를 사용하지 않습니다. semantic release가 태그 및 기타 모든 것을 관리하기 때문입니다. Gitlab Flow의 기본적인 개념입니다.

Gitlab Flow

Gitlab Flow - source

https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022 semantic-release에 대한 한 가지 주의사항입니다.

deployment branch에서 semantic-release가 트리거될 때, 이전 태그의 버전 번호와 제공된 수정 사항 또는 기능에 따라 자동으로 새로운 버전 번호를 계산합니다. 수정 사항은 새로운 패치 버전을 생성하며, 기능은 새로운 마이너 버전을 생성합니다. 또한 prerelease

, etc.도 버전 번호에 자동으로 포함됩니다. alpha, betahttps://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

Semantic release는 커밋에서 변경 로그를 생성하고, conventional 커밋 (see https://www.conventionalcommits.org/en/about )과 semantic release에서 정의된.fixes 및 기능을 그룹화합니다. It will also update all your git (__CAPGO_KEEP_0__, in my case) merged pull requests and related issues with comments linking them to the tag and release. Finally, in this __CAPGO_KEEP_1__ release, it will attach assets such as source __CAPGO_KEEP_2__, binaries if necessary, etc.4. semantic release와 __CAPGO_KEEP_0__에서 branch, release/prerelease, channel

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.mdI want semantic release to generate the version number

Capgo have developed and documented their own version of the “Conventional Commits” tool, with their forked repo https://Capgo.com/Cap-go/standard-version )

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

__CAPGO_KEEP_0__

Capgo have developed and documented their own version of the “Conventional Commits” standard-version __CAPGO_KEEP_2__ standard-version (github__CAPGO_KEEP_0__ 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_0__를 매우 많이 사용합니다.

또한, semantic release는 다양한 채널에서 앱 배포를 생성하도록 설정하고 싶습니다.

As mentioned above, I need to deploy prerelease version from branches such as alpha, beta, nightly 그리고 고객 전용 버전을 위한 branch 들도 있죠. production-customer-jones, production-customer-doe, etc.

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 CHANNEL은 __CAPGO_KEEP_0__에 배포할 채널을 지정하는 옵션입니다. (예를 들어

npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID

Capgo alpha)
버전은 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으로 빌드된 앱 버전

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를 호출하는 것입니다.

브랜치 목록에 있는 모든 머지에 대해, semantic release는 배포를 트리거합니다. 설정 branches__CAPGO_KEEP_0__는 protectedTokens에 포함되어 있으므로 그대로 유지됩니다. CAPGO_APIKEY repository의 비밀을 업데이트하세요. CAPGO_APPID 여기.

semantic release의 동작은 configuration 파일에서 설정됩니다. .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 branch의 설정 (name)을 Capgo 채널 (channel)에 매핑하고 prerelease 버전 번호를 어떻게 불러올 것인지 설정합니다. 예를 들어, prerelease)이면 semantic release가 생성하는 버전 번호는 branch.prerelease = "development"입니다. x.y.z-development.n
- Cloudflare로의 alphaCapacitor로의 alpha-nocapgo branch는 모두 앱을 Cloudflare로 배포합니다. alpha채널, 버전 번호에 다른 prerelease 이름을 가지는
- 개발자 branch로의 배포 dev-rupert또는 dev-paul 모두 __CAPGO_KEEP_0__ 채널에 배포될 것입니다. developmentchannel on Capgo, all with the same development: semantic release의 첫 번째 단계에서, __CAPGO_KEEP_0__에 대한 올바른 접근 권한이 있는지 확인합니다. __CAPGO_KEEP_1__ __CAPGO_KEEP_2__에 대한 인증 체크를 추가할 예정입니다.
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 https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formathttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
@semantic-release/release-notes-generator : Ionic 빌드와 semantic release 작업에 의해 업데이트된 파일을 커밋합니다. CHANGELOG.md
@semantic-release/git 그리고package.json, CHANGELOG.md and ios/App/App.xcodeproj/project.pbxproj - 안드로이드를 위한 빌드를 하지 않습니다.
@semantic-release/github : __CAPGO_KEEP_0__ 릴리즈에 포함될 __CAPGO_KEEP_0__ 자산으로 파일을 첨부하세요 CHANGELOG.md file to the Github release as an asset
@semantic-release/exec) 그리고 __CAPGO_KEEP_0__ 서버에 앱 번들을 효과적으로 빌드 배포하세요 (prepareCmd앱 버전 번호를 계산하고 증가시키는 방법에 대한 설명이나 변경 로그를 생성하는 방법, 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와 통합하여 새로운 애플리케이션 바이너리의 버전을 빌드하는 것은 간단합니다 (안드로이드에 배포하지 않지만, 그 빌드는 유사합니다) :

XCode Cloud 프로세스를 설정하여 __CAPGO_KEEP_0__ branch에서 변경이 발생할 때 빌드를 트리거합니다 (예를 들어, 이 branch에서 __CAPGO_KEEP_0__ file이 업데이트되면 XCode Cloud는 빌드를 트리거합니다. 이 파일은 semantic release가 생성한 각 버전 후에 업데이트됩니다.

다른 채널에 대한 배포를 시뮬레이션하기 위해 다른 branch에서 빌드를 트리거할 수 있습니다. 각 XCode Cloud 빌드 구성에서, __CAPGO_KEEP_0__ branch의 다른 환경 변수를 수동으로 설정하여 __CAPGO_KEEP_0__ channel의 값을 할당합니다. production)
__CAPGO_KEEP_0__ channel의 값을 할당합니다. CHANGELOG.md __CAPGO_KEEP_0__ channel의 값을 할당합니다.
__CAPGO_KEEP_0__ channel의 값을 할당합니다. branch.channel 설정 releaserc.json (예, 이는 수동 복제입니다) 그리고 만약에 내가 원한다면, 나는 이전에 언급된 것과 같이 각 사용자 지정 고객 응용 프로그램을 사용하여 사용자 지정 릴리스 branch에서 배포한 각 사용자 지정 고객 응용 프로그램에 대해 다른 AppStore 응용 프로그램을 배포할 수 있습니다.

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

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

7. 결론

결론을 내리자, 나는 Capgo CapacitorUpdater를 내장된 의미론적 릴리스 pipeline에 통합할 수 있었던 것에 대해 매우 행복합니다. 또한 14일 무료 시험 기간 내에 빠르게 통합할 수 있었으며, 결과는 다음과 같습니다.

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

다음 단계

현재 이 앱의 개발 단계에 있습니다. 테스터에게 빠르게 TestFlight (iOS)에서 앱을 제공할 것입니다. Capgo의 힘을 고려할 때, 테스트를 위해 AppStore에 무료 버전의 앱을 배포할 것입니다. 테스트 중에는 Capgo으로 정기적으로 업데이트할 것입니다. 그 다음에, 테스트를 위해 AppStore에 또 다른 (유료) 버전의 앱을 배포할 것입니다. 또 다른 레코드 아래에 배포하고, 테스트 중에는 Capgo로 정기적으로 업데이트할 것입니다.

테스트를 위해 AppStore에 무료 버전의 앱을 배포하고, 테스트 중에는 __CAPGO_KEEP_1__으로 정기적으로 업데이트할 것입니다. 그 다음에, 테스트를 위해 AppStore에 또 다른 (유료) 버전의 앱을 배포할 것입니다. 또 다른 레코드 아래에 배포하고, 테스트 중에는 __CAPGO_KEEP_2__로 정기적으로 업데이트할 것입니다. 또한 Capgo에 대한 더 나은 빌드 전 검증을 추가하려고 합니다. bundle upload prerequisites를 내 semantic release 구성으로 넣어보세요.

Ionic + Angular + Capacitor로 개발된 미래의 모바일 앱에 대한 간단하고 reproducible한 semantic release pipeline을 갖추게되었습니다.

작성자 - Rupert Barrow

22년 이상의 Salesforce 경험을 보유하고 있습니다. 클라이언트와 사용자, 파트너 및 통합자, 아키텍트, 개발자, 비즈니스 분석가 및 컨설턴트로 Salesforce를 사용했습니다. Altius Services의 COO 및 CTO로 13년 동안 프랑스에서 성공적인 Salesforce SI 파트너를 공동 설립하고 관리했습니다. 그리고 나서 새로운 모험으로 Salesforce 솔로 프레너로서 나의 Rapido Cloud 제품 제공.

링크드인에서 나를 찾으세요. https://linkedin.com/in/rbarrow.

나의 Salesforce 제공을 확인하세요. https://www.rapido-companion.app 그리고 https://www.rapido.cloud (개발 중입니다).

How Rapido Cloud Capgo CapacitorUpdater를 사용하여 Semantic Release를 관리하는 방법

CapacitorUpdater를 사용하는 경우 How Rapido Cloud Capgo CapacitorUpdater를 사용하여 Semantic Release를 관리하는 방법 __CAPGO_KEEP_0__ Live Updates와 연결하여 Capgo Live Updates의 제품 워크플로우에서 for the product workflow in Capgo Live Updates, __CAPGO_KEEP_0__ Live Updates의 구현 세부 정보 기능 __CAPGO_KEEP_0__ Live Updates의 구현 세부 정보 업데이트 동작 __CAPGO_KEEP_0__ Live Updates 구현 세부 정보에 대한 Update Behavior, 그리고 Update Types 구현 세부 정보에 대한 Update Types, 그리고

How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater