# Despliegue progresivo con tags

> Publica Builds de forma gradual en tu organización usando anillos de despliegue — asocia cada anillo a una Publicación filtrada por tags y promociona un único Build desde el piloto hasta producción.

Source: https://docs.applivery.com/es/app-distribution/distribute/progressive-deployment/  •  Last updated: 2026-07-30

**Answers:** ¿Cómo hago un despliegue por fases en Applivery? · ¿Cómo publico una app primero a un grupo piloto? · ¿Cómo promociono un build entre entornos en Applivery? · ¿Cómo funcionan las tags en las Publicaciones de Applivery? · ¿Puedo usar un único build para varias publicaciones?

**Key topics:** Anillos de despliegue, Tags de Build, Publicaciones, Control de acceso, Applivery, Builds, Grupos de usuarios, Audiencias

---

**TL;DR:** Crea una Publicación por anillo con la selección de Build configurada en Tags, asigna a cada anillo sus propios Grupos o Audiencias y después promociona una versión añadiendo la tag del siguiente anillo al mismo Build.

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.

:::tip
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

**Abre tu App y ve a Apps publicadas**

Crea una nueva Publicación.

**Configura la selección de Build en Tags**

Introduce la tag de este anillo, por ejemplo `ring-pilot`. La Publicación servirá cualquier Build que lleve esa tag.

**Configura la Visibilidad y la Seguridad**

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.

**Restringe el acceso**

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](#cómo-elegir-quién-recibe-cada-anillo) más abajo.

**Dale un slug reconocible**

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](https://docs.applivery.com/es/app-distribution/distribute/distribute-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](https://docs.applivery.com/es/app-distribution/api/publications/create-publication/).

**Integrations API** — limitada a una sola App, autenticada con un App API Token:

```bash
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:

```bash
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](https://docs.applivery.com/es/app-distribution/distribute/user-groups/)** son colecciones de personas seleccionadas a mano. Ideales para un anillo piloto, donde quieres nombrar a los testers exactos.

-   Las **[Audiencias](https://docs.applivery.com/es/app-distribution/distribute/user-audiences/)** 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:

```text
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

**Abre el Build**

Ve a **Builds** en tu App y selecciona el Build que quieres promocionar.

**Añade la tag del siguiente anillo**

Edita sus **Tags** y añade la tag del siguiente anillo.

**Quita la tag del Build anterior**

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](https://docs.applivery.com/es/app-distribution/api/builds/update-build/).

:::warning
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.
:::

```bash
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.

:::tip
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:

```bash
curl 'https://upload.applivery.io/v1/integrations/builds' \
  -X POST \
  -H 'Authorization: Bearer YOUR_APP_TOKEN' \
  -F 'build=@myapp.aab' \
  -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](https://docs.applivery.com/es/app-distribution/api/builds/upload-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.