Cómo Rapido Cloud gestiona la liberación semántica con Capgo CapacitorUpdater
1. IntroducciónEn 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 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 desean gestionar especificidades de la plataforma Salesforce, como Lightning Web Components; y es más fácil y económico para mí reclutar desarrolladores y mantenidos de aplicaciones móviles Ionic + Angular.
Este artículo explica mi diseño, mis elecciones y la implementación que hacen de Capgo y semantic-release una muy exitosa opción sin pensarlo dos veces para gestionar todos los despliegues 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 ?
CapacitorUpdater de Capgo me atrae 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 ir a través del proceso estándar de Apple AppStore/Google PlayStore.
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.
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 !
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 fuente de código 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 :
- se lleva a cabo en se ramifican desde
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)mainse desencadenan las entregas - desarrollo desde ramas de lanzamiento que pueden ser :
production, ramas de lanzamiento prerelease (alpha,beta,nightly, etc.) 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 para 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 :
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 las correcciones o características entregadas. Las correcciones 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 las versiones prerelease alpha, betaetc. en la versión número.
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/es/about) y configurado en semantic release.
Actualizará también todos tus pull requests de git (Github, en mi caso) fusionados y los problemas relacionados con comentarios que los vinculan a la etiqueta y la versión. Finalmente, en esta Github versión, adjuntará activos como fuentes code, binarios si es necesario, CHANGELOG.mdetc.
4. Rama, versiones/prereleases, canales en semantic release y en Capgo
Entonces, lo que quiero que semantic release haga para Capgo despliegues 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 ‘Conventional Commits’ standard-version tool, con su repositorio forkeado standard-version (https://github.com/Cap-go/standard-versiony sus propios capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) también como capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-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-version-en-capgo/). Los paquetes de JavaScript siguen el esquema de 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 extensivamente
I también quiero que semantic release genere despliegues de aplicaciones en diferentes canales
Como se mencionó anteriormente, necesito desplegar versiones de pruebas 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 versiones de pruebas tienen el formato 1.0.0-alpha.1El número de compilación de las sucesivas compilaciones en esta rama se incrementa 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 las versiones de pruebas 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. Presiona 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 Capgo canal al que deseamos desplegar (por ejemplo)
alpha) - VERSION 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 creadas 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 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 }}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 los secretos de tu repositorio.
Actualiza tu CAPGO_APPID aquí.
La configuración del comportamiento de semantic release se establece en su .releaserc.json archivo de configuración.
Aquí te explico mis ajustes, 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:branchesconfigura las ramas (name), mapped to the Capgo channel (channel) y cómo se llamará el número de versión de prerelease (). Por ejemplo, siprerelease, el número de versión generado por semantic release serábranch.prerelease = "development"despliega a lax.y.z-development.n- y
alphayalpha-nocapgoramas desplegarán la aplicación en elalphacanal, pero con diferentes nombres de versión previa en el número de versión - despliegues a las ramas de desarrollo
dev-rupertodev-pauldesplegarán adevelopmentel canal en Capgo, todos con la mismadevelopmentpalabra clave de versión previa en el número de versión
verifyConditions: en la primera etapa de la liberación semántica, 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 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 comoCHANGELOG.md@semantic-release/git: comita 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.mdyios/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 construir y desplegar efectivamente el paquete de la aplicación en los servidores Capgo (publishCmd)
Observarás que no hay que fijarse en cómo queremos que se calcule y se incremente el número de versión, cómo debemos generar un changelog, una etiqueta o lanzamiento Github, etc. : todo está gestionado por defecto por semantic release, con una configuración mínima.
Compilando nuevos binarios con XCode Cloud
Integrando todo esto con XCode Cloud para compilar 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) :
- Establezco un proceso de XCode Cloud para compilar cuando hay un cambio en la rama que deseo utilizar para esto (por ejemplo
production) - en esta rama, establezco XCode Cloud para compilar solo cuando el
CHANGELOG.mdarchivo se actualiza. Esto se actualiza después de cada versión generada por semantic release - Podemos disparar 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.channelestablecido enreleaserc.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.
Compilando 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 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 XCode Cloud de binarios de aplicaciones
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 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.
I espero agregar una mejor verificación previa a la compilación de Capgo bundle upload los requisitos previos en mi configuración de liberación semántica.
Ahora tengo una pila 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 servicios 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 y contexto: Página/área: sitio web de marketing de Capgo. Rol: Etiqueta de navegación corta o elemento de navegación. Visto en: página trust.astro. Clave de mensaje `y` (Y). 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 la entrega de actualizaciones en vivo, conecta con Capgo Actualizaciones en vivo for the product workflow in Capgo Live Updates, para el flujo de trabajo del producto en __CAPGO_KEEP_0__ Actualizaciones en vivo, Resumen para los detalles de implementación en Resumen, Características Comportamiento de Actualización para el detalle de implementación en Comportamiento de Actualización, y Tipos de Actualización para el detalle de implementación en Tipos de Actualización.
