Puntos clave
- El patrón preferido sigue siendo una configuración parametrizada de OneLake y Direct Lake.
- Las regresiones activas pueden exigir URLs literales como control, etiquetadas como temporales.
- Publica validadores junto a los parches para que Test falle antes que Prod.
- Mantén bajo el apaño un playbook de promoción de Test a Preprod y a Prod.
- Guarda la documentación del caso de soporte junto a la convención en Git.
- Dale a cada apaño un responsable y una fecha de revisión; retirarlo es una tarea con seguimiento.
Las expresiones de DataLake parametrizadas pueden funcionar durante meses y luego fallar en todas las etapas de un día para otro. Los equipos reescriben a toda prisa sus documentos de convenciones como si las URLs literales de OneLake hubieran sido siempre el objetivo de diseño. Eso borra la historia y garantiza que el apaño se convierta en religión.
Replantea los fallos "literal URL required" como regresiones del servicio. Publica validadores y parches literales como controles temporales. Mantén bajo el apaño un plan de promoción de Test a Preprod y a Prod. Abre el caso de soporte con Microsoft y haz su seguimiento junto a la convención del repo. No finjas que la plataforma siempre quiso URLs fijas en el código.
Modelo con nombre: control temporal, no dogma
- Intención preferida: la configuración parametrizada de OneLake y Direct Lake sigue siendo el objetivo de diseño, documentada como estado deseado.
- Control temporal: parches con URLs literales etiquetados como temporales, acompañados de validadores por etapa y de un playbook de promoción explícito.
- Camino de vuelta: documentación del caso de soporte en Git, un responsable, una fecha de revisión y un plan de retirada etapa por etapa cuando el caso lo permita.
- Contrato: un apaño para una regresión no es un principio de arquitectura hasta que tú lo decidas, por escrito, una vez resuelto o aceptado el bug.
Figura 1. Control temporal, no dogma. Mantén la intención parametrizada en la documentación. Los parches literales desbloquean; no reescriben el estándar.
Contexto y restricción
Un fallo habitual: pipelines de promoción que eran aburridos de repente exigen rutas literales. La tentación es reescribir todos los estándares como "usa siempre literales". Es mejor tener validadores, un playbook de promoción por etapas y un caso de soporte que mantenga viva la intención parametrizada a largo plazo.
Los parches literales temporales pueden desbloquear Prod. Un dogma permanente sin rastro de soporte ni fecha de revisión se convierte en deuda impagada. Los validadores detectan pronto ese modo de fallo. La promoción sigue necesitando un plan explícito por etapa. Las convenciones del repo deberían etiquetar los apaños como apaños.
La figura 2 es la pantalla de Learn para conectar un modelo de Direct Lake con el almacenamiento. El patrón previsto es Direct Lake sobre OneLake. Los parches con URLs literales son controles para cuando los parámetros tienen regresiones, no la historia de la arquitectura.
Figura 2. Direct Lake on OneLake es el patrón previsto. Los parches con URLs literales son controles para cuando los parámetros tienen regresiones. Fuente: Microsoft Learn: Direct Lake storage.
Diseño
1. Llama regresión al fallo en el ticket
Escribe qué funcionaba antes, qué falló, en qué etapas y con qué texto de error. Evita poner "OneLake requiere literales" como título si los parámetros funcionaban el mes pasado. Nombrar con precisión lleva a correcciones precisas.
2. Publica validadores junto a los parches
Automatiza comprobaciones que hagan fallar el pipeline cuando las expresiones parametrizadas se rompan en una etapa. Los validadores convierten roturas sorpresa en Prod en fallos en Test. Combínalos con el parche literal para que operaciones sepa cuándo sigue haciendo falta el parche.
3. Mantén la intención parametrizada en la documentación
Documenta el patrón preferido (parámetros y variables) y el control literal temporal. Si solo documentas los literales, los recién llegados los grabarán en piedra. La documentación doble es honesta: estado deseado frente a control actual.
4. Escribe el playbook de promoción bajo el apaño
Test, Preprod y Prod pueden necesitar valores literales distintos mientras dure la regresión. Detalla los pasos: dónde se parchea, quién aprueba, cómo se verifica Direct Lake después de promover. No dependas de la memoria de un solo ingeniero durante una promoción en viernes.
La figura 3 es la pareja que evita que la siguiente etapa se invente un ritual propio.
Figura 3. Validadores junto a parches literales. Un parche sin validador es la forma en que Preprod y Prod se inventan cada uno el mismo simulacro de incendio.
5. Guarda el rastro de soporte junto al repo
Guarda los números de caso, los correos clave y las notas de reproducción en la misma carpeta que el documento de convenciones. Cuando el servicio corrija la regresión, necesitarás un camino de vuelta. Sin rastro, nadie se atreverá a quitar los literales.
6. Programa una revisión
Pon una fecha o una nota de "revisar cuando se cierre el caso" en el apaño. Los apaños caducados sin responsable son la forma en que lo temporal se vuelve eterno. Pon la revisión en el calendario como harías con la caducidad de un certificado.
Qué contar a los stakeholders
Di: las rutas parametrizadas de OneLake siguen siendo el diseño previsto; una regresión de la plataforma obliga a usar literales en estas etapas; estamos validando, parcheando, promoviendo con un playbook y haciendo seguimiento con soporte; quitaremos los literales cuando el caso lo permita. Ese relato protege los estándares mejor que fingir que elegiste fijar valores por pureza. Los stakeholders pueden aceptar una fealdad temporal. La confusión permanente la huelen.
Coordinar SemPy y las ediciones en el portal
Las regresiones suelen manifestarse de forma distinta en las acciones del portal y en los scripts de SemPy. Inventaría todas las rutas que establecen expresiones de DataLake u OneLake. Aplica la misma política de apaño a cada ruta. Las herramientas con el cerebro dividido son la forma en que Test parece arreglado mientras la automatización vuelve a introducir parámetros en la siguiente ejecución. Una política, muchos puntos de entrada, validadores compartidos.
La figura 4 es el contrato de coordinación, y el playbook inverso para cuando soporte confirme la corrección.
Figura 4. Una política para el portal y SemPy. Cuando se cierre el caso, reactiva primero los parámetros en Test y quita los literales etapa por etapa.
Cómo retirar el apaño sin dramas
Cuando soporte confirme la corrección, reactiva primero los parámetros en Test. Ejecuta los validadores esperando que los parámetros funcionen. Promueve con el mismo playbook a la inversa: quita los literales etapa por etapa. Archiva las notas del caso. Celebra la retirada en el mismo canal donde se anunció el apaño, para que el equipo aprenda que temporal significaba temporal.
No dejes que los ejemplos de SemPy se conviertan en el nuevo estándar
Los notebooks de ejemplo que fijan literales para desbloquear un post de blog o un ejemplo interno acabarán copiados en Prod. Marca los ejemplos con una cabecera WARNING cuando muestren un apaño. Mejor aún: que los ejemplos muestren parámetros y que un fragmento aparte de "control de regresión" muestre los literales con un enlace al ADR. La cultura de copiar y pegar seguirá todo lo que dejes sin marcar.
Errores comunes
Reescritura dogmática. Las convenciones fingen que los literales siempre fueron obligatorios.
Parche sin validador. La siguiente etapa se rompe de la misma manera.
Sin plan de promoción. Cada entorno se inventa un ritual.
Soporte como conocimiento tribal. El id del caso vive en una sola bandeja de entrada.
Sin revisión. Los controles temporales sobreviven al bug durante años.
Deriva silenciosa en SemPy o en scripts. Una herramienta sigue con parámetros, otra con literales; caos.
Úsalo tal cual o adáptalo
Úsalo tal cual
- El patrón preferido sigue siendo una configuración parametrizada de OneLake y Direct Lake.
- Las regresiones activas pueden exigir URLs literales como control, etiquetadas como temporales.
- Los validadores detectan el modo de fallo en cada etapa antes de Prod.
- Los playbooks de promoción cubren los parches literales en Test, Preprod y Prod.
- La documentación del caso de soporte vive junto a la convención en Git.
- Los apaños tienen responsable y fecha de revisión; retirarlos es una tarea con seguimiento cuando se corrija el fallo.
Adáptalo antes de usarlo
Los parches literales son feos y dependen de cada entorno. Las promociones fallidas son más feas. Mantener documentación doble (estado deseado frente a apaño) cuesta atención; una documentación única que miente cuesta más. Los casos de soporte llevan tiempo; sin ellos nunca obtienes permiso para revertir. Los validadores suman minutos de CI y salvan fines de semana.
Referencias principales: Direct Lake overview y Direct Lake storage en Microsoft Learn, además de tus notas internas de soporte. Combina la documentación del producto con el ADR del apaño para que los ingenieros sepan en qué realidad están trabajando.
Parchea para sobrevivir. Valida para detectar. Promueve con un playbook. Haz seguimiento con soporte. Revisa a propósito. Las URLs literales de OneLake pueden ser un control. No deberían convertirse por accidente en la historia de tu arquitectura.