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와 관련하여 내 설계, 내 선택 및 구현을 설명합니다. 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.

Capgo CapacitorUpdater는 앱 배포를 표준 Apple AppStore/Google PlayStore 배포 프로세스보다 훨씬 더 간단하고 빠르게, 유연하게 만들 수 있는 약속으로 나를 끌어들였습니다. 이것은 나의 첫 번째 모바일 앱입니다. 이전에는 웹 앱에 집중했으며 Salesforce Experience Cloud에서 개발했습니다.

Capgo CapacitorUpdater attracted me with its promise to make mobile app deployments much more simple, much more rapid and flexible than going through the standard Apple AppStore/Google PlayStore delivery process. This is my first mobile application which I am pushing to the stores, having concentrated in the past on web apps, usually developed on the Salesforce Experience Cloud.

I was rather afraid of the learning curve to make this successful but I got my app onto Apple TestFlight quite easily. I was then in position to use Capgo CapacitorUpdater to deploy my updates much faster.

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. My branching and release model, and how semantic-release fits in

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/... branch main에서 main 으로
으로 merge됩니다. 이는 대부분의 개발 branch의 기준이 되며, 유지보수 및 특정 기능을 위한 커스터마이즈된 배포 외에는 다른 branch의 기준이 됩니다. (이하에 대한 자세한 설명이 있습니다.) 배포는 다음과 같이 트리거됩니다. release branch에서 예를 들어 : productionprerelease branch (alpha, beta, nightly등의 branch도 있고, 고객 또는 상황에 맞는 branch도 사용할 수 있습니다.
pull request가 deployment branch로 merge될 때 deployment이 트리거됩니다. tag를 기반으로 하는 deployment을 사용하지 않습니다. semantic release는 tag와 그 외의 모든 것을 관리하기 때문입니다.

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를 자동으로 포함합니다. alpha, beta버전 번호, etc.

Semantic release는 커밋으로부터 변경 로그를 생성하고, conventional commits ( conventionalcommits.org 에서 자세히 설명됨 )에 정의된修정 및 기능을 그룹화합니다. 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.mdsemantic release가 __CAPGO_KEEP_0__ 배포에 대해 수행해야 하는 작업은 다음과 같습니다.

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

Capgo는 conventional commits의 버전을 개발하고 문서화했습니다.

https://__CAPGO_KEEP_0__.com/Cap-go/standard-version

Capgo standard-version __CAPGO_KEEP_1__ 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에서 semantic release를 사용하여 다양한 채널에서 앱 배포를 자동으로 생성하고 싶습니다.

위에 설명한 것처럼, prerelease 버전을 branch에서 배포해야 합니다. alpha, beta, nightly etc., but also customer-specific versions on branches such as production-customer-jones, production-customer-doe, etc.

Capgo은 "채널" 기능을 제공하는데, 이 기능은 의미적 릴리스도 지원하는 기능과 정확히 동일하기 때문에 이 두 기능을 함께 사용할 수 있는 방법을 찾는 것이 흥미롭습니다. 이 기능은 또한 XCode Cloud가 관리하는 다양한 branch 빌드와도 잘 맞습니다. (다음에 더 자세히 설명합니다.)

__CAPGO_KEEP_0__ prereleases의 semantic release에 의해 생성된 Semver 버전 번호는 다음 형식으로 보입니다: __CAPGO_KEEP_1__ 1.0.0-alpha.1. 이 branch에 대한 연속적인 빌드는 빌드 번호를 증가시켜서 1.0.0-alpha.2, etc. Although not explicitly documented, 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.

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. semantic release + Capgo CapacitorUpdate 설정

마지막으로, 이것이 어떻게 모두 연결되는지 알려드릴게요

Github Actions으로 빌드한 앱 버전

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의 모든 머지에 대해 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-nocapgo branch는 모두 __CAPGO_KEEP_0__에 앱을 배포하지만, 버전 번호의 prerelease 이름이 다릅니다. alpha개발자 branch에 대한 배포
- 또는 dev-rupert모두 __CAPGO_KEEP_0__에 배포됩니다. 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 : 변경 로그 파일을 생성합니다.https://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 : 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__ 태그 또는 릴리즈를 생성하는 방법 등에 대한 설명은 없습니다. : semantic release가 기본적으로 모든 것을 처리하며 최소한의 설정만 필요합니다.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에 대한 빌드를 자동화합니다. 이 빌드는 __CAPGO_KEEP_0__ 파일이 업데이트된 후에 수행됩니다. 이 파일은 semantic release가 생성한 각 버전 후에 업데이트됩니다.

: __CAPGO_KEEP_0__에 포함된 파일을 __CAPGO_KEEP_0__ 릴리즈에 첨부하세요 production)
: 앱 빌드를 준비하기 위해 이 2개의 명령어를 사용하세요 ( CHANGELOG.md ) 그리고 앱 번들을 __CAPGO_KEEP_0__ 서버에 배포하세요 (
다양한 branch에서 빌드를 트리거하여 다양한 채널에 대한 배포를 시뮬레이션할 수 있습니다. XCode Cloud에서 빌드하는 각 구성에서, 나는 __CAPGO_KEEP_0__의 값을 가진 환경 변수를 수동으로 설정하고, 그 후에, 만약 내가 원한다면, __CAPGO_KEEP_0__ 채널에 대한 다른 AppStore 앱을 각 사용자 지정 고객 앱에 대한 사용자 지정 릴리즈 branch에서 배포할 수 있습니다. branch.channel __CAPGO_KEEP_0__ 채널에서 XCode Cloud에서 앱 바이너리를 빌드하는 경우 releaserc.json __CAPGO_KEEP_0__ 채널에서 XCode Cloud에서 앱 바이너리를 빌드하는 경우

Building app binaries on XCode Cloud with Capgo channels

Capgo CapacitorUpdater를 내 표준 semantic release pipeline에 통합할 수 있었던 것에 대해 매우 만족합니다. 14일 무료试用 기간 내에 빠르게 통합할 수 있었고, 그 결과는 다음과 같습니다.

semantic release가 자동으로 __CAPGO_KEEP_0__ 서버와 호환되는 버전 번호를 생성합니다.

semantic release가 Capgo 앱 배포를 자동으로 배포하며, __CAPGO_KEEP_1__ 채널도 사용합니다.

bundle version numbers are generated automatically by semantic release and compatible with the Capgo servers
semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
현재 이 앱의 개발 단계에 있습니다. iOS용으로 테스트러너(TestFlight)에서 빠르게 배포할 예정입니다. __CAPGO_KEEP_0__의 강력함을 고려하여, 테스트를 위해 무료 버전의 앱을 AppStore에 배포할 예정이며, 테스트 중에는 __CAPGO_KEEP_1__로 정기적으로 업데이트할 예정입니다. 그 후에, 또 다른(유료) 버전의 앱을 AppStore에 배포할 예정이며, __CAPGO_KEEP_2__로 정기적으로 업데이트할 예정입니다.

__CAPGO_KEEP_1__ 채널을 사용하여 테스트 중인 경우

I am currently in the development phase of this app. I will quickly make it available to testers through TestFlight (for iOS). Considering the power of Capgo, I will most certainly deploy a free version of the app to the AppStore for tests, which will be updated regularly with Capgo during tests. I will then deploy another (paid) version of the app on the AppStore, under another record, and also update that regularly with Capgo.

Capgo을 더 나은 빌드 전 검증으로 추가하는 것을 기대합니다. bundle upload __CAPGO_KEEP_0__의 사전 조건을 내 semantic release 구성에 추가하는 것을 기대합니다.

Ionic + Angular + Capacitor로 개발된 미래의 모바일 앱에 대해 내게 있는 깨끗하고 간단한, 재현 가능한 semantic release pipeline을 가지고 있습니다.

작가 - Rupert Barrow

Salesforce에 대한 22년 이상의 경험을 보유하고 있습니다. 고객과 사용자, 파트너 및 통합자, 아키텍트, 개발자, 비즈니스 분석가 및 컨설턴트로 Salesforce를 사용했습니다. Altius Services의 공동 설립자이자 13년 동안 COO 및 CTO로 관리했습니다. 프랑스에서 성공적인 Salesforce SI 파트너로 Altius Services를 운영한 후, 새로운 모험을 시작하여 Salesforce 솔로 프레너로서 Rapido Cloud의 제품을 제공하는 솔로 프레너로 활동했습니다. 링크드인에서 나를 찾으세요. https://linkedin.com/in/rbarrow

Rapido Cloud의 Salesforce 제품을 확인하세요. https://www.rapido-companion.app.

and __CAPGO_KEEP_0__을 더 나은 빌드 전 검증으로 추가하는 것을 기대합니다. __CAPGO_KEEP_0__의 사전 조건을 내 semantic release 구성에 추가하는 것을 기대합니다. https://www.rapido.cloud (개발 중입니다).

How Rapido Cloud는 Capgo CapacitorUpdater를 사용하여 Capgo Semantic Release를 관리합니다.

Capacitor를 사용 중이라면 How Rapido Cloud는 Capgo CapacitorUpdater를 사용하여 Capgo Semantic Release를 관리합니다. live update 전송을 계획하는 데 사용하는 경우 __CAPGO_KEEP_0__ Live Updates와 연결하세요. Capgo Live Updates의 제품 워크플로우에서 Capgo Live Updates의 구현 세부 정보에서 __CAPGO_KEEP_0__ Overview __CAPGO_KEEP_0__ Features의 구현 세부 정보에서 __CAPGO_KEEP_0__ Features __CAPGO_KEEP_0__ Overview 업데이트 동작 업데이트 동작의 구현 세부 사항에 대해, 그리고 업데이트 유형 업데이트 유형의 구현 세부 사항에 대해

Rapido Cloud에서 Capgo CapacitorUpdater를 사용한 Semantic Release 관리 방법