라피도 클라우드가 Capgo CapacitorUpdater를 사용하여 세마틱 릴리즈를 관리하는 방법

1. 소개

Rapido Cloud (www.rapido.cloudSalesforce 고객을 위한 모바일 애플리케이션을 개발하고 있습니다. Salesforce Mobile SDK 또는 Salesforce Mobile Publisher를 사용하지 않고 쉽게 브랜드화된 모바일 애플리케이션을 배포할 수 있도록 합니다.

I have developed this mobile app on a modern and “standard” platform with widespread components and tools including Ionic 8, Angular 18, TypeScript, Capacitor and now Capgo CapacitorUpdater. These are more simple to handle for clients who do not want to manage Salesforce platform specifics such as Lightning Web Components; and its easier and cheaper for me to recruit developers and maintainers of Ionic + Angular mobile applications.

이 기사에서는 Capgo 및 CapacitorUpdater를 사용하여 자동으로 모든 배포를 관리하는 Capgo Actions의 설계, 선택 및 구현에 대해 설명합니다. 이 모든 것이 __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.

Capgo CapacitorUpdater는 Apple AppStore/Google PlayStore 배포 프로세스보다 배포를 더 간단하고 빠르게 할 수 있는 약속으로 저를 매료했습니다. 이是我 첫 번째 모바일 애플리케이션으로, 이전에는 웹 앱을 개발했으며 Salesforce Experience Cloud를 사용했습니다.

Capgo

I는 애플 테스트 플라이트에 앱을 성공적으로 배포하기 위한 학습 곡선을 두려워했지만, 쉽게 앱을 배포할 수 있었다. 나중에, 나는 Capgo CapacitorUpdater를 사용하여 업데이트를 배포할 수 existed.

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. 나의 branch와 release 모델, 그리고 semantic-release가 어디에 들어가는지

이제 나의 배포가 Capgo 서버에 정상적으로 작동하고 있으므로, CI/CD pipeline에 자동화하고 배포 모델에 통합해야 한다.

이것은 나의 branch와 release 모델을 어떻게 구성하는지 설명한다.

모든 애플리케이션(모바일, 웹, Salesforce 포함)에서:

개발은 branch에서 feature/... 다음으로 main그리고 그들은 main reference로 가장 많은 개발 branch에 merge된다. 유지보수 및 특정 기능을 위한 커스터마이즈된 배포 외에.
배포는 릴리스 branch에서 트리거됩니다. 릴리스 branch에서 트리거되는 배포는 릴리스 branch, prerelease branch, etc. 및 고객 또는 컨텍스트에 맞는 branch를 사용하여 커스터마이즈된 배포를 수행할 수 있습니다. production릴리스 branch에 대한 pull request가 병합될 때 배포가 트리거됩니다.alpha, beta, nightly릴리스 태그에 의한 배포를 사용하지 않습니다. semantic-release는 태그 관리 및 기타 모든 것을 관리하기 때문입니다.
이것은 Gitlab Flow의 기본적인 개념입니다. Gitlab Flow

Gitlab Flow - source

semantic-release의 동작에 대한 간단한 설명입니다. CapacitorUpdater

CapacitorUpdater

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

semantic-release는 conventional commits(see https://www.conventionalcommits.org/en/about)에서 정의된 수정 사항과 기능을 그룹화하여 커밋 로그를 생성합니다. semantic release에서 구성된 conventional commits. semantic-release는 또한 git (__CAPGO_KEEP_0__, 나의 경우) 병합된 pull 요청과 관련된 이슈에 태그와 릴리즈에 대한 링크를 포함하는 댓글을 업데이트합니다. 마지막으로 이 __CAPGO_KEEP_1__ 릴리즈에서 소스 __CAPGO_KEEP_2__, 바이너리 등이 포함된 asset를 첨부합니다.4. semantic release와 __CAPGO_KEEP_0__에서 브랜치, 릴리즈/프리릴리즈, 채널

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.md__CAPGO_KEEP_0__에서 버전 번호를 생성하길 원합니다.

Capgo는 Conventional Commits라는 도구의 버전을 개발하고 문서화했습니다. 그들은 fork된 repo를 사용합니다.

Capgo

__CAPGO_KEEP_1__

Capgo have developed and documented their own version of the “Conventional Commits” 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 그것도 따라한다 (물론이다 !)

그것이 좋고, 나에게는 큰 편리함이다. 왜냐하면 나는 __CAPGO_KEEP_1__을 사용하기 때문이다. semantic-release 엄청나게.

또한 semantic release가 다채널에 앱 배포를 생성하도록 하려면.

위에서 설명한 것처럼, prerelease 버전을 branch 등에서 배포해야 하며, alpha, beta, nightly 등의 branch에서 customer-specific 버전을 배포해야 합니다. production-customer-jones, production-customer-doe, 등.

Capgo은 '채널' 기능을 제공하는데, 이 기능은 semantic release도 지원하므로, 이 두 가지를 함께 사용하는 것은 정말 좋습니다. 이 기능은 XCode Cloud가 관리하는 다채널 빌드와도 잘 맞습니다. (다음에 더 자세히 설명하겠습니다.).

semantic release가 prerelease에서 생성한 Semver 버전 번호는 다음과 같습니다. 1.0.0-alpha.1이 branch에서 연속적으로 빌드가 진행되면, 빌드 번호가 증가합니다. 1.0.0-alpha.2, 등. 이 버전 번호는 Capgo에서 지원되므로, 이점은 좋습니다. : semantic release의 채널과 prerelease를 사용하여 Capgo 채널을 사용하여 앱의 버전을 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. semantic release + Capgo CapacitorUpdate 설정

마지막으로, 이것은 어떻게 모두 연결되는 것일까요?

Github Actions을 사용한 semantic release 자동화

Github Actions을 사용한 semantic release 자동화

Semantic release automation with Github Actions

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를 호출합니다.

For every branch on a listed in branches, semantic release will trigger a deployment. CAPGO_APIKEY Set in your repository’s secrets. CAPGO_APPID Update your here.

The behavior of semantic release is set in its configuration file. .releaserc.json Here are my settings, explained below :

// .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 sets the configuration of branches (name), mapped to the Capgo channel (channel) and how the prerelease version number will be called (prerelease). For example, if branch.prerelease = "development", the version number generated by semantic release will be x.y.z-development.n
- deployments to the alpha그리고 alpha-nocapgo branch는 모두 __CAPGO_KEEP_0__에 앱을 배포하지만, 버전 번호의 prerelease 이름이 다릅니다. alpha개발자 branch에 배포
- 또는 dev-rupert__CAPGO_KEEP_0__에 배포 dev-paul __CAPGO_KEEP_0__에 배포 developmentCapgo에 배포 development__CAPGO_KEEP_0__에 배포
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__에 배포github에 배포)
@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 : 이 애플리케이션의 Ionic 빌드와 semantic release 작업에 의해 업데이트된 파일을 __CAPGO_KEEP_0__package.json, CHANGELOG.md 그리고 ios/App/App.xcodeproj/project.pbxproj - 안드로이드 빌드에는 아직 준비되지 않았습니다.
@semantic-release/github : __CAPGO_KEEP_0__ CHANGELOG.md : 이 2 개의 명령어를 사용하여 앱 빌드를 준비하고 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로 새로운 애플리케이션 바이너리의 버전을 빌드하는 것은 간단합니다. (Google Play에 배포하는 것은 아직 안되지만, 그 빌드는 비슷할 것입니다.) :

XCode Cloud 프로세스를 설정하여 __CAPGO_KEEP_0__

이 branch에서 XCode Cloud를 빌드하도록 설정했습니다. production)
이 branch에서 XCode Cloud를 빌드하도록 설정했습니다. CHANGELOG.md 파일이 업데이트되었습니다. 이 버전은 semantic release가 생성한 각 버전마다 업데이트됩니다.
다른 branch에서 빌드를 트리거하여 각 채널에 대한 배포를 시뮬레이션할 수 있습니다. XCode Cloud 빌드의 각 구성에서 branch마다 환경 변수를 수동으로 설정하여 __CAPGO_KEEP_0__의 값을 설정하고, 만약에 원하는 경우, 이전에 언급된 것과 같이 custom release branch에서 custom customer application을 배포할 수 있는 다른 AppStore application을 배포할 수 있습니다. branch.channel __CAPGO_KEEP_0__ 채널을 사용하여 XCode Cloud에서 앱 바이너리를 빌드합니다. releaserc.json __CAPGO_KEEP_0__ 채널을 사용하여 XCode Cloud에서 앱 바이너리를 빌드합니다.

Building app binaries on XCode Cloud with Capgo channels

결론을 내리자면, 14일 무료试用 기간 내에 Capgo Builder의 Capgo CapacitorUpdater를 내장된 semantic release pipeline에 통합할 수 있었고, 결과는 다음과 같습니다.

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
다음 단계

nextSteps

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

테스트 중에 Capgo의 더 나은 전제 조건을 미리 빌드한 후에 검증할 수 있도록 Capgo에 더 나은 전제 조건을 추가하는 것을 기대합니다. 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.

Salesforce에 대한 22년 이상의 경험을 가지고 있습니다. Salesforce의 고객이자 사용자, 파트너이자 통합자, 아키텍트, 개발자, 비즈니스 분석가, 컨설턴트로 13년 동안 Altius Services를 공동 설립하고 공동 관리했습니다. 프랑스에서 성공적인 Salesforce SI 파트너로 13년 동안 COO와 CTO로 일한 후, 새로운 모험을 시작하여 Salesforce 솔로 프레너로서 Rapido Cloud의 제품을 제공하기 시작했습니다.

링크드인에서 나를 찾으실 수 있습니다. https://linkedin.com/in/rbarrow Salesforce의 제품을 확인하시려면 https://www.rapido-companion.app를 방문해 주세요.

https://www.rapido-companion.app https://linkedin.com/in/rbarrow.

Rapido Cloud Rupert Barrow 그리고 https://www.rapido.cloud (개발 중입니다).

Rapido Cloud에서 Capgo CapacitorUpdater를 사용하여 의미 있는 릴리즈 관리하는 방법

Rapido Cloud에서 __CAPGO_KEEP_0__ CapacitorUpdater를 사용하여 의미 있는 릴리즈 관리하는 방법 라이브 업데이트 전송을 계획하는 데 사용하는 경우 Capgo CapacitorUpdater를 Capgo Live Updates와 연결하세요. __CAPGO_KEEP_0__ Live Updates Capgo Live Updates Capgo Live Updates 제품 워크플로우 개요 개요 Capgo의 Capacitor Updater를 사용하여 의미있는 릴리스 관리하는 방법 업데이트 동작 업데이트 동작의 구현 세부 사항, 그리고 업데이트 유형 기사 기여자

Capgo를 사용하는 애플리케이션의 릴리스를 관리하는 방법: Rapido Cloud의 Capgo CapacitorUpdater