En esta página, se explica cómo usar un flujo de trabajo de CI/CD de varios niveles en Looker después de que se instaló y configuró dicho flujo de trabajo.
En estas instrucciones, se usa un sistema de tres niveles que incluye desarrollo, QA y producción. Sin embargo, puedes aplicar los mismos principios a un sistema de dos o cuatro niveles.
En estas instrucciones, también se supone que usas GitHub como tu proveedor de Git. Puedes usar otros proveedores de Git para crear un flujo de trabajo de CI/CD. Sin embargo, debes tener la experiencia necesaria para modificar estas instrucciones según tu proveedor.
Descripción general del flujo de trabajo
Los desarrolladores de LookML comienzan escribiendo código en su rama de desarrollo, que normalmente se llama algo como dev-my-user-ydnv, prueban sus cambios con la integración continua de Looker (o ejecutando manualmente un conjunto de pruebas de CI) y confirman su código. Por último, abren una solicitud de extracción para combinar su código con la rama main.
Cuando se abre la solicitud de extracción, se dirige al desarrollador a GitHub. El desarrollador debe escribir un título significativo para la solicitud de extracción con el estilo de confirmaciones convencionales y agregar un comentario a la descripción que se incluirá en el registro de cambios. Si se configura el activador de solicitudes de extracción, la integración continua de Looker valida automáticamente la solicitud de extracción, y los desarrolladores pueden ver los resultados en Looker o en GitHub.
A continuación, el desarrollador debe seleccionar un revisor en GitHub. El revisor recibirá una notificación y podrá agregar su revisión a la PR. Si el revisor aprueba el cambio, la PR se combina con la rama main. Se llama a un webhook y el entorno de desarrollo ahora ve el cambio.
Automáticamente, se ejecutará la automatización de Release Please y se abrirá una segunda solicitud de extracción para crear una nueva versión etiquetada. O bien, si ya hay una PR abierta para este propósito, Release Please la actualiza. La RP de la versión tiene un número de versión asociado, así como un registro de cambios que incluye los títulos y las descripciones de los cambios incluidos.
Cuando se aprueba y se combina la PR generada por Release Please, se genera una nueva etiqueta de versión y el registro de cambios se combina con la rama main. Las instancias de QA y producción de Looker pueden seleccionar esta versión con el Modo de implementación avanzado.
Prácticas recomendadas para numerar versiones y nombrar confirmaciones
Las versiones y sus etiquetas asociadas se pueden nombrar y numerar de cualquier manera que tenga sentido en tu entorno. Sin embargo, aquí se usa el control de versiones semántico, que se recomienda mucho porque funciona bien con el complemento Release Please.
En el control de versiones semántico, la versión consta de tres números separados por puntos: MAJOR.MINOR.PATCH
PATCHse incrementa cada vez que una versión corrige un error.MINORse incrementa yPATCHse restablece a cero cada vez que la versión agrega o perfecciona una función y, al mismo tiempo, es retrocompatible.MAJORse incrementa yMINORyPATCHse establecen en cero cuando se agrega una función que no es retrocompatible.
Conventional Commits es un sistema para nombrar las confirmaciones según el impacto que tienen en los usuarios finales. Si bien no es obligatorio, el uso de nombres de confirmación convencionales también es útil para el complemento de Release Please.
En la nomenclatura de confirmaciones convencional, cada mensaje de confirmación se antepone con un indicador del alcance del cambio:
- Las correcciones de errores se indican con
fix:, comofix: set proper currency symbol on sale_amt format. - Las funciones nuevas se indican con
feat:, comofeat: added explore for sales by territory. - Las funciones con un cambio que genera interrupciones se indican con
feat!:, comofeat!: rewrote sales explore to use the new calendar view. - Cuando se actualiza la documentación, pero no se cambia LookML, el mensaje de confirmación comienza con
doc:.
Si los commits convencionales se usan de forma coherente, determinar el número semántico que se usará a continuación suele ser sencillo. Si el registro de confirmaciones solo consta de confirmaciones de fix: y doc:, se debe incrementar el valor de PATCH. Si hay una confirmación de feat:, se debe incrementar MINOR. Si hay un feat!:, se debe incrementar MAJOR. El complemento Release Please incluso puede generar un archivo CHANGELOG y etiquetar la versión automáticamente.
Cómo usar el modo de implementación avanzada
Después de que se realicen los cambios y se envíen como una PR en la instancia de desarrollo, el complemento Release Please etiquetará los cambios con una etiqueta de versión como v1.2.3. Luego, el modo de implementación avanzado de Looker hace que estas versiones estén disponibles en la IU de Looker para las instancias de QA y producción.
Para implementar un cambio, elige el Administrador de implementaciones en el IDE de Looker:
Haz clic en el vínculo Select Commit en la parte superior derecha del Administrador de implementaciones. A continuación, selecciona el menú de tres puntos asociado con la etiqueta que deseas implementar y elige Implementar en el entorno:
No es necesario que vuelvas a etiquetar la implementación, así que elige Implementar sin etiquetar y presiona el botón Implementar en el entorno:
Por último, envía a producción con Deployment Manager.
Usa la integración continua de Looker
Para verificar los cambios en una rama de desarrollo o como parte de una solicitud de extracción, los desarrolladores pueden usar la integración continua de Looker. La integración continua proporciona los siguientes validadores:
- Validador de SQL: Verifica que las dimensiones de tus Exploraciones se ejecuten correctamente en tu base de datos.
- Assert Validator: Ejecuta todas las pruebas de datos de LookML que crearon tus desarrolladores de Looker y devuelve todos los errores y las fallas.
- Validador de contenido: Ejecuta la validación de contenido de Looker para detectar errores en las vistas y los paneles de tu proyecto de LookML.
- Validador de LookML: Ejecuta el Validador de LookML para detectar errores de LookML en el proyecto.
- Validador de estilo: Aplica los estándares de codificación de LookML, las convenciones de nomenclatura y las prácticas recomendadas estructurales en todo tu proyecto.
Puedes agrupar estos validadores en paquetes de integración continua y ejecutarlos automáticamente en solicitudes de extracción, según un programa o de forma manual.
Validador de SQL
El validador de SQL de integración continua verifica que las dimensiones de tus Explorar se ejecuten correctamente en tu base de datos. Comprueba si los campos definidos en las vistas de LookML corresponden a columnas o expresiones de SQL válidas en la base de datos.
El validador de SQL tiene las siguientes capacidades clave:
- Ejecuta consultas con cláusulas
LIMIT 0yWHERE 1=2para validar el código SQL sin incurrir en costos de análisis de datos. - Admite la validación incremental para probar solo los Explorar que cambiaron en la rama de desarrollo.
- La validación de permisos se limita a Explores específicos para consultar o excluir.
- Excluye dimensiones específicas de la validación con etiquetas de LookML o comentarios en SQL (
tags: ["ci: ignore"]o-- ci: ignore).
Para obtener más información y opciones de configuración, consulta la página de documentación del Validador de SQL de integración continua.
Validador de LookML
El validador de LookML de integración continua verifica si hay errores de sintaxis en tu proyecto de LookML, como corchetes faltantes o referencias de campos no válidas. Este validador es especialmente útil para los desarrolladores que escriben LookML fuera del IDE de Looker.
El validador de LookML tiene las siguientes capacidades clave:
- Te permite establecer un umbral de gravedad (Error, Advertencia o Información) que determina qué nivel de gravedad del mensaje provoca que falle una ejecución.
- Te permite configurar una duración de tiempo de espera para las ejecuciones de validación.
Para obtener más información y opciones de configuración, consulta la página de documentación del Validador de LookML de integración continua.
Validador de contenido
El Validador de contenido de integración continua verifica que el contenido guardado, como las Looks y los paneles definidos por el usuario (UDD), siga funcionando correctamente después de que se realicen cambios en LookML.
El Validador de contenido tiene las siguientes capacidades clave:
- Validación de permisos para carpetas de contenido específicas o Explores
- Se excluye el contenido de las carpetas personales.
- Admite la validación incremental para encontrar errores que son únicos en la rama de desarrollo.
Para obtener más información y opciones de configuración, consulta la página de documentación del Validador de contenido de integración continua.
Validador de aserciones
El validador de aserciones de integración continua ejecuta pruebas de datos de LookML que se definen en tu proyecto para verificar la lógica del modelo y la integridad de los datos.
Por ejemplo, una prueba de datos de LookML podría verse de la siguiente manera:
test: historic_revenue_is_accurate {
explore_source: orders {
column: total_revenue { field: orders.total_revenue }
filters: [orders.created_date: "2024"]
}
assert: revenue_is_expected_value {
expression: ${orders.total_revenue} = 626000 ;;
}
}
El validador de aserciones tiene las siguientes capacidades clave:
- Los alcances afirman la validación en Explores específicos para consultar o excluir.
- Te permite configurar la concurrencia de consultas para administrar la carga de la base de datos.
Para obtener más información y opciones de configuración, consulta la página de documentación del validador de aserciones de integración continua.
Administración y ejecución de paquetes de CI
Para administrar y ejecutar pruebas de integración continua, sigue estos pasos:
- Crea conjuntos de pruebas: Configura qué validadores ejecutar y establece sus opciones en la página Suites en el IDE de Looker. Para obtener más información, consulta la página de documentación Cómo crear un conjunto de pruebas de integración continua.
- Ejecuciones de activación: Activa ejecuciones de validación automáticamente en solicitudes de extracción, según una programación o manualmente para una rama de desarrollo o producción. Para obtener más información, consulta la página de documentación Cómo ejecutar conjuntos de pruebas de integración continua.
- Ver resultados: Revisa los mensajes de error, las líneas de LookML afectadas y los vínculos a Explorar y a los paneles en la página de resultados de la ejecución de CI. Para obtener más información, consulta la página de documentación Cómo ver los resultados de una ejecución de CI.
Estabilidad de los vínculos para las Vistas y los paneles
De forma predeterminada, las vistas y los paneles reciben IDs numéricos ascendentes que se usan en la URL de la vista o el panel. Sin embargo, no hay forma de mantenerlos sincronizados en todos los sistemas. Por lo tanto, la URL de un panel específico en desarrollo no apuntará al mismo panel en QA o producción.
En el caso de los UDD, existe la opción de usar un slug en lugar de un ID como parte de la URL. El slug es un conjunto de caracteres semi aleatorio en lugar de un número. El slug se puede establecer como parte de la importación, de modo que una URL similar pueda apuntar al mismo UDD en el desarrollo, el control de calidad y la producción. Usar slugs en lugar de IDs es una práctica recomendada, en especial cuando se hace clic para acceder a una UDD desde Look o desde otra UDD.
Puedes encontrar el slug si inspeccionas el resultado de gzr dashboard cat. El slug se puede usar en la URL del panel en lugar del ID numérico.
Migra contenido del usuario con Gazer
A menudo, es útil copiar contenido, como Looks y paneles, entre los entornos de desarrollo, QA y producción. Es posible que desees producir contenido que muestre las nuevas incorporaciones de LookML o verificar que el contenido guardado siga funcionando correctamente después de los cambios en LookML. En estas situaciones, se puede usar Gazer para copiar contenido entre instancias.
Paneles de LookML
Los paneles de LookML se sincronizan entre las instancias durante el flujo de trabajo habitual de CI/CD de LookML. Sin embargo, si alguna UDD está sincronizada con los paneles de LookML, se puede actualizar con Gazer usando el siguiente comando:
gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL
Paneles definidos por el usuario
Los paneles definidos por el usuario (UDD) se pueden migrar con Gazer haciendo referencia al ID del panel y a la URL de la instancia de Looker en la que reside el UDD. Gazer guarda la configuración del panel en un archivo JSON que luego se importa a la instancia de Looker de destino.
El comando para extraer la configuración de UDD es el siguiente:
gzr dashboard cat DASHBOARD_ID --host TARGET_SYSTEM_URL --dir .
Esto generará un archivo llamado Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json que contiene la configuración del panel.
El UDD se puede importar al sistema de destino con el siguiente comando:
gzr dashboard import Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json FOLDER_ID \
--host TARGET_SYSTEM_URL
Vistas
La migración de aspecto funciona de manera muy similar a la migración de UDD. Primero, usa Gazer para guardar la configuración de Look en un archivo JSON:
gzr look cat LOOK_ID --host SOURCE_SYSTEM_URL --dir .
Luego, importa el Look a la instancia de destino:
gzr look import Look_LOOK_ID_LOOK_NAME.json FOLDER_ID \
--host TARGET_SYSTEM_URL