Cómo Rapido Cloud gestiona Semantic Release 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 personalizada sin tener que pasar por los difíciles bucles de utilizar la plataforma móvil de Salesforce (SDK) o el 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 especificaciones de la plataforma de 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 Un verdadero éxito sin complicaciones para gestionar todos los despliegues de manera automática a través de Github Acciones. Todo esto se diseñó, probó y documentó durante el agradable 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 atrae con su promesa de hacer que los despliegues de aplicaciones móviles sean mucho más simples, rápidos y flexibles que ir a través del proceso estándar de Apple AppStore/Google PlayStore.

Me atrae la promesa de Capgo CapacitorUpdater de hacer que los despliegues de aplicaciones móviles sean mucho más simples, rápidos y flexibles que ir a través del proceso estándar de Apple AppStore/Google PlayStore.

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 acceder a la Galería de Fotos y la Cámara. No teniendo la experiencia pasada de probar una aplicación móvil Capacitor, no estaba seguro de si todo iba a funcionar correctamente : nada mejor que probar la aplicación real, en condiciones reales !

So Capgo CapacitorUpdater me ayudó a actualizar mi aplicación en mi dispositivo 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 ramas y liberación, y cómo semantic-release se ajusta a él

Ahora que tengo mi entrega a Capgo servidores funcionando correctamente, necesito automatizar esto y integrarlo en mi pipeline 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 se desencadenan los despliegues
• desde las ramas de liberación desarrollo que pueden ser : production, ramas de pruebas (alpha, beta, nightly, etc.) y también ramas específicas para clientes o contextuales para entregas personalizadas
• se desencadenan los despliegues por una solicitud de extracción están siendo fusionadas en una rama de despliegue. No uso despliegues desencadenados por etiquetas porque semantic release gestiona las etiquetas y todo lo demás para mí.

Básicamente, este 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 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 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 define en commits convencionales (ver https://www.conventionalcommits.org/en/about) y configurado en semantic release.

Actualizará también todos tus pull requests de git (en mi caso, Github) y problemas relacionados con comentarios que enlacen a ellos a la etiqueta y la versión. Finalmente, en esta Github versión, adjuntará activos como código fuente code, binarios si es necesario, etc. CHANGELOG.md4. Rama, versiones/prereleases, canales en semantic release y en __CAPGO_KEEP_0__

Entonces, lo que quiero que semantic release haga 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-version4. Branches, releases/prereleases, channels in semantic release and in __CAPGO_KEEP_0__ capacitor-standard-version (https://github.com/Cap-go/capacitor-versión-estándar) además de capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-versión-estándar) repositorios. Han documentado en su blog el esquema de versión utilizado por Capgo en sus despliegues (https://capgo.app/blog/cómo-funciona-la-versión-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 uso semantic-release de manera extensiva.

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

As mencionado anteriormente, necesito desplegar la versión 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. Los siguientes compilados 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 soportados por Capgo, lo cual es una excelente 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 mi aplicación a Capgo, necesito utilizar el comando Capgo CLI bundle upload. Tipo 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 canal Capgo al que queremos 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 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 semantic release.

Por cada mérge en una rama lista en branches, semantic release desencadenará una implementación. Configura CAPGO_APIKEY In su repositorio, en las variables de entorno. Actualice su CAPGO_APPID Aquí.

El comportamiento de semantic release se configura en su archivo de configuración. Aquí están mis configuraciones, explicadas a continuación: .releaserc.json configura 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 ) que se mapean al canal (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 a la x.y.z-development.n
  • y las alpharamas desplegarán la aplicación en el alpha-nocapgo sets the configuration of branches (__CAPGO_KEEP_0__) alphacanal, pero con diferentes nombres de versión de prerelease
  • despliegues a las ramas de desarrollo del programador dev-ruperto dev-paul ambos se desplegarán en el developmentcanal en Capgo, todos con la misma developmentpalabra clave de prerelease en la versión del número
• verifyConditions : en la primera etapa de la liberación semántica, verifica que tiene el 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 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 - No construyo para Android, aún)
• @semantic-release/github : adjunta el CHANGELOG.md archivo al Github release como 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 en los servidores Capgo (publishCmd)

Usted notará que no hay manipulación con explicaciones sobre 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 release, etc. : todo está manejado por defecto por semantic release, 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) :

• Configuré 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, configuré XCode Cloud para construir solo cuando el CHANGELOG.md archivo se actualiza. Esto se actualiza después de cada versión generada por semantic release
• 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 branch.channel establecido en releaserc.json (sí, se trata de 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 canales Capgo

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 liberación semántica y son compatibles con los servidores Capgo
• La liberación semántica despliega automáticamente los paquetes de aplicaciones Capgo, también haciendo uso de los canales Capgo
• Esto se ajusta bien a las construcciones 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 probadores a través de TestFlight (para iOS). Considerando la potencia de Capgo, sin duda 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 pre-construcción de Capgo bundle upload configuración de lanzamiento semántico en mi configuración de lanzamiento semántico.

Ahora tengo un pipeline de lanzamiento semántico limpio, 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 negocio y consultor. Co-fundé y co-dirigí 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 Rapido Cloud oferta de productos.

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).

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 Live Updates para el flujo de trabajo del producto en Capgo Live Updates, 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 Update Behavior, y Tipos de Actualización para los detalles de implementación en Tipos de Actualización.