Variable Library: ¿cómo cambias los conjuntos de valores activos de dev a prod?

Los IDs de workspace fijos en los notebooks son la forma en que Test reasigna Prod por accidente. Los "mapas de entornos" en una hoja de cálculo del chat son la forma en que dos equipos mantienen dos verdades distintas. Fabric ya trae un sitio mejor: una Variable Library en Git con value sets por etapa.

Pon los valores de Test, Preprod y Prod en el elemento. Enseña a los notebooks de reasignación a leerlos mediante API compatibles. Separa de forma explícita los workspaces de plataforma y de dominio. Respeta el esquema de Git para que las restauraciones funcionen. Acompaña la library con un plan de promoción para cuando los parámetros del portal tengan regresiones.

Figura 1. Una Variable Library en Git guarda los value sets por etapa. La automatización resuelve los destinos a partir del mapa. Los pósits y las hojas de cálculo del chat no escalan hasta Prod.

Contexto y restricción

Un fallo habitual: los notebooks de reasignación acumulan constantes de GUID "solo por ahora". Ese ahora dura tres etapas y un susto serio. La Variable Library está disponible. Los equipos siguen actuando como si los pósits escalaran.

Los value sets por etapa van en la Variable Library. La automatización de reasignación y despliegue debería resolver los IDs de workspace, los IDs de lakehouse y los nombres de conexión a partir de ese mapa. Los workspaces de plataforma y de dominio necesitan filas explícitas para que la gente deje de adivinar. Un JSON editado a mano que viola el esquema del elemento hace fallar las restauraciones y te cuesta un día. Cuando los parámetros del portal tengan regresiones, ten un apaño documentado para la promoción junto a la library, no en su lugar.

La figura 2 es la pantalla de Learn para definir valores en una Variable Library. En el portal cuidas los conjuntos; en Git la verdad tiene que mantenerse honesta.

Figura 2. La promoción es más segura cuando los destinos de workspace salen de un mapa en la Variable Library y no de GUID pegados. Fuente: Microsoft Learn: Variable Library overview.

Diseño

1. Una library, value sets por etapa

Mantén variables para los identificadores que necesita la automatización: workspaces, lakehouses, warehouses y nombres de conexión principales. Rellena los value sets de Test, Preprod y Prod. Resiste la tentación de un cuarto conjunto informal de "dev en mi portátil" que nunca se cuida. Puede haber sobrescrituras locales; no deberían bifurcar el mapa.

2. Reasigna con lecturas compatibles, no con GUID pegados

Los notebooks y pipelines que reasignan deberían obtener los valores con los mecanismos compatibles de la Variable Library o con helpers aprobados de la plataforma. Pegar GUID en celdas recrea el pósit con mejor resaltado de sintaxis. La revisión de código debería rechazar los nuevos IDs de workspace fijos igual que rechaza los secretos. La figura 3 es esa bifurcación.

Figura 3. Los GUID pegados recrean la arqueología. Las lecturas compatibles de la library evitan que Test reasigne Prod por accidente.

En mi demo, demo_varlib tiene un value set por defecto y los conjuntos de Test, Preprod y Prod, con Test activo. Una sola llamada a notebookutils.variableLibrary en un notebook resuelve target_lakehouse como demo_lakehouse_test y batch_size como 1000. La celda nombra la library, nunca un valor de una etapa (figura 4).

Figura 4. Una library, value sets por etapa y una lectura desde el notebook. Con Test activo, la celda resuelve los valores de Test sin ningún valor de etapa en el código.

3. Separa en el mapa los workspaces de plataforma y de dominio

Las capacidades compartidas de plataforma y los workspaces de proyectos de dominio aparecen ambos, etiquetados. Operaciones debería ver qué destinos son infraestructura compartida y cuáles son de un equipo. Los nombres ambiguos provocan reasignaciones que "salen bien" en el workspace equivocado. La figura 5 también marca la línea de los secretos.

Figura 5. Etiqueta las filas de plataforma y de dominio con su responsable. La topología vive en la Variable Library. Los secretos se quedan en Key Vault.

4. Trata el esquema de Git como ley

La Variable Library en Git tiene una forma. Editarla a mano sin validar contra esa forma rompe la sincronización y la restauración. Para los cambios estructurales, mejor el portal o herramientas compatibles; si tienes que editar a mano, valida. Aquí, un historial de Git roto es una clase de caída, no una cuestión de estilo.

5. Acompáñala con playbooks de promoción

Cuando los parámetros del portal o los enlaces de Direct Lake tengan regresiones entre etapas, documenta los controles temporales junto a la library. No abandones el mapa porque una ruta de promoción tenga errores. Los apaños sin mapa se convierten en conocimiento tribal permanente.

6. Haz que el mapa se pueda encontrar

Enlaza la library desde el README de la plataforma y desde los runbooks de reasignación. Los ingenieros nuevos deberían encontrar el mapa en minutos. Si solo dos personas conocen el nombre del elemento, sigues teniendo un pósit, solo que con permisos.

Qué va en la library y qué en Key Vault

La Variable Library es para la topología no secreta de los entornos: IDs, nombres y endpoints que no son credenciales. Los secretos se quedan en Key Vault o equivalente. Mezclar secretos en la library enseña el patrón equivocado y complica Git. Si un valor es sensible, no es un valor de la Variable Library. Si un valor es un GUID de workspace, es exactamente un valor de la Variable Library. Marca esa línea en el ADR para que los ingenieros bienintencionados dejen de "proteger" la topología escondiéndola en notas personales.

Operar el mapa entre equipos

Da a los ingenieros de plataforma la responsabilidad de las filas compartidas. Da a los equipos de dominio la responsabilidad de las filas de sus workspaces, con revisión. Los cambios en los value sets de Prod deberían pasar el mismo escrutinio que los cambios en los pipelines. Editar a la ligera un ID de Prod es un incidente de producción con mejores modales. Revisa los diffs de los value sets en los PR cuando haya conexión con Git. Cuando se edite en el portal, exporta o sincroniza enseguida para que Git no mienta.

Prueba de humo de las reasignaciones en Test cada vez que cambia el mapa

Cuando alguien edite un id de workspace, ejecuta el notebook de reasignación (o una comprobación en seco) en Test contra el nuevo mapa antes de tocar Preprod. Los cambios en el mapa sin prueba de humo son la forma en que las erratas se convierten en caídas. Si puedes, automatiza en CI una comprobación de "resolver todas las claves necesarias"; si no, conviértela en un punto obligatorio de la checklist del PR.

Errores comunes

Arqueología de GUID en los notebooks. Entornos a base de copiar y pegar. Test reasigna Prod.

Hojas de cálculo del chat como fuente de verdad. Deriva mensaje a mensaje. Dos equipos, dos mapas.

Un único bloque de variables con conjuntos por etapa poco claros. Etapa equivocada, despliegue muy seguro de sí mismo.

JSON de Git roto a mano. La restauración falla justo cuando la necesitas.

Abandonar la library tras un error del portal. Vuelve el folclore. Los apaños se convierten en el sistema.

Destinos de plataforma y de dominio sin etiquetar. Reasignación correcta al sitio equivocado.

Úsalo tal cual o adáptalo

Úsalo tal cual

• La Variable Library de Fabric como mapa de entornos para los identificadores de workspaces y lakehouses en todas las etapas.
• Automatización de reasignación y despliegue que lee la library; GUID fijos por etapa prohibidos en código nuevo.
• Workspaces de plataforma y de dominio como filas explícitas con responsable.
• Validación del esquema de Git para los cambios en la library.
• Los secretos nunca en la Variable Library; la topología sí va ahí.
• Las regresiones en la promoción reciben playbooks que acompañan a la library, no que la sustituyen.

Adáptalo antes de usarlo

Los mapas centrales crean un punto de coordinación. Los GUID dispersos crean escrituras silenciosas entre entornos. Una higiene estricta de Git frena las ediciones a la ligera; las ediciones a la ligera rompen las restauraciones. Leer variables en la automatización añade unas pocas líneas de código y elimina toda una clase de errores. Los apaños de promoción añaden documentación; los apaños sin documentar añaden caídas.

Pruébalo tú mismo

La Variable Library targets demo de mi repo público tech-demos crea una library con value sets de Test, Preprod y Prod y un notebook que la lee, para que puedas cambiar el conjunto activo y ver cómo cambian los valores sin tocar el código.

Referencias principales: Fabric Variable Library y la documentación de deployment pipelines en Microsoft Learn. Combínalas con tu runbook de reasignación para que el mapa se use y no solo se admire.

Pon el mapa en la Variable Library. Léelo desde la automatización. Mantén Git honesto. Separa plataforma de dominio. Cuando la promoción se porte mal, documenta el apaño junto al mapa. Los pósits no escalan hasta Prod.

Relacionado

• Direct Lake on OneLake: ¿merece la pena el esfuerzo? (cuando un ajuste literal temporal tiene que convivir con el mapa)