Despliegue de SPFx a todo el tenant o sitio a sitio
Última actualización:
Cuando subes un .sppkg al catálogo de aplicaciones, SharePoint pregunta si quieres hacer la solución disponible para todos los sitios de la organización. Marcarlo despliega una vez y el componente queda disponible en todas partes. Dejarlo sin marcar significa que alguien tiene que añadir la app en cada sitio antes de que nadie allí pueda usarla.
La casilla no es del todo tuya: refleja skipFeatureDeployment en el manifiesto del paquete, y algunos paquetes exigen true. Por ejemplo, cualquier solución con componentes expuestos en Microsoft Teams tiene que ser de alcance de tenant.
Lo importante que conviene zanjar primero, porque es de donde viene la inquietud: que esté disponible en todo el tenant no pone nada en las páginas de nadie. Hace que el web part aparezca en el selector para quien edita páginas. No se renderiza nada hasta que alguien con permisos de edición lo coloca a propósito.
Qué cambia de verdad
| Todo el tenant | Sitio a sitio | |
|---|---|---|
| Esfuerzo de despliegue | Una vez | Por sitio, para siempre |
| Quién puede usarlo | Quien edite páginas en cualquier sitio | Solo los sitios donde se haya añadido la app |
| Aparece en el selector de web parts | En todas partes | Solo donde se haya añadido |
| Se renderiza solo en las páginas | No | No |
| Quitar el acceso a un sitio | No directamente: se controla con permisos de sitio | Quitar la app de ese sitio |
| Obligatorio para componentes expuestos en Teams | Sí | No es posible |
| Modelo de gobierno | Central: una decisión, auditada en un solo sitio | Distribuido: decide cada propietario de sitio |
La fila que más se lee mal es la cuarta. Un web part desplegado a todo el tenant está inerte hasta que se coloca. Eso es genuinamente distinto de una extensión desplegada a todo el tenant (un application customizer), que sí se ejecuta sola en las páginas — y esa diferencia es la razón por la que las extensiones merecen una revisión más estricta que los web parts.
Cuál elegir
Todo el tenant, cuando
- El componente está pensado para estar disponible en la organización, no en un departamento.
- No quieres un ticket cada vez que un sitio nuevo lo quiera, que es el desenlace normal de cualquier cosa que resulte útil.
- El paquete expone componentes en Microsoft Teams, en cuyo caso es obligatorio.
- Quieres un único registro auditable de lo desplegado en vez de un ejercicio de arqueología por sitios dentro de un año.
Sitio a sitio, cuando
- Estás pilotando con un departamento y quieres una frontera dura mientras evalúas.
- El componente es genuinamente específico de un sitio y en el selector de los demás solo sería ruido.
- Vuestro modelo de gobierno exige que cada propietario de sitio dé el alta explícitamente, y aceptáis el coste continuo de eso.
En la práctica, casi todas las organizaciones acaban en despliegue de tenant para cualquier cosa que funcione, porque la alternativa convierte a cada nuevo adoptante en una petición de soporte. Lo sensato es pilotar estrecho y decidir después, no quedarse en sitio a sitio de forma permanente para sentirse más seguro: la seguridad que compra es menor de lo que parece.
Cómo se controla un despliegue de tenant
Si desplegar a todo el tenant suena a perder el control, estas son las palancas que quedan — y son más de las que la gente espera:
- Permisos de sitio. Solo quien tiene permisos de edición en una página puede colocar un web part. Si no los das, no se puede añadir nada, esté desplegado lo que esté.
- El permiso de API. Un componente que necesita un permiso aprobado no hace nada útil hasta que lo apruebas — y quitar la aprobación lo desactiva en todas partes de golpe, sin tocar el paquete.
- La lista Tenant Wide Extensions del catálogo, para las extensiones en concreto: es donde se apaga una sin borrar nada.
- Retirar el paquete. Borrarlo del catálogo hace que deje de renderizarse en todas partes inmediatamente.
- El gobierno del propio proveedor, cuando existe. Algunos productos permiten desactivar un componente concreto de forma central, que es más fino que nada que ofrezca SharePoint.
Cambiar de idea después
Se puede. El alcance viene del manifiesto del paquete, así que cambiarlo significa que el proveedor publique una versión con otro skipFeatureDeployment y tú la subas. Pasar de sitio a sitio a todo el tenant es la dirección fácil; al revés deja las apps ya añadidas en los sitios, que hay que quitar una a una.
Esa asimetría es el argumento práctico para pilotar primero sitio a sitio si tienes dudas: la dirección barata es hacia fuera.
Preguntas frecuentes
¿Un web part desplegado a todo el tenant aparecerá en nuestras páginas existentes?
No. Queda disponible en el selector de web parts para quien edita páginas. Las páginas existentes no se tocan, y no se renderiza nada en ningún sitio hasta que alguien con permisos de edición lo añade a propósito a una página y la publica. Las extensiones se comportan de otra forma —esas sí se ejecutan automáticamente—, y por eso las dos cosas merecen niveles de escrutinio distintos.
¿Podemos desplegar a todo el tenant pero ocultarlo en la mayoría de sitios?
A través del despliegue, no: la disponibilidad es todo o nada. En la práctica se controla con permisos de sitio, ya que solo quien edita páginas puede colocar web parts. Si necesitáis aislamiento real por departamento, el despliegue sitio a sitio es el mecanismo que lo da, a cambio de administración continua.
¿Desplegar a todo el tenant ralentiza la carga de páginas?
En el caso de los web parts, no. El código solo se carga en las páginas donde el componente está realmente colocado. Las extensiones son otra vez la excepción: una extensión desplegada a todo el tenant se carga en todas las páginas de su alcance, así que el peso de su bundle sí es una pregunta legítima de rendimiento, cosa que en un web part no lo es.
¿Qué significa skipFeatureDeployment, literalmente?
Le dice a SharePoint que se salte el paso de activación de la característica por sitio. Cuando es true, la solución se despliega una vez y sus componentes están disponibles en todas partes sin instalación a nivel de sitio. Cuando es false, hay que añadir la app en cada sitio, lo que activa ahí la característica. La casilla del diálogo de subida es ese ajuste, enseñado al administrador.