How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

1. Introducción

En Rapido Cloud (www.rapido.cloud), I am developing a mobile application for Salesforce clients to easily deploy their own branded mobile application without having to go through the difficult loops of using the Salesforce Mobile SDK or the 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.

This article explains my design, my choices and implementation which make Capgo and 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. Why use Capgo ? Why use semantic-release ?

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 tenía miedo de la curva de aprendizaje para hacer esto exitoso, pero pude poner mi aplicación en Apple TestFlight con facilidad. Luego estaba en posición de usar Capgo CapacitorUpdater para desplegar mis actualizaciones mucho más rápido.

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 !

Entonces Capgo CapacitorUpdater me ayudó a actualizar mi aplicación en mi móvil, en vivo, 1 minuto después de guardar una nueva característica o corrección en mi fuente code : tan aliviado, y tan flexible, y fácil de configurar !

3. Mi modelo de ramas y liberación, y cómo semantic-release se ajusta a él

Entonces ahora tengo mi entrega a Capgo servidores funcionando correctamente, necesito automatizar esto y ajustarlo a mi pipeline de CI/CD.

Esto es cómo organizo mi modelo de ramas y liberación

Para cada aplicación, ya sea móvil, web o Salesforce :

• se lleva a cabo en se desprenden feature/... , y se fusionan en mainque es la referencia para la mayoría de las ramas de desarrollo, fuera de la mantenimiento y características específicas para entregas personalizadas (más sobre esto a continuación) main desarrollo
• los despliegues se disparan desde ramas de liberación que pueden ser : production, ramas de liberación previas (alpha, beta, nightly, etc.) y también ramas específicas del cliente o del contexto para entregas personalizadas
• los despliegues se disparan por una solicitud de extracción que se está fusionando en una rama de despliegue. No uso despliegues disparados por etiquetas porque semantic release gestiona las etiquetas y todo lo demás para mí.

En resumen, esto es el flujo de Gitlab :

Flujo de Gitlab - fuente https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

Un apunte sobre cómo funciona semantic-release :

In una rama de despliegue, cuando se dispara semantic-release, calculará automáticamente el nuevo número de versión en esta rama, dependiendo del número de versión del etiqueta anterior en la rama y los arreglos o características entregados. Los arreglos crearán una nueva versión de parche, mientras que las características crearán una nueva versión menor. También incluye automáticamente la versión de prerelease alpha, beta, etc. en el número de versión.

Semantic release genera el changelog a partir de tus commits, agrupando arreglos y características según se definen en commits convencionales (ver https://www.conventionalcommits.org/en/about) y configurados en semantic release.

Actualiza automáticamente todos tus pull requests de git (en mi caso, Github) fusionados y los problemas relacionados con comentarios que enlacen a la etiqueta y la versión. Finalmente, en esta Github versión, adjuntará activos como código fuente code, binarios si es necesario CHANGELOG.md, etc.

4. Ramas, lanzamientos/prereleases, canales en semantic release y en Capgo

Entonces, lo que quiero que semantic release haga para los despliegues de Capgo es lo siguiente.

Quiero que semantic release genere el número de versión

Capgo han desarrollado y documentado su propia versión de la "Conventional Commits" standard-version __CAPGO_KEEP_1__ es la versión de la cual se está hablando en este artículo standard-version (https://github.com/Cap-go/standard-version), y sus propias capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) además de capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repositorios. Han documentado en su blog el esquema de versión utilizado por Capgo en sus despliegues (https://capgo.app/blog/how-version-work-in-capgo/). Los paquetes de JavaScript siguen el 'estándar' semver 'Semantic Versioning' (https://semver.org) que semantic-release también sigue (obviamente !)

Entonces eso es genial, y es un alivio para mí porque uso semantic-release extensivamente.

También quiero que semantic release genere despliegues de aplicaciones en diferentes canales.

Como se mencionó anteriormente, necesito desplegar versiones de prerelease desde ramas como alpha, beta, nightly etc., pero también versiones específicas de clientes en ramas como production-customer-jones, production-customer-doe, etc.

Capgo proporciona la característica de "canales" que es exactamente lo que también admite semantic release, por lo que estoy emocionado de hacer que funcionen juntos. Estos también se ajustan a las diferentes compilaciones de rama gestionadas por XCode Cloud (consulte más sobre esto a continuación).

Los números de versión Semver generados por semantic release en prereleases tienen el formato 1.0.0-alpha.1Éxito. Los compilados consecutivos en esta rama incrementarán el número de compilado a 1.0.0-alpha.2, etc. Aunque no se documenta explícitamente, estos números de versión son compatibles con Capgo, lo cual es una excelente noticia para mí: utilizaré los canales y prerelease de semantic release para generar versiones de mi aplicación con Capgo canales.

5. ¿Cómo puedo utilizar Capgo para lanzar mi aplicación?

Para automatizar el despliegue de los paquetes de tu aplicación a Capgo, debes utilizar el comando Capgo CLI bundle upload. Presiona npx @capgo/cli@latest bundle upload --help para obtener las numerosas opciones de carga.

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

• El canal es el Capgo canal al que deseamos desplegar (por ejemplo alpha)
• La versión es generada por semantic release (por ejemplo 1.0.0-alpha.1)
• CAPGO_APIKEY se proporciona por Capgo para identificar de manera única tu pipeline de CI/CD de inicio de sesión
• CAPGO_APPID se proporciona por Capgo para identificar de manera única tu aplicación (por ejemplo com.mystartup.mysuperapp)

6. Mi configuración de semantic release + Capgo CapacitorUpdate

Finalmente, ¿cómo se ajusta todo esto?

Las versiones de paquetes de la aplicación construidas con semantic release y Github Actions

Automatización de semantic release con Github Actions

La belleza de semantic release es que la automatización de despliegue, en forma de un flujo de trabajo de Github Actions, es muy simple. Esto se verá muy similar en otras plataformas de 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 }}

Solo instala el entorno de NodeJS, luego llama a semantic release.

For cada merge en una rama lista en branches, semantic release desencadenará un despliegue. Establezca CAPGO_APIKEY en los secretos de su repositorio. Actualice su CAPGO_APPID aquí.

La configuración de semantic release se establece en su archivo de configuración. Aquí están mis ajustes, explicados a continuación: .releaserc.json configura la configuración de las ramas (

// .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 ), vinculadas al canal __CAPGO_KEEP_0__ (name), mapped to the Capgo channel (channel). Por ejemplo, siprerelease, el número de versión generado por semantic release será branch.prerelease = "development"despliegues al x.y.z-development.n
  • channel alphay alpha-nocapgo seguirán ambos desplegar la aplicación en el alphacanal, pero con nombres de versión de prerelease diferentes
  • o dev-rupert¿o dev-paul seguirán ambos desplegando a developmenten el canal en Capgo, todos con la misma developmentpalabra de prerelease en el número de versión
• verifyConditions : en la primera etapa de la liberación semántica, verifica que tiene acceso correcto a Github. Espero poder agregar una verificación de autenticación para el Capgo CLI aquí más adelante
• @semantic-release/commit-analyzer : cosas estándar de la liberación semántica - consulte su documentación (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator : genere el archivo de cambios como CHANGELOG.md
• @semantic-release/git : commit los siguientes archivos que han sido actualizados por la compilación de Ionic de la aplicación y por el trabajo de liberación semántica (package.json, CHANGELOG.md y ios/App/App.xcodeproj/project.pbxproj - No construyo para Android, todavía)
• @semantic-release/github : adjunta el CHANGELOG.md file to the Github release as an asset
• @semantic-release/exec__CAPGO_KEEP_0__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.

) y luego para construir y desplegar efectivamente el paquete de la aplicación en los

__CAPGO_KEEP_0__

• servidores ( production)
• Observará que no hay fregaduras explicando cómo queremos que se calcule y se incremente el número de versión, cómo debemos generar un changelog, un etiqueta o liberación de __CAPGO_KEEP_0__, etc. : todo está manejado por defecto por la liberación semántica, con una configuración mínima. CHANGELOG.md El archivo se actualiza. Esto se actualiza después de cada versión generada por semantic release.
• Puedo desencadenar compilaciones en diferentes ramas para simular la implementación para diferentes canales. En cada configuración de compilación de XCode Cloud en una rama diferente, establezco una variable de entorno manualmente con el valor de branch.channel Establecer en releaserc.json (sí, esto es una duplicación manual) y luego, si lo deseaba, podía desplegar una aplicación de AppStore diferente para cada aplicación de cliente personalizada desplegada desde una rama de liberación personalizada, como se mencionó anteriormente.

Compilando binarios de aplicaciones en XCode Cloud con Capgo canales

7. Conclusión

En conclusión, estoy muy feliz de haber podido integrar Capgo CapacitorUpdater en mi pipeline de liberación semántica estándar, rápidamente dentro del plazo del período de prueba de 14 días, y el resultado es el siguiente:

• Los números de versión de paquetes se generan automáticamente por semantic release y son compatibles con los Capgo servidores
• semantic release despliega automáticamente los paquetes de aplicaciones Capgo, también haciendo uso de Capgo canales
• esto se ajusta perfectamente a las compilaciones de XCode Cloud de binarios de aplicaciones

Pasos siguientes

I actualmente estoy en la fase de desarrollo de esta aplicación. La haré disponible rápidamente para los testadores a través de TestFlight (para iOS). Considerando la potencia de Capgo, estoy seguro de que desplegaré una versión gratuita de la aplicación en la AppStore para pruebas, que se actualizará regularmente con Capgo durante las pruebas. Luego desplegaré otra (paga) versión de la aplicación en la AppStore, bajo otro registro, y también la actualizaré regularmente con Capgo.

Espero poder agregar una mejor verificación de Capgo antes de la compilación en mi configuración de liberación semántica. bundle upload Ahora tengo una pila de liberación semántica limpia, simple y reproducible para futuras aplicaciones móviles desarrolladas con Ionic + Angular + __CAPGO_KEEP_0__.

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

Tengo más de 22 años de experiencia en Salesforce, como cliente y usuario, como socio y integrador, arquitecto, desarrollador, analista de negocio y consultor. Co-fundé y co-administré Altius Services como COO y CTO durante 13 años, un exitoso socio de servicios de Salesforce en Francia, antes de emprender una nueva aventura como solopreneur de Salesforce con mi

oferta de productos Rapido Cloud Puedes encontrarme en LinkedIn en https://linkedin.com/in/rbarrow

Puedes echar un vistazo a nuestras ofertas de Salesforce en https://www.rapido-companion.app.

Me gustaría agregar una mejor verificación de __CAPGO_KEEP_0__ antes de la compilación en mi configuración de liberación semántica. Ahora tengo una pila de liberación semántica limpia, simple y reproducible para futuras aplicaciones móviles desarrolladas con Ionic + Angular + __CAPGO_KEEP_0__. y https://www.rapido.cloud (en desarrollo).

Sigue adelante desde Cómo Rapido Cloud gestiona la liberación semántica con Capgo CapacitorUpdater

Si estás utilizando Cómo Rapido Cloud gestiona la liberación semántica con Capgo CapacitorUpdater para planificar la entrega de actualizaciones en vivo, conecta con Capgo Actualizaciones en vivo para el flujo de trabajo del producto en Capgo Actualizaciones en vivo, Resumen para los detalles de implementación en Resumen, Características para los detalles de implementación en Características Comportamiento de Actualización para los detalles de implementación en Comportamiento de Actualización, y Tipos de Actualización para los detalles de implementación en Tipos de Actualización.