1. Introducción
En Rapido Cloud (www.rapido.cloud), estoy desarrollando una app móvil para clientes de Salesforce para que desplieguen su propia app de marca sin pasar por los complejos ciclos de Salesforce Mobile SDK o Salesforce Mobile Publisher.
He desarrollado esta app en una plataforma moderna y estándar con herramientas como Ionic 8, Angular 18, TypeScript, Capacitor y ahora Capgo CapacitorUpdater. Es más sencillo para clientes que no quieren gestionar especificidades de Salesforce como Lightning Web Components; y me resulta más fácil y barato contratar devs para Ionic + Angular.
Este artículo explica mi diseño, mis decisiones e implementación que hacen de Capgo y semantic-release una solución automática muy eficaz para gestionar despliegues vía Github Actions. Todo fue diseñado, probado y documentado durante los 14 días de prueba gratuita de Capgo CapacitorUpdater.
2. ¿Por qué usar Capgo? ¿Por qué usar semantic-release?
Capgo CapacitorUpdater me atrajo con su promesa de hacer los despliegues de apps móviles mucho más simples, rápidos y flexibles que el proceso estándar de la App Store de Apple o la Play Store de Google. Esta es la primera aplicación móvil que subo a las tiendas, ya que antes me había centrado en web apps, desarrolladas normalmente en Salesforce Experience Cloud.
Me preocupaba un poco la curva de aprendizaje para que esto funcionara, pero logré subir mi app a Apple TestFlight con bastante facilidad. Así, 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 y probar mi app como una app móvil real en mi propio teléfono, en lugar de probar en un emulador móvil o en un simulador mediante el navegador móvil Nexus que sugiere Ionic. Esto se debe a que mi app usa funciones nativas como Geolocation o el acceso a la galería de fotos y la cámara. Al no tener experiencia previa probando una app móvil con Capacitor, no estaba seguro de si todo iba a funcionar correctamente: ¡nada mejor que probar la app real en condiciones reales!
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 funcionalidad o fix en mi code de origen: ¡qué alivio, qué flexible y qué fácil de configurar!
3. Mi modelo de branching y release, y cómo encaja semantic-release
Ahora que mi entrega a los servidores de Capgo funciona correctamente, necesito automatizar esto e integrarlo en mi pipeline de CI/CD.
Así es como organizo mi modelo de branching y release
Para cada aplicación, ya sea móvil, web o Salesforce:
- desarrollo se realiza en
feature/...que parten demain, and they are merged intomainque es la referencia para la mayoría de las ramas de desarrollo, salvo mantenimiento y features específicas para entregas personalizadas (más sobre esto abajo) - se disparan los deployments desde ramas de release que pueden ser:
production, ramas de prerelease (alpha,beta,nightly, etc.) y también ramas específicas de clientes o contextos para entregas personalizadas - los deployments se activan mediante un pull request que se mergea en una rama de deployment. No uso deployments activados por tags porque semantic-release gestiona los tags y todo lo demás por mí.
Básicamente, este es el Gitlab Flow:
Gitlab Flow - fuente https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
Una nota sobre cómo funciona semantic-release:
En una rama de deployment, cuando se activa semantic-release, calculará automáticamente el nuevo número de versión en esta rama, según el número de versión del tag anterior en la rama y los fixes o features entregados. Los fixes crearán una nueva versión patch, mientras que los features crearán una nueva versión minor. También incluye automáticamente la prerelease alpha, beta, etc. en el número de versión.
Semantic release genera el changelog a partir de tus commits, agrupando fixes y features según lo definido en conventional commits (ver https://www.conventionalcommits.org/es/about) y configurado en semantic release.
También actualizará todos tus pull requests mergeados de git (Github, en mi caso) y los issues relacionados con comentarios que los vinculen al tag y al release. Por último, en este release de Github, adjuntará assets como el código fuente code, binarios si hace falta, CHANGELOG.md, etc.
4. Branches, releases/prereleases y channels en semantic-release y en Capgo
Así que lo que quiero que haga semantic release para los deployments 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 herramienta “Conventional Commits” standard-version , con su repo forkeado standard-version (https://github.com/Cap-go/standard-version), y sus propios capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) así como capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repos. Han documentado en su blog el esquema de versiones que usa Capgo en sus despliegues ("https://capgo.app/blog/como-funciona-el-versionado-en-capgo/"). Los bundles de JavaScript siguen el semver "standard" o "Semantic Versioning" ("https://semver.org") el cual semantic-release también sigue (¡obviamente!)
Eso es genial y me da un respiro porque uso semantic-release intensivamente.
También quiero que semantic-release genere deployments de la app en diferentes channels
Como mencioné antes, necesito desplegar versiones prerelease desde ramas como alpha, beta, nightly etc., pero también versiones específicas para clientes en ramas como production-customer-jones, production-customer-doe, etc.
Capgo ofrece la funcionalidad de “channels”, que es exactamente lo que también soporta semantic release, así que me entusiasma hacerlos trabajar juntos. Estos también encajan con los diferentes builds de ramas gestionados por XCode Cloud (ver más abajo).
Los números de versión Semver generados por semantic release en prereleases se ven así: 1.0.0-alpha.1. Los builds sucesivos en esta rama incrementarán el número de build a 1.0.0-alpha.2, etc. Aunque no está documentado explícitamente, Capgo soporta estos números de versión, lo cual es una gran noticia para mí: usaré los channels de semantic release y prerelease para generar versiones de mi app con channels de Capgo.
5. ¿Cómo puedo usar Capgo para lanzar mi app?
Para automatizar el deployment de tus app bundles a Capgo, necesitas usar el comando Capgo CLI de Capgo bundle upload. Escribe npx @capgo/cli@latest bundle upload --help para ver las múltiples opciones de upload. Entre ellas, usaremos las siguientes:
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- CHANNEL es el channel de Capgo al que queremos hacer deploy (ej.
alpha) - VERSION es generada por semantic release (ej.
1.0.0-alpha.1) - CAPGO_APIKEY es proporcionada por Capgo para identificar de forma única tu login de pipeline de CI/CD
- CAPGO_APPID es proporcionada por Capgo para identificar de forma única tu aplicación (ej.
com.mystartup.mysuperapp)
6. Mi setup de semantic-release + Capgo CapacitorUpdate
¿Cómo encaja todo esto al final?
Versiones de app bundles con semantic release y Github Actions
Automatización de semantic-release con Github Actions
Lo mejor de semantic release es que la automatización del despliegue, mediante un workflow de Github Action, es muy sencilla. Será 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 y luego ejecuta semantic release.
Para cada merge en una rama listada en branches, semantic release activará un despliegue.
Configura CAPGO_APIKEY en los secrets de tu repositorio.
Actualiza tu CAPGO_APPID aquí.
El comportamiento de semantic release se define en su .releaserc.json archivo de configuración.
Aquí tienes mi configuración, explicada abajo:
// .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:branchessets the configuration of branches (name), mapeadas al canal Capgo (channel) y cómo se llamará la versión prerelease (prerelease). Por ejemplo, sibranch.prerelease = "development", el número de versión generado por semantic release seráx.y.z-development.n- despliegues a las
alphayalpha-nocapgoramas desplegarán la app en elalphacanal, pero con distintos nombres de prerelease en la versión - despliegues a las ramas de desarrollo
dev-rupertodev-paulse desplegarán ambos aldevelopmentcanal en Capgo, todos con la mismadevelopmentkeyword de prerelease en el número de versión
verifyConditions: en la primera etapa de semantic release, comprueba que tiene el acceso correcto a Github. Espero añadir un check de autenticación para el Capgo CLI aquí más adelante@semantic-release/commit-analyzer: lo estándar de semantic release; consulta su documentación (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator: genera el archivo changelog comoCHANGELOG.md@semantic-release/git: hace commit de los siguientes archivos actualizados por el build de Ionic de la aplicación y por el proceso de semantic release (package.json,CHANGELOG.mdyios/App/App.xcodeproj/project.pbxproj- (aún no hago builds para Android)@semantic-release/github: adjunta elCHANGELOG.mdarchivo al release de Github como un asset@semantic-release/exec: usa estos 2 comandos para preparar el build de la app (prepareCmd) y luego para hacer el build y deploy del app bundle a los servidores de Capgo (publishCmd)
Notarás que no hay que complicarse explicando cómo queremos calcular e incrementar el número de versión, cómo generar un changelog, un tag o release de Github, etc.: todo lo gestiona semantic release por defecto con una configuración mínima.
Generar nuevos binarios con XCode Cloud
Integrar todo esto con XCode Cloud para generar nuevas versiones del binario de la app es sencillo (aún no despliego en Google Play, pero el build debería ser similar):
- Configuré un proceso en XCode Cloud para que haga el build cuando haya un cambio en la rama que quiero usar (ej.
production) - en esta rama, configuré XCode Cloud para que haga el build solo cuando el
CHANGELOG.mdarchivo se actualice. Este se actualiza tras cada versión generada por semantic release - Puedo lanzar builds en distintas ramas para simular el despliegue para diferentes canales. En cada configuración de build de XCode Cloud en una rama distinta, defino manualmente una variable de entorno con el valor de
branch.channeldefinido enreleaserc.json(sí, esto es una duplicación manual) y luego, si quisiera, podría desplegar una aplicación de App Store distinta para cada aplicación personalizada de cliente desplegada desde una rama de release personalizada, como mencioné antes.
Compilar binarios de la app en XCode Cloud con canales Capgo
7. Conclusión
En conclusión, estoy muy contento de haber podido integrar Capgo CapacitorUpdater en mi pipeline estándar de semantic release, rápidamente dentro del periodo de prueba de 14 días, y el resultado es el siguiente:
- los números de versión del bundle se generan automáticamente por semantic release y son compatibles con los servidores de Capgo
- semantic release despliega automáticamente bundles de aplicación de Capgo, usando también canales Capgo
- esto encaja perfectamente con los builds de binarios de la aplicación en XCode Cloud
Próximos pasos
Actualmente estoy en la fase de desarrollo de esta app. Pronto la pondré a disposición de los testers a través de TestFlight (para iOS). Dada la potencia de Capgo, sin duda desplegaré una versión gratuita de la app en el App Store para pruebas, que actualizaré regularmente con Capgo durante las pruebas. Luego desplegaré otra versión (de pago) de la app en el App Store, bajo otro registro, y también la actualizaré regularmente con Capgo.
Espero añadir una mejor verificación previa al build de Capgo bundle upload los prerrequisitos en mi configuración de semantic release.
Ahora tengo un pipeline de semantic release limpio, simple y reproducible para futuras apps móviles con Ionic + Angular + Capacitor.
Autor - Rupert Barrow
Tengo más de 22 años de experiencia en Salesforce como cliente, usuario, partner, integrador, arquitecto, desarrollador, analista de negocio y consultor. Co-fundé y gestioné Altius Services como COO y CTO durante 13 años, un exitoso partner de Salesforce SI en Francia, antes de emprender una nueva aventura como solopreneur de Salesforce con mi Nube rápida propuesta de productos.
Puedes encontrarme en LinkedIn en https://linkedin.com/in/rbarrow.
Puedes echar un vistazo a nuestras soluciones de Salesforce en https://www.rapido-companion.app y https://www.rapido.cloud (en desarrollo).
Sigue leyendo: Cómo Rapido Cloud gestiona Semantic Release con Capgo CapacitorUpdater
Si estás usando Cómo Rapido Cloud gestiona Semantic Release con Capgo CapacitorUpdater para planificar la entrega de live update, conéctalo con Live Updates de Capgo para el flujo de trabajo del producto en Capgo Live Updates, Resumen para el detalle de implementación en Overview, Funcionalidades para el detalle de implementación en Features, Comportamiento de actualización para el detalle de implementación en Update Behavior, y Tipos de actualización para el detalle de implementación en Update Types.
