¿Cómo Rapido Cloud gestiona la liberación semántica con Capgo CapacitorUpdater?

1. Introducción

En Rapido Cloud (www.rapido.cloud), estoy desarrollando una aplicación móvil para clientes de Salesforce para que puedan desplegar fácilmente su propia aplicación móvil con marca propia sin tener que pasar por los difíciles bucles de utilizar la aplicación móvil de Salesforce SDK o el Publicador de Aplicaciones Móviles de Salesforce.

He desarrollado esta aplicación móvil en una plataforma moderna y "estándar" con componentes y herramientas ampliamente utilizados, incluyendo Ionic 8, Angular 18, TypeScript, Capacitor y ahora Capgo CapacitorUpdater. Estos son más fáciles de manejar para los clientes que no quieren gestionar especificidades de la plataforma de Salesforce, como los Componentes Web de Lightning; y es más fácil y económico para mí reclutar desarrolladores y mantenores de aplicaciones móviles Ionic + Angular.

Este artículo explica mi diseño, mis elecciones e implementación que hacen que Capgo y semantic-release sea una opción muy exitosa y sin problemas para gestionar todos los despliegues automáticamente a través de Github Actions. Todo esto fue diseñado, probado y documentado durante el período de prueba de 14 días gratuito de Capgo CapacitorUpdater.

2. ¿Por qué usar Capgo ? ¿Por qué usar semantic-release ?

Capgo CapacitorUpdater me atrajo con su promesa de hacer que los despliegues de aplicaciones móviles sean mucho más simples, mucho más rápidos y flexibles que pasar por el proceso estándar de Apple AppStore/Google PlayStore de entrega.

I estaba un poco asustado por la curva de aprendizaje para hacer esto exitoso pero pude poner mi aplicación en Apple TestFlight de manera bastante fácil. Pude entonces utilizar 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 !

Así que 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 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

Así que 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 el desarrollo en se desprenden rama 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 : productionramas de liberación previas (alpha, beta, nightlyetc.) y también ramas específicas para clientes o contextuales 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 por mí.

Básicamente, esto es el flujo de Gitlab :

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

Nota al margen 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. alpha, betaLos arreglos crearán una nueva versión de parche, mientras que las características crearán una nueva versión menor.

Además, incluirá automáticamente el prerelease , 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

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) y configurados en semantic release.

También actualizará todos tus pull requests de Git (Capgo, en mi caso) fusionados y problemas relacionados con comentarios que enlacen a la etiqueta y la versión.

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

, etc.

4. Ramas, versiones/prereleases, canales en semantic release y en Capgo standard-version Entonces, lo que quiero que haga semantic release para los despliegues de __CAPGO_KEEP_0__ es lo siguiente. standard-version (https://github.com/Cap-go/versión-estándar), y sus propias capacitor-standard-version (https://github.com/Cap-go/capacitor-versión-estándar) así como capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-estándar-version) repositorios. Han documentado en su blog el esquema de versión utilizado por Capgo en sus despliegues (https://capgo.app/blog/como-funciona-la-versionado-en-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 yo uso semantic-release extensivamente.

También quiero que semantic release genere despliegues de la aplicación 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 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 parecen 1.0.0-alpha.1. Los compilados consecutivos en esta rama incrementarán el número de compilación a 1.0.0-alpha.2, etc. Aunque no se documenta explícitamente, estos números de versión están respaldados por 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 To obtener las numerosas opciones de carga. Entre ellas, usaremos 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 queremos desplegar (por ejemplo alpha)
• 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 actualización de Capacitor con semantic release + Capgo

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 la liberación semántica con Github Actions

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

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

For cada merge en una rama listada en branches, semantic release desencadenará un despliegue. Establecer CAPGO_APIKEY en los secretos de tu repositorio. Actualiza tu CAPGO_APPID aquí.

El comportamiento de semantic release se establece en su .releaserc.json archivo de configuración. Aquí tienes mis configuraciones, explicadas 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 establece la configuración de ramas (name), vinculadas al canal Capgo (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 al alphay las ramas deployarán la aplicación en el alpha-nocapgo canal, pero con diferentes nombres de prerelease en el número de versión alphadespliegues a las ramas del desarrollador
  • o dev-rupertdeployarán ambos a dev-paul canal en __CAPGO_KEEP_0__, todos con el mismo developmentchannel on Capgo, all with the same development: en la primera etapa de la liberación semántica, verifica que tenga el acceso correcto a __CAPGO_KEEP_0__. Espero poder agregar una verificación de autenticación para el __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ aquí más tarde
• 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 y 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 archivo a la Github liberación como un activo
• @semantic-release/exec: utiliza estos 2 comandos para preparar la compilación de la aplicación (prepareCmd) y luego para construir y desplegar efectivamente el paquete de la aplicación a los servidores Capgo (publishCmd)

Usted notará que no hay manipulación al explicar cómo queremos que se calcule y se incremente el número de versión, cómo debemos generar un changelog, una Github etiqueta o liberación, etc. : todo está manejado por defecto por la liberación semántica, con configuración mínima.

Construyendo nuevos binarios con XCode Cloud

Integrando todo esto con XCode Cloud, construir nuevas versiones del binario de la aplicación es simple (No estoy aún desplegando en Google Play, pero esa compilación debería ser similar) :

• Establecí un proceso de XCode Cloud para construir cuando hay un cambio en la rama que deseo utilizar para esto (por ejemplo production)
• en esta rama, establecí XCode Cloud para construir solo cuando el CHANGELOG.md El archivo ha sido actualizado. 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 establecido en releaserc.json (sí, esto es una duplicación manual) y luego, si lo deseaba, podrí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.

Compilar 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 los 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 pondré rápidamente a disposición de los probadores 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 Tienda de Aplicaciones para pruebas, que se actualizará regularmente con Capgo durante las pruebas. Luego desplegaré otra (paga) versión de la aplicación en la Tienda de Aplicaciones, bajo otro registro, y también la actualizaré regularmente con Capgo.

Espero poder agregar una mejor verificación de Capgo previa a la compilación en mi configuración de semantic release. bundle upload Ahora tengo un pipeline de liberación semántica limpio, 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-dirigí Altius Services como COO y CTO durante 13 años, un exitoso socio de integración 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.

TestFlight (para iOS) Tienda de Aplicaciones y https://www.rapido.cloud (en desarrollo).

Sigue adelante desde cómo Rapido Cloud gestiona Semantic Release con Capgo CapacitorUpdater

Si estás utilizando Cómo Rapido Cloud gestiona Semantic Release 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, Actualizar Comportamiento para los detalles de implementación en Actualizar Comportamiento, y Tipos de Actualización para los detalles de implementación en Tipos de Actualización.