Publicar una versión nueva para todos a la vez significa que, si algo va mal, todo el mundo se entera al mismo tiempo. El despliegue progresivo — también llamado despliegue por fases o por anillos — evita eso publicando primero a un grupo pequeño y ampliando la audiencia solo una vez que la versión ha demostrado su fiabilidad.
Applivery no tiene una función dedicada de "anillos". Los construyes a partir de dos cosas que ya tienes: tags en los Builds y Publicaciones que seleccionan Builds por tag. Todo el modelo cabe en una frase:
Un anillo es una Publicación que sirve Builds que llevan una tag concreta. Promocionar una versión consiste en añadir la tag del siguiente anillo al mismo Build.
Cómo se corresponden los anillos con Applivery
Una configuración típica usa tres anillos, aunque puedes usar tantos como necesites:
| Anillo | A quién llega | Propósito |
|---|---|---|
| Piloto | Un puñado de personas — QA, early adopters | Detectar fallos evidentes antes de que los vea nadie más |
| Despliegue | Uno o dos departamentos | Validar frente al uso real del día a día |
| Producción | Todo el mundo | Disponibilidad general |
Cada anillo necesita dos elementos:
Una tag que identifica el anillo, configurada en la selección de Build de la Publicación.
Una regla de acceso — los Grupos de usuarios o Audiencias que pueden acceder a esa Publicación.
El Build en sí no tiene ninguna noción de anillo. Solo lleva tags, y las Publicaciones deciden qué hacer con ellas.
Cuando subes un Build, las tags se envían como una lista separada por comas, así que una coma dentro del nombre de una tag la divide en dos tags. Usa guiones en su lugar: ring-pilot, ring-rollout, ring-production. Elige una convención y mantenla — la tag es lo que conecta todo.
Crear un anillo
Un anillo es una Publicación normal con la selección de Build configurada en Tags. Crea una por anillo.
Desde el Dashboard
Crea una nueva Publicación.
Introduce la tag de este anillo, por ejemplo ring-pilot. La Publicación servirá cualquier Build que lleve esa tag.
Para anillos internos, la combinación habitual es visibilidad Activa con seguridad Privada — las personas inician sesión con su cuenta de Applivery o con el SSO de tu Workspace. Usa No listada si prefieres compartir el anillo solo mediante URL directa.
En Control de acceso, añade los Grupos de usuarios o Audiencias que pueden acceder a este anillo. Consulta Cómo elegir quién recibe cada anillo más abajo.
Por ejemplo myapp-pilot. La URL resultante es yourworkspace.applivery.com/{slug}.
Acabas con una Publicación y una URL por anillo, cada una atenta a su propia tag.
Para la lista completa de ajustes de Publicación, consulta Distribuir Apps.
Desde la API
El parámetro clave es filter.type configurado en tag, con filter.value conteniendo la tag del anillo. Referencia completa: POST – Crear una Publicación.
Integrations API — limitada a una sola App, autenticada con un App API Token:
curl 'https://api.applivery.io/v1/integrations/distributions' \
-X POST \
-H 'Authorization: Bearer YOUR_APP_TOKEN' \
-H 'Content-Type: application/json' \
-d '{
"slug": "myapp-pilot",
"security": "logged",
"visibility": "active",
"filter": {
"type": "tag",
"value": "ring-pilot"
},
"groups": [["qa-team"]],
"showHistory": true
}'
Workspace API — a nivel de Workspace, autenticada con un token de Service Account:
curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps' \
-X POST \
-H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \
-H 'Content-Type: application/json' \
-d '{
"slug": "myapp-production",
"security": "logged",
"visibility": "active",
"filter": {
"type": "tag",
"value": "ring-production"
},
"activateUserAudiences": true,
"userAudienceMap": [
{ "id": "AUDIENCE_ID", "notifyNewBuildsProcessed": true }
]
}'
security acepta public, password o logged. visibility acepta active, inactive o unlisted.
Cómo elegir quién recibe cada anillo
El acceso a un anillo se controla mediante el Control de acceso de la Publicación, usando Grupos de usuarios o Audiencias.
Los Grupos de usuarios son colecciones de personas seleccionadas a mano. Ideales para un anillo piloto, donde quieres nombrar a los testers exactos.
Las Audiencias se definen mediante reglas y se actualizan por sí solas a medida que las personas se incorporan o salen. Ideales para anillos más amplios, donde mantener una lista manual sería una tarea pesada.
Un punto de partida razonable:
| Anillo | Acceso típico |
|---|---|
ring-pilot |
Grupo de usuarios — equipo de QA, early adopters |
ring-rollout |
Audiencia — un departamento como IT o Soporte |
ring-production |
Audiencia — todo el mundo en el Workspace |
Vía API, groups admite lógica AND/OR: cada array interno es una cláusula AND y cada elemento externo es una cláusula OR, de modo que [["group1","group2"],["group3"]] significa group1 AND group2, OR group3. Solo se aplica cuando security es logged. Para las Audiencias, configura activateUserAudiences en true y enuméralas en userAudienceMap.
Promocionar un Build a través de los anillos
La promoción no implica recompilar ni volver a subir nada. Es el mismo Build ganando tags:
Build #A (v2.0)
1) tags: ring-pilot → visible solo en piloto
2) tags: ring-pilot, ring-rollout → ahora también en despliegue
3) tags: ring-pilot, ring-rollout, ring-production → ahora también en producción
Desde el Dashboard
Ve a Builds en tu App y selecciona el Build que quieres promocionar.
Edita sus Tags y añade la tag del siguiente anillo.
Si un Build más antiguo todavía lleva la tag de ese anillo, quítala para que el anillo sirva exactamente un Build.
El Build aparece en la Publicación de ese anillo en cuanto guardas.
Desde la API
Usa PUT – Actualizar un Build.
El campo tags reemplaza el array completo. Incluye todas las tags que el Build deba conservar — si envías solo la tag nueva, todas las demás se eliminan.
curl 'https://api.applivery.io/v1/integrations/builds/BUILD_ID' \
-X PUT \
-H 'Authorization: Bearer YOUR_APP_TOKEN' \
-H 'Content-Type: application/json' \
-d '{
"tags": ["ring-pilot", "ring-rollout"]
}'
El equivalente en la Workspace API es PUT https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID con un token de Service Account.
Mantén la tag de cada anillo en un solo Build a la vez. Cuando promociones un Build nuevo a un anillo, quita la tag del anterior. Así la versión que sirve cada anillo nunca es ambigua.
¿Un Build para todos los anillos, o un Build por anillo?
Es preferible un único Build promocionado a través de los anillos.
| Enfoque | Qué significa | Recomendación |
|---|---|---|
| Un Build → varios anillos | Compilas y subes una vez; el mismo binario avanza ganando tags | Preferido |
| Un Build por anillo | Compilas y subes un Build distinto para cada anillo | Solo para casos concretos |
El enfoque de un único Build gana por tres razones:
Publicas lo que probaste. El binario exacto que validó tu grupo piloto es el que recibe producción — sin recompilaciones intermedias que introduzcan diferencias.
Los metadatos de versión se mantienen coherentes. Applivery lee la información de versión del propio paquete, así que un Build significa un único conjunto de valores de versión en todos los anillos.
La trazabilidad es sencilla. Una versión equivale a un Build equivale a un historial.
Subir un Build distinto por anillo solo tiene sentido cuando los anillos realmente necesitan binarios diferentes — configuraciones de compilación distintas, endpoints distintos incrustados en tiempo de compilación, y similares. En caso contrario, promociona por tag.
Definir la tag inicial al subir el Build
Puedes ahorrarte un paso etiquetando un Build en el primer anillo al subirlo. Esto encaja de forma natural con un pipeline de CI, que sube el resultado y lo deja directamente en piloto:
curl 'https://upload.applivery.io/v1/integrations/builds' \
-X POST \
-H 'Authorization: Bearer YOUR_APP_TOKEN' \
-F '[email protected]' \
-F 'versionName=v2.0' \
-F 'tags=ring-pilot' \
-F 'changelog=Sprint 42 release'
La respuesta incluye el id del Build, que necesitarás para volver a etiquetarlo más adelante. Consulta POST – Subir un Build para la lista completa de parámetros.
Checklist
Una Publicación por anillo, cada una con selección de Build = Tags.
Una convención de nombres de tags acordada y anotada, sin comas.
Control de acceso configurado por anillo — Grupos para el piloto, Audiencias para los anillos más amplios.
CI sube los Builds nuevos ya etiquetados en el primer anillo.
Promocionar consiste en añadir la tag del siguiente anillo al mismo Build, y quitarla del anterior.