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 me atrajo con su promesa de hacer que las implementaciones de aplicaciones móviles sean mucho más simples, rápidas y flexibles que pasar por el proceso estándar de entrega de Apple AppStore/Google PlayStore. Este es mi primera aplicación móvil que estoy enviando a las tiendas, habiendo concentrado en el pasado en aplicaciones web, usualmente desarrolladas en la nube de Salesforce Experience.

Me asustaba un poco la curva de aprendizaje para hacer esto exitoso, pero pude poner mi aplicación en Apple TestFlight con facilidad. Luego pude usar Capgo CapacitorUpdater para desplegar mis actualizaciones mucho más rápido.

Mi primer requisito y caso de prueba fue desplegar para mí mismo para probar mi aplicación como una aplicación móvil real en mi propio teléfono, en lugar de probarla en un emulador móvil o en un simulador a través del navegador móvil Nexus sugerido por IIonic. Eso porque mi aplicación utiliza características nativas como la geolocalización o el acceso a la Galería de Fotos y la Cámara. Sin experiencia previa de prueba de una aplicación Capacitor móvil, no estaba seguro de si todo iba a funcionar correctamente : nada mejor que probar la aplicación real, en condiciones reales !

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 código fuente code : tan aliviante, y tan flexible, y fácil de configurar !

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

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

Así es como organizo mi modelo de ramas y lanzamiento con CapGo CapacitorUpdater

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

• el desarrollo se lleva a cabo en feature/... ramas derivadas main, y se fusionan en main que 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)
• los despliegues se disparan desde ramas de lanzamiento que pueden ser : production, ramas de lanzamiento previas (alpha, beta, nightly, etc.) y también ramas específicas para clientes o contextuales para entregas personalizadas
• Las despliegues se disparan por una solicitud de extracción. No uso despliegues desencadenados por etiquetas porque semantic release gestiona las etiquetas y todo lo demás por mí.

En resumen, esto es el flujo de Gitlab :

Flujo de Gitlab - fuente https://faun.dev/c/stories/manuelherrera/estrategias-de-ramas-de-git-en-2022

Nota al margen sobre cómo funciona semantic-release :

En una rama de despliegue, cuando se desencadena semantic-release, calculará automáticamente el nuevo número de versión en esta rama, dependiendo del número de versión de la 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 el prerelease alpha, betaen el número de versión.

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

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, etc.

4. Rama, versiones/prereleases, canales en semantic release y en Capgo

Entonces, lo que quiero que semantic release haga para 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 los "Comentarios Convencionales" standard-version herramienta, con su repositorio forkeado standard-version (https://github.com/Cap-go/standard-versiony su propia capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versiony también capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repos. They have documented on their blog the version scheme used by Capgo in their deployments (https://capgo.app/blog/como-funciona-la-versionado-en-capgo/). Los paquetes de JavaScript siguen el esquema de versión estándar de "Semantic Versioning" (https://semver.org) que también sigue (obviamente !) semantic-release Entonces, eso es genial, y es un alivio para mí porque uso

extensivamente. semantic-release También quiero que la liberación semántica genere despliegues de aplicaciones en diferentes canales

Como se mencionó anteriormente, necesito desplegar versiones de pruebas desde ramas como

Etc., pero también versiones específicas de clientes en ramas como alpha, beta, nightly Etc. production-customer-jones, production-customer-doe, etc.

Capgo ofrece la característica de 'canales' que es exactamente lo que también admite la liberación semántica, por lo que estoy emocionado de hacer que funcionen juntos. Estos también se ajustan a los diferentes builds de rama gestionados por XCode Cloud (consulte más sobre esto a continuación).

Los números de versión Semver generados por la liberación semántica en versiones de prueba tienen el aspecto de 1.0.0-alpha.1. Los builds consecutivos en esta rama incrementarán el número de compilación a 1.0.0-alpha.2, etc. Aunque no está documentado explícitamente, estos números de versión están respaldados por Capgo, lo cual es una excelente noticia para mí: utilizaré los canales de liberación semántica y las versiones de prueba para generar versiones de mi aplicación con Capgo canales.

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

Para automatizar la distribución de los paquetes de tu aplicación a Capgo, debes utilizar el comando Capgo CLI bundle upload. Introduce npx @capgo/cli@latest bundle upload --help para obtener las numerosas opciones de carga. Entre ellas, utilizaremos las siguientes:

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

• CANAL es el Capgo canal al que deseamos distribuir (por ejemplo) alpha)
• VERSION es generado por la liberación semántica (por ejemplo) 1.0.0-alpha.1)
• CAPGO_APIKEY is provided by Capgo to uniquely identify your CI/CD pipeline login
• CAPGO_APPID is provided by Capgo to uniquely identify your application (eg com.mystartup.mysuperapp)

6. Mi configuración de liberación semántica + Capgo CapacitorUpdate

Finalmente, ¿cómo se ajusta todo esto?

Versiones de paquetes de la aplicación creadas con liberación semántica y Github Actions

Automatización de liberación semántica con Github Actions

La belleza de la liberación semántica es que la automatización de la implementación, 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 }}

Esto solo instala el entorno de NodeJS, luego llama a la liberación semántica.

Para cada merge en una rama lista en branchesLa liberación semántica desencadenará una implementación para cada merge en una rama lista en CAPGO_APIKEY Configura CAPGO_APPID en los secretos de tu repositorio. Actualiza

aquí. .releaserc.json archivo de configuración. Aquí están mis ajustes, explicados a continuación :

// .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 configura la configuración de ramas (name), mapped to the Capgo channel (channel) y cómo se llamará el número de versión de prerelease (prerelease). Por ejemplo, si branch.prerelease = "development"el número de versión generado por semantic release será x.y.z-development.n
  • despliegues a la alphay alpha-nocapgo ramas se desplegarán ambas en el alphacanal, pero con nombres de prerelease diferentes en el número de versión
  • despliegues a las ramas de desarrollo dev-ruperto dev-paul desplegarán ambos a la developmentcanal 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 tenga acceso correcto a Github. Espero 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 : cometa los siguientes archivos que han sido actualizados por la compilación de Ionic de la aplicación y por el trabajo de la liberación semántica (package.json, CHANGELOG.md y ios/App/App.xcodeproj/project.pbxproj contexto: Página/área: Sitio web de marketing de Capgo. Rol: Etiqueta de interfaz de usuario corta o elemento de navegación. Visto en: página trust.astro. Clave de mensaje `y` (Y).
• @semantic-release/github : adjunta el CHANGELOG.md archivo al Github como un recurso
• @semantic-release/exec: use these 2 commands to prepare the build of the app (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.

etc. : todo está gestionado por defecto por semantic release, con una configuración mínima.

Construyendo nuevos binarios con XCode Cloud

• Integrar todo esto con XCode Cloud para construir nuevas versiones del binario de la aplicación es sencillo (no estoy aún desplegando en Google Play, pero ese build debería ser similar) : production)
• Configuré un proceso de XCode Cloud para construir cuando hay un cambio en la rama que deseo utilizar para esto (por ejemplo CHANGELOG.md en esta rama, configuré XCode Cloud para construir solo cuando el
• se actualiza. Esto se actualiza después de cada versión generada por semantic release branch.channel Puedo desencadenar construcciones en diferentes ramas para simular el despliegue para diferentes canales. En cada configuración de construcción de XCode Cloud en una rama diferente, establecí una variable de entorno manualmente con el valor de releaserc.json establecido en

Construyendo 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 los paquetes se generan automáticamente por la liberación semántica y son compatibles con los Capgo servidores
• La liberación semántica despliega automáticamente los paquetes de aplicaciones Capgo, también haciendo uso de Capgo canales
• Esto se ajusta perfectamente a las construcciones de binarios de aplicaciones en XCode Cloud

Pasos siguientes

Estoy actualmente en la fase de desarrollo de esta aplicación. La pondré rápidamente a disposición de los testers 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 verificación de pre-construcción mejorada de Capgo en mi configuración de liberación semántica. bundle upload Ahora tengo una pipeline 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.

Paso siguiente

I tengo más de 22 años de experiencia en Salesforce, como cliente y usuario, como socio y integrador, arquitecto, desarrollador, analista de negocios y consultor. Co-fundé y co-dirigí Altius Services como COO y CTO durante 13 años, un exitoso socio de Salesforce en Francia, antes de emprender una nueva aventura como solopreneur de Salesforce con mi Rapido Cloud product offering.

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 y context: Página/área: sitio web de marketing de Capgo. Rol: etiqueta de navegación o elemento UI corto. Visto en: página trust.astro. Clave de mensaje `y` (Y). https://www.rapido.cloud

Keep going from How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

context: Página/área: sitio web de marketing de Capgo. Rol: etiqueta de navegación o elemento UI corto. Visto en: página trust.astro. Clave de mensaje `y` (Y). (en desarrollo). How Rapido Cloud gestiona la liberación semántica con Capgo CapacitorUpdater para planificar la entrega de actualizaciones en vivo, conéctelo con Capgo Actualizaciones en vivo for the product workflow in Capgo Live Updates, para el flujo de trabajo del producto en __CAPGO_KEEP_0__ 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