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 especificidades 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 decisiones y la implementación que hacen que Capgo y semantic-release un muy exitoso no-brainer para gestionar todas las implementaciones automáticamente a través de Github Actions. 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 attracted me with its promise to make mobile app deployments much more simple, much more rapid and flexible than going through the standard Apple AppStore/Google PlayStore delivery process. This is my first mobile application which I am pushing to the stores, having concentrated in the past on web apps, usually developed on the Salesforce Experience Cloud.
Me asustaba 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. No teniendo experiencia en el pasado de probar una Capacitor aplicación 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 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 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 de CI/CD.
Esto es cómo organizo mi modelo de ramificación y liberación
Para cada aplicación, ya sea móvil, web o Salesforce :
- development ramas derivadas de
feature/..., y se fusionan enmainque 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)mainla cual es la referencia para la mayoría de las ramas de desarrollo, fuera de mantenimiento y características específicas para entregas personalizadas (más sobre esto abajo) - desde ramas de liberación desde ramas de liberación que puede ser :
production, rama de pruebas (alpha,beta,nightly, etc.) y también rama específica del cliente o del contexto para entregas personalizadas - los despliegues se disparan por una solicitud de extracción Estoy siendo integrado a una rama de despliegue. No utilizo despliegues desencadenados por etiquetas porque semantic release gestiona las etiquetas y el resto para 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 dispara 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, 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.comunicadosconvencionales.org/es/acercade) y configurados en liberación semántica.
It también actualizará todos tus pull requests de git (Github, en mi caso) fusionados y problemas relacionados con comentarios que los vinculen a la etiqueta y la liberación. Finalmente, en esta Github liberación, adjuntará activos como fuentes code, binarios si es necesario, etc. CHANGELOG.md, etc.
4. Rama, versiones de pruebas y canales en semantic release y en Capgo
Así es como quiero que semantic release realice Capgo para las implementaciones.
Quiero que semantic release genere el número de versión.
Capgo han desarrollado y documentado su propia versión de la ‘Conventional Commits’ standard-version __CAPGO_KEEP_0__.com/Cap-go/standard-version standard-version (https://github.com/Cap-go/standard-versiony sus propios 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/como-funciona-la-versionado-en-capgo/) Los paquetes de JavaScript siguen la 'estándar' semver 'Semantic Versioning' (https://semver.org) lo cual semantic-release también sigue (obviamente !)
Entonces eso es genial, y es un alivio para mí porque uso semantic-release extensivamente.
Quiero que la liberación semántica genere despliegues de aplicaciones en diferentes canales
As mencionado anteriormente, necesito desplegar la versión prerelease desde ramas como alpha, beta, nightly por ejemplo, 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 construcciones 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.1El número de construcción en este ramo aumentará en cada construcción 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 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, 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- CHANNEL es el canal Capgo al que deseamos 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?
Versiónes de paquete de aplicación construidas con semantic release y Github Acciones
Automatización de semantic release con Github Actions
La belleza de semantic release es que la automatización de 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 }}Esto solo instala el entorno de NodeJS, luego llama a semantic release.
Para cada merge en una rama lista en branchessemantic release desencadenará un despliegue.
Establece CAPGO_APIKEY en su repositorio de secretos.
Actualice su CAPGO_APPID aquí.
El comportamiento de la liberación semántica está configurado en su .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:branchesestablece la configuración de ramas ("name), asignado al canal Capgo.channel) y cómo se llamará el número de versión de prerelease (prerelease). Por ejemplo, sibranch.prerelease = "development", el número de versión generado por la liberación semántica seráx.y.z-development.n- despliegues a los
alphayalpha-nocapgolas ramas se desplegarán ambas la aplicación en elalphacanal, pero con diferentes nombres de prerelease en el número de versión - despliegues a las ramas de desarrollo
dev-rupertodev-pauldesplegarán a ambosdevelopmentcanal en Capgo, todos con el mismodevelopmentcanal en __CAPGO_KEEP_0__, todos con la misma
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: cosas estándar de liberación semántica - consulte su documentación (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#formato-de-mensaje-de-commit)@semantic-release/release-notes-generatorhttps://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formatCHANGELOG.md@semantic-release/gitComite 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.mdandios/App/App.xcodeproj/project.pbxproj- No construyo para Android, aún)@semantic-release/github: adjunta elCHANGELOG.mdarchivo al Github como activo@semantic-release/exec: utiliza estos 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 a los servidores Capgo (publishCmd)
Observarás 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 liberación, 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 esa compilación debería ser similar) :
- Establezco 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, establezco XCode Cloud para construir solo cuando el
CHANGELOG.mdarchivo se actualiza. Esto se actualiza después de cada versión generada por semantic release - Puedo desencadenar compilaciones en diferentes ramas para simular el despliegue para diferentes canales. En cada configuración de XCode Cloud para construir en una rama diferente, establezco una variable de entorno manualmente con el valor de
branch.channelestablecido enreleaserc.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 liberación personalizada, como se mencionó anteriormente.
Construyendo binarios de aplicaciones en XCode Cloud con canales de 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 del paquete se generan automáticamente por semantic release y son compatibles con los servidores Capgo.
- lanzamiento semántico despliega automáticamente paquetes de aplicaciones Capgo, también aprovechando los canales Capgo
- 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, 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 verificación de pre-construcción mejorada de Capgo bundle upload requisitos 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 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 Rápido Cloud Puedes encontrarme en LinkedIn en
https://linkedin.com/in/rbarrow https://linkedin.com/in/rbarrow.
Puede ver nuestras ofertas de Salesforce en https://www.rapido-companion.app and https://www.rapido.cloud (en desarrollo).
Sigue adelante desde Cómo Rapido Cloud gestiona la liberación semántica con Capgo CapacitorUpdater
Si estás utilizando Cómo Rapido Cloud gestiona la liberación semántica con Capgo CapacitorUpdater para planificar live update entrega, 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, Comportamiento de actualización para los detalles de implementación en Comportamiento de Actualización, y Tipos de Actualización para los detalles de implementación en Tipos de Actualización.
