Cómo Rapido Cloud gestiona Semantic Release con 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.

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 las especificidades de la plataforma Salesforce, como Lightning Web Components; 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 y la implementación que hacen que Capgo y semantic-release sea un muy buen negocio 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 las implementaciones de aplicaciones móviles sean mucho más simples, mucho más rápidas y flexibles que pasar por el proceso estándar de Apple AppStore/Google PlayStore.

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 aliviado, 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 Capgo servidores funcionando correctamente, necesito automatizar esto y ajustarlo a mi pipeline CI/CD.

Esta es la forma en que organizo mi modelo de ramificación y lanzamiento

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

• se lleva a cabo el desarrollo en ramas derivadas de 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 se desencadenan los despliegues desde las ramas de lanzamiento
• que pueden ser: , ramas de lanzamiento previas ( , etc.) y también ramas específicas para clientes o contextuales para entregas personalizadas productiony también ramas específicas para clientes o contextuales para entregas personalizadasalpha, beta, nightlyy también ramas específicas para clientes o contextuales para entregas personalizadas
• Las implementaciones se desencadenan mediante una solicitud de extracción. No uso las implementaciones desencadenadas 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/git-branching-strategies-in-2022

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

En una rama de implementación, cuando semantic-release se desencadena, 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, 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 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.md4. Rama, versiones/prereleases, canales en semantic release y en __CAPGO_KEEP_0__

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

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

__CAPGO_KEEP_0__ han desarrollado y documentado su propia versión de la "Conventional Commits"

Capgo have developed and documented their own version of the “Conventional Commits” standard-version https://__CAPGO_KEEP_0__.com/Cap-go/standard-version standard-version (https://github.com/Cap-go/standard-versionhttps://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-standard-version capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionhttps://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-plugin-standard-version capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionrepositorios. 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 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 semantic release genere despliegues de aplicaciones en diferentes canales

Como se mencionó anteriormente, necesito desplegar versiones de prueba 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

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 los diferentes builds de rama gestionados por XCode Cloud (consulte más sobre esto a continuación).

Los números de versión de semver generados por semantic release en versiones de prueba parecen 1.0.0-alpha.1. Los builds consecutivos en esta rama incrementarán el número de build 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 gran noticia para mí: utilizaré los canales de semantic release y prerelease para generar versiones de mi aplicación con Capgo canales.

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

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

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

• CANAL es el canal de Capgo 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 lanzamiento semántico + Capgo CapacitorUpdate configuración

Finalmente, ¿cómo se ajusta todo esto?

Versiones de paquetes de la aplicación construidas con semantic release y Github Acciones

Automatización de lanzamiento semántico con Github Acciones

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

Para cada mero en una rama listada en branchesla automatización de semantic release desencadenará una implementación. CAPGO_APIKEY Establezca CAPGO_APPID en los secretos de su repositorio.

Actualice su configuración de CI/CD aquí. .releaserc.json archivo de configuración. Aquí están 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 configura la configuración de ramas (name), asignada al canal de Capgo (channel) y cómo se llamará la versión prerelease (prerelease). Por ejemplo, si branch.prerelease = "development", la versión de número generada por semantic release será x.y.z-development.n
  • despliegues a la alphay las alpha-nocapgo ramas desplegarán la aplicación en el alphacanal, pero con diferentes nombres de versión prerelease
  • despliegues a las ramas de desarrollo dev-ruperto dev-paul se desplegarán ambos en el developmentcanal en Capgo, todos con la misma developmentpalabra de prerelease en el número de versión
• verifyConditions : en la primera etapa de semantic release, verifica que tiene acceso correcto a Github. Espero agregar una verificación de autenticación para el Capgo CLI aquí más tarde
• @semantic-release/commit-analyzer : cosas estándar de semantic release - 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 semantic release (package.json, CHANGELOG.md y ios/App/App.xcodeproj/project.pbxproj - No construyo para Android, todavía)
• @semantic-release/github : adjunte el CHANGELOG.md archivo a la Github liberación como un activo
• @semantic-release/exec: use these 2 comandos para preparar la compilación de la aplicación (prepareCmd) y luego para compilar y desplegar efectivamente el paquete de la aplicación en los Capgo servidores (publishCmd)

No notará que no hay que explicar cómo queremos que se calcule y se incremente el número de versión, cómo debemos generar un changelog, un Github etiqueta o lanzamiento, etc. : todo está manejado 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) :

• Configuré un proceso de XCode Cloud para que se ejecute cuando haya un cambio en la rama que deseo utilizar para esto (por ejemplo, production)
• en esta rama, configuré XCode Cloud para que se ejecute solo cuando el CHANGELOG.md archivo se actualice. Esto se actualiza después de cada versión generada por semantic release
• Puedo activar construcciones en diferentes ramas para simular el despliegue para diferentes canales. En cada configuración de XCode Cloud para construir en una rama diferente, establecí 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 lanzamiento personalizada, como se mencionó anteriormente.

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 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 compilaciones de binarios de aplicaciones en XCode Cloud

Pasos siguientes

Actualmente estoy 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, sin duda deployaré 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 deployaré 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 pre-compilación de Capgo bundle upload requisitos previos en mi configuración de liberación semántica.

Ahora tengo una pipeline de liberación semántica limpia, simple y reproducible para futuras aplicaciones móviles desarrolladas con Ionic + Angular + Capacitor.

Autor - Rupert Barrow

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 SI de Salesforce en Francia, antes de emprender una nueva aventura como solopreneur de Salesforce con mi Rapido Cloud oferta de producto.

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 https://www.rapido.cloud (en desarrollo).