HOJA DE CONTROL DEL DOCUMENTO
Documento |
|
Aprobado por |
| Fecha Aprobación |
|
Código documento |
|
Índice
Alcance
Entornos a instalar | |
Módulos afectados |
- Governance
- Rocket
- Discovery
- GoSec
|
Corte de servicio |
| Duración estimada del corte de servicio |
|
Servicios afectados |
|
Impacto de los cambios |
Proceso de instalación | | | |
Error en proceso de instalación | | | |
Marcha atrás | | | |
Participantes
| Ancla |
|---|
| Participantes |
|---|
| Participantes |
|---|
|
Participantes |
|
|---|
Departamento |
|
|---|
| Responsable |
|
|---|
Teléfono |
|
|---|
| Mail |
|
|---|
Rol |
|
|---|
Requisitos de instalación
Entornos
Entornos | Orden |
Preproducción | 1 |
Producción | 2 |
Entorno | Nombre | Capa | Roles de cada Servidor | Servicio (Aplicación) | Versión de los Servidores |
|
|
|
|
|
|
Ficha de entrega Software
| Ancla |
|---|
| FichaSoftware |
|---|
| FichaSoftware |
|---|
|
git checkout <entorno_destino>
git pull
git checkout <entorno_origen> <path1> <path2> ... <pathN>
git add .
git commit -m "<mensaje>"
git push
|
|---|
entorno_destino | entorno_origen | mensaje | path1 | path2 | pathN |
|
|
|
|
|
|
Checklist de requisitos
| Expandir |
|---|
|
| Expandir |
|---|
| - Se cumple con la estructura del activo (Colecciones/Reglas de calidad) establecida por la organización
- La base de datos en la que se basa la colección existe
- Se ha definido el propietario del dato
- Se ha definido el responsable del dato
- Los permisos de acceso y consumo han sido definidos y validados
- El nombre cumple con la normativa establecida por la organización
- Contiene los metadatos mínimos asociados
- El formato de los metadatos asociados cumple la normativa
- El campo de descripción del activo se encuentra completo
- Se ha comprobado que las colecciones utilizadas para el desarrollo existen en los entornos productivos
|
| Expandir |
|---|
| title | Gestión de metadatos |
|---|
| - El formato de los metadatos asociados sigue la normativa
- El campo de descripción se encuentra completo
- La sensibilidad de la información ha sido definida y validada
|
| Expandir |
|---|
| title | Gestión de reglas de calidad |
|---|
| - Se cumple con la estructura del activo (Colecciones/Reglas de calidad) establecida por la organización
- El nombre cumple con la normativa establecida por la organización
- Contiene los metadatos mínimos asociados
- El formato de los metadatos asociados sigue la normativa
- El campo de descripción del activo se encuentra completo
- Las reglas de calidad han sido aprobadas por el responsable correspondiente
- Se ha definido y validado el umbral necesario para las diferentes reglas de calidad
- Los resultados de los perfilados de datos son tratados correctamente
- La frecuencia de ejecución de las reglas de calidad ha sido definida y validada por el responsable correspondiente
|
| Expandir |
|---|
| title | Gestión de relaciones entre assets |
|---|
| - La tipología de relaciones utilizada está dentro de las establecidas por la organización
- La relación entre assets que se desea realizar está entre las recogidas por la organización
|
| Expandir |
|---|
| - Se cumple con la estructura del activo (Colecciones/Reglas de calidad) establecida por la organización
- Se ha definido el propietario del dato
- Se ha definido el administrador del dato
- Los permisos de acceso y consumo han sido definidos y validados
- El nombre cumple con la normativa establecida por la organización
- Contiene los metadatos mínimos asociados
- El formato de los metadatos asociados es el correcto
- El campo de descripción del activo se encuentra completo
- La tipología de activos de negocio utilizados se recogen en las acordadas por la organización
|
| Expandir |
|---|
| - Contiene los metadatos relacionados con la definición del linaje (transformación y origen)
- Las tipologías de relaciones establecidas para la definición de linaje cumplen con la normativa constituida
|
|
| Expandir |
|---|
|
- Los nombres de los assets cumplen con la normativa establecida por la organización
- Se ha evitado el uso de cajas PySpark y PySparkUDF
- Se ha definido el responsable del desarrollo
- Se ha definido el responsable del proceso de carga
- Contiene los metadatos mínimos asociados
- El formato de los metadatos asociados es el correcto
- Se han definido las relaciones con otros assets
- Los assets de los que depende existen y funcionan correctamente
- La fuentes de datos de las que se hacen uso están correctamente definidas
- Se siguen las buenas prácticas impuestas para la correcta gestión de proyectos y el correcto desarrollo de workflows
|
| Expandir |
|---|
|
- Los nombres de los DAGs cumplen con la normativa establecida por la organización
- Se han añadido en el script de python etiquetas que hacen referencia a los proyectos o desarrollos a los que pertenece el DAG
- Se ha almacenado el DAG en la carpeta "dags_sas" de Git, dentro de la subcarpeta correspondiente a su proyecto
- Se han almacenado las funciones a las que invoca el DAG en la carpeta "librería_sas" de Git, dentro de la subcarpeta correspondiente a su proyecto
- Se respetan las directrices recogidas en la normativa sobre la forma de hacer las llamadas a los flujos
- Se han añadido descripciones a los DAGs, a los grupos de tareas y a cada tarea en concreto
- Se han añadido parámetros a los DAGs y a sus tareas, y descripciones de esos parámetros
|
| Expandir |
|---|
|
- Los tamaños de los archivos parquets cumplen con el tamaño establecido en la normativa
- Se ha creado una subcarpeta para cada valor distinto de la columna de partición
- La columna de partición no contiene nulos y es equidistante
- La columna de partición elegida es técnicamente correcta
- Se han ingestado y curado aquellas tablas que requerían añadir alguna columna
- La tabla se ha almacenado donde corresponde según su cantidad de registros
- Las tablas ingestadas y/o curadas se han ubicado en la capa que corresponde según establece la normativa
- Las carpetas "…incremental" se han incluido en el backup de HDFS
|
| Expandir |
|---|
|
- Las particiones, índices y claves primarias son idénticos en Postgres y en Oracle
- Las tablas almacenadas en Postgres tienen menos de 5 millones de registros
- Las tablas son consistentes en todas las instancias
- Los nombres de las tablas, campos, secuencias, índices, constantes y esquemas siguen las pautas establecidas en la normativa
|
Manual de Instalación/Desinstalación
Instalación
Procesos de promoción
- Governance - Colecciones
- Implementar la promoción a través de Jenkins, dentro del proyecto Governance, mediante la opción Build with Parameters, estableciendo los parámetros necesarios.
- Governance - Resto asset
- Desde el entorno de origen ir a Opciones → Export y seleccionar el asset que se desea promocionar, estableciendo la configuración a exportar.
- Al exportarlo se descargará un archivo .zip que se debe importar en el entorno de destino. Dicha acción se realiza desde Opciones -> Import.
- Rocket
- Acceder a la opción Promote version dentro de la interfaz de edición del asset que se desea promocionar.
- Determinar los parámetros necesarios para la promoción: asset, version, dependencias y settings.
- Seleccionar promote para llevar a cabo la promoción.
Actualización de un asset existente.
En el caso en el que se requiera la actualización de un asset ya existente para posteriormente ser promocionado, los pasos a seguir serían los siguientes:
Actualización de asset en Governance
- Modificación del asset en el entorno de desarrollo con las actualizaciones pertinentes.
- Actualización del atributo atr_version con la versión correspondiente.
- Borrado del antiguo asset en el entorno de destino. Este borrado es necesario ya que si el asset a promocionar existe en el entorno destino, el proceso de promoción no contempla la sobreescritura de los Custom Attributes, por lo que estos serán duplicados.
- Promoción del asset actualizado a través de los pasos anteriormente citados en (1) o (2).
Actualización de assets de Rocket
- Creación de una nueva versión del asset a través de la opción Save → Save as new version.
- Promoción de la nueva versión del asset a través de los pasos anteriormente citados en (3).
Desinstalación
| Ancla |
|---|
| Desinstalacion |
|---|
| Desinstalacion |
|---|
|
En el caso de necesitar volver a una versión anterior tras la realización de una promoción, los pasos a seguir serían los que se detallan a continuación.
Restaurar versión anterior - Governance
- A través de Git y dentro del proyecto Governance, se encuentran los diferentes assets existentes en cada uno de los entornos, así como el histórico de cambios.
- Se debe acceder al entorno deseado y restaurar la versión que se requiera.
Restaurar versión anterior - Rocket
- Acceder al menú Admin Proyect - Backups y restaurar la versión a la que se requiera volver.