Instructivo Data Ops

INSTRUCTIVO GENERACIÓN DE INFRAESTRUCTURA Y PIPELINES EN DATAOPS
GESTIÓN DE INFORMACIÓN
VICEPRESIDENCIA DIGITAL
CÓDIGO Elaborado Versión:
G-01 03/06/2021 1
1. GLOSARIO
Término Traducción/Definición
ARM Templates Documentos en formato JSON que definen la infraestructura y la configuración de diversos
recursos en los proyectos.
Azure CLI Interfaz de Línea de Comandos que permite crear y manejar recursos de Azure.
Azure DevOps Herramienta que permite llevar a cabo la gestión del ciclo de vida de desarrollo de aplicaciones.
Azure Pipelines Es un término en inglés que se refiere a una tubería informática, es generada con los pasos de
tareas específicas que se crean como una automatización.
Cloning Generar una copia local de un repositorio.
Data Factory Servicio en la nube de Azure creado para procesos de extracción, transformación y carga (ETL) y
de integración de datos.
DataOps Metodología automatizada utilizada por equipos de analítica para mejorar la calidad y reducir el
tiempo de ciclo de análisis de datos.
Despliegue Continuo (Continuous Delivery por sus siglas en inglés) Vendría a ser el siguiente paso luego de la
(CD) integración continua, consiste en liberar de forma automática una nueva versión del producto
que se está desarrollando.
Forking Desarrollar un proyecto tomando como base una plantilla, proyecto o repositorio ya existente.
Infraestructura como El proceso de utilizar archivos de configuración (código) para la definición y aprovisionamiento de
Código (IaC) la infraestructura, en lugar de realizar la configuración manualmente.
Integración continua (Continuous Integration por sus siglas en inglés) Es una práctica de ingeniería de software con la
(CI) que los desarrolladores pueden combinar los cambios realizados en el código de un proyecto de
manera periódica, en un repositorio central y agregando estándares de calidad y seguridad.
Git Git es un sistema distribuido de control de versiones para código fuente. Mediante esta
herramienta se puede hacer seguimiento a los cambios y realizar una colaboración más
organizada por parte de los desarrolladores.
Nube La tecnología de Nube (Cloud Computing) es un tipo de arquitectura informática que permite
almacenar y acceder a datos y programas a través de Internet en lugar del disco duro de nuestra
computadora. También es conocida como Servicios en la Nube, Nube de Cómputo, Informática
en la Nube o simplemente “La Nube”.
Pipeline Conjunto de procesos automatizados y de tareas que se ejecutan secuencialmente para obtener
un resultado deseado.
Powershell Es una Interfaz de Línea de Comandos (CLI) de Microsoft que permite automatizar tareas y realizar
configuración de recursos.
Seguimiento El seguimiento es un análisis sistemático de todos los procesos en su conjunto con el fin de evaluar
un resultado.
Synapse Es un servicio de Analítica de Azure que permite la integración de diversas fuentes de datos para
realizar consultas de Inteligencia de Negocios.
1
G-01 03/06/2021 1
2. OBJETIVO
El Objetivo de este documento es presentar el Instructivo para la realización de cualquier proyecto que utilice DataOps.
Se presentarán recomendaciones de buenas prácticas de ingeniería para la realización de estos proyectos, así como un
paso a paso para realizar un nuevo proyecto a partir de una plantilla ya existente.
3. CONDICIONES GENERALES
Para que un proyecto pueda realmente cumplir con las prácticas de DevOps, se deben cumplir algunos estándares que
garanticen la calidad y la estabilidad de todo el proceso de desarrollo y paso a producción. En el caso de los proyectos de
DataOps, se busca que estos cumplan con un modelo de prácticas que permita un despliegue rápido y automatizado
acorde con sus necesidades. Estas prácticas están divididas en 3 fases. Cada una de estas fases será realizada por un
equipo diferente:
• En la primera fase, el equipo de cloud realizará la creación y configuración inicial de los recursos en la nube.
• En la segunda fase, el equipo de DevOps creará el repositorio y el pipeline en Azure DevOps.
• En la tercera fase, el equipo encargado del proyecto ejecutará los pipelines y continuará el desarrollo del proyecto.
En la siguiente imagen se puede apreciar la división de responsabilidades entre los equipos.
Imagen 1: Descripción general del instructivo
Los scripts y archivos de configuración se encuentran en el siguiente repositorio:
2
G-01 03/06/2021 1
https://dev.azure.com/ecopetrolad/AzureVirtualDatacenter/_git/AzureVirtualDatacenterPS1?path=%2FREADME.md&_
a=preview
A este repositorio sólo tiene acceso el equipo de Plataformas de la operación de la VDI de Ecopetrol.
4. INSTRUCTIVO CLOUD
Para el instructivo de cloud el Pipeline de Despliegue Deploy-AzureProject.CD crea y despliega Grupos de Seguridad,
Grupos de Recursos, Service Principals y Service Connections para los diversos ambientes de Azure.
Las acciones descritas en este numeral las debe ejecutar el equipo de la Plataformas de la Operación de la VDI.
4.1 Creación de Archivo de Configuración
Este paso consiste en la creación de un archivo de tipo JSON en el que se especificarán los detalles de los recursos. Primero,
es necesario clonar el repositorio
https://dev.azure.com/ecopetrolad/AzureVirtualDatacenter/_git/AzureVirtualDatacenterPS1?path=%2F&version=GBma
in
Después, Crear un nuevo archivo de configuración JSON en el directorio “configs/cloud-

setup” (ejemplo: <DOMAIN_NAME>.json), basado en el archivo de template “template.json” para no tener que crear
todas las propiedades desde cero.
Imagen 2: Directorios con los archivos de configuración basados en template.json
Nota: Si el proyecto es un proyecto de migración, es necesario elegir el alias correctamente para ser el mismo que será
utilizado para el storage account.
3
G-01 03/06/2021 1
Después de crear el archivo en el directorio, es necesario:
1. Crear una nueva rama Git (ejemplo: git checkout -b <BRANCH_NAME>)

2. Crear un commit (ejemplo: git commit -m "<DOMAIN_NAME> cloud setup config file")
3. Hacer el git push (ejemplo: git push -u origin <BRANCH_NAME>).
4. Abrir el Azure DevOps y crear un Pull Request, agregando un ID de una tarea y personas para revisar el
archivo y aprobar el merge.
4.2 Ejecutar el CD pipeline de Cloud Setup
• En Azure DevOps, ir en la sección Pipelines y seleccionar el pipeline Deploy-AzureProject.CD:

https://dev.azure.com/ecopetrolad/AzureVirtualDatacenter/_build?definitionId=1544
• Seleccionar el botón Run pipeline.
Seleccionar la ruta del archivo de configuración creada en el paso 3.1:
Imagen 3: Preparación del pipeline para ejecutar. Seleccionar el archivo correspondiente.

4
G-01 03/06/2021 1
• Finalmente Seleccionar el botón de RUN para ejecutar el pipeline.
Nota: Si es un proyecto de migración, es necesario mover los storage accounts para los nuevos grupos de recursos de los
ambientes de DEV, QA y PROD después de hacer la ejecución del CD pipeline.
5. INSTRUCTIVO DEVOPS
5.1 Prácticas de Ingeniería
Para comenzar, se definirán primero unas prácticas de Ingeniería que se deben adoptar a la hora de comenzar la
creación de un proyecto de DataOps. Estas prácticas permitirán la correcta organización del proyecto y servirán
como estándar para los equipos que usen DataOps.
• Flujo de Trabajo de GIT:
El diseño de Flujo de trabajo de GIT que se propone es “Scaled-Trunk Based Development”. Este Flujo de
Trabajo consiste en utilizar una rama fija como el “trunk”. En esta rama estará lo principal del proyecto.
Además, Se utilizan ramas de corta duración - conocidas también como short-lived branches - para el
desarrollo de características y corrección de errores. Estas ramas idealmente deben tener duración de 1 o 2
días máximo. De esta manera, en el “trunk” siempre estará el código que se va desarrollando y se sacan ramas
temporales para ir agregando funcionalidades. Esas ramas cortas después se unen al trunk por medio de
merge. La siguiente figura representa a mayor detalle el proceso:
Imagen 4: Modelo Scaled Trunk Development
La política de merge, o unión, de las ramas consistirá en las siguientes reglas:

1. Hay que asegurar que no haya conflictos de merge.
5
G-01 03/06/2021 1
2. El código debe ser revisado y aprobado por al menos una persona.

3. Hay que asegurar que al menos un work item esté asociado con el pull request.
4. Hay que asegurar que todos los comentarios realizados en el pull request sean resueltos
• Convenciones de nombre para ramas y commits

Para mantener el orden y evitar posibles errores, se establece una convención para el nombramiento tanto
de las ramas como de los commits que se hagan en dichas ramas. El diseño de nombramiento se aprecia en la
siguiente figura:
Imagen 5: Descripción de las convenciones
1. Convenciones para Ramas:

Los IDs de work items (como tasks y PBIs) son agregados como parte del nombre de las ramas de corta
duración, como ramas de feature y fix. Esta estrategia trae las siguientes ventajas:
- Es una forma simple de comunicar el equipo cuales son las tareas que están siendo desarrolladas.
- Es una forma de asegurar que las ramas no se conviertan en ramas de larga duración, porque las tareas
solo van a ser completadas cuando los merges son hechos en la rama main.
2. Convenciones para mensajes de Commits:

Para convenciones de nombramiento en mensajes de commit, se va a utilizar el patrón Conventional
Commits. El uso de convenciones para commits trae las siguientes ventajas:
- Comunicar la naturaleza de los cambios a los demás integrantes del equipo, el público o cualquier otro
interesado.
- Hacer más fácil a otras personas contribuir al proyecto, permitiendo explorar una historia de los
commits más estructurada.
- Facilitar el proceso de troubleshooting, por hacer con que el proceso de identificación de un commit
(o un conjunto de commits) que introdujo un error sea más simple a través del uso de prefijos que
traen el contexto de los commits.
3. Prefijos:
Se usarán los siguientes prefijos para los diversos commits:
6
G-01 03/06/2021 1
- docs: Utilizado para crear o actualizar nuevos documentos.

- style: Utilizado para actualizar un estilo de un documento (una tabla en Markdown por ejemplo).
- feat. Utilizado para crear una nueva característica (feature) en el código.
- fix: Utilizado para arreglar código o documentos.
- test: Utilizado para crear nuevas pruebas (unitarias, integración, etc.).
- refactor: Utilizado para refactorizar códigos.
- chore: Utilizado para cambiar algo que no es relacionado a código o documentación (cambiar el
nombre de una carpeta, borrar archivos antiguos, etc.).
5.2 Introducción
Este instructivo presenta un paso a paso para ejecutar un Script que configurará un Proyecto de DataOps con todos sus
recursos asociados a partir de un proyecto plantilla. Este Script ejecutará los siguientes pasos:
1. Cargar un Archivo de Configuración con algunos parámetros.

2. Validar el Archivo de Configuración.
3. Crear un Repositorio en Azure DevOps.
4. Clonar el Repositorio en una carpeta temporal.
5. Agregar una entrada remota al repositorio de ejemplo y subir la rama principal con la rama principal del
repositorio de ejemplo.
6. Crear una nueva rama y aplicar los cambios establecidos en el archivo de configuración en los archivos de ejemplo.
7. Crear un nuevo pull request (asociado a un work item y que requiere aprobación).
8. Crear pipelines (especificadas en el archivo de configuración).
9. Crear una política de build.
10. Crear un pull request con los cambios específicos de la plantilla para que sean específicos a ese dominio.
5.3 Prerrequisitos
Para utilizar el template para crear un proyecto de DataOps, se debe utilizar primero una clonación del proyecto como se
muestra en la siguiente figura:
7
G-01 03/06/2021 1
Imagen 6: Estructura del repositorio template
Este patrón indica que se debe partir de un template y hacerle clone por medio de un script. A partir del clone, se podrán
realizar otras configuraciones adicionales como la creación de los recursos y se podrá comenzar a trabajar a partir de un
proyecto ya estructurado.
Además, para la ejecución del Script es necesario contar con los siguientes permisos:
Imagen 7: Roles y permisos en Azure
8
G-01 03/06/2021 1
También es necesario configurar algunos roles para el Service Principal. Los roles requeridos son Contributor y User Access
Administrator.
Además, se requiere generar 2 Service Connections, una para el ambiente DevTest y la otra para el ambiente de
Producción. Es importante que en la configuración de los Service Connections, se habilite el permiso para acceder a todos
los pipelines. Esto se muestra en la siguiente figura:
Imagen 8: Configuración de las Service Connections
5.4 Despliegue de pipeline inicial
Como se explicó al inicio de esta sección, un script (.\scripts\operations\Add-Domain.ps1) está disponible para
automatizar la creación de un nuevo repositorio por medio de un archivo de configuración. Ese Script Creará los
siguientes recursos Azure:
• Un nuevo repositorio
- Políticas de build y pull requests
• Pipelines DevOps
- CI de Infraestructura como código
- CD de infraestructura como código
- CI de Azure Data Factory
- CD de Azure Data Factory
9
G-01 03/06/2021 1
- CI de Synapse
- CD de Synapse
• Un pull request con los cambios de código específicos para cada dominio.
IMPORTANTE: Antes de realizar estos pasos, se debe haber ejecutado el pipeline Deploy-AzureProject. Esto evitará
que se deban crear archivos de configuración manualmente para la ejecución de este pipeline.
Para utilizar el script, es necesario modificar el archivo de configuración (config.template.json) el cual se encuentra
dentro de la carpeta (./scripts/configs). Para más información sobre el archivo de configuración necesario para el
script Add-Domain.ps1, por favor revisar el siguiente enlace:
https://dev.azure.com/ecopetrolad/AzureVirtualDatacenter/_git/AzureVirtualDatacenterPS1?path=%2Fdocs%
2Fdataops%2Fadd-domain.config.md&version=GBmain
5.5 Generación de ambientes
Creación del Archivo de configuración:

1. Clonar el repositorio en la máquina local:
https://ecopetrolad@dev.azure.com/ecopetrolad/AzureVirtualDatacenter/_git/AzureVirtualDatacenterPS1
En una consola tipo Git Bash ejecutar los siguientes comandos, reemplazando <url> por la url del repositorio:
git clone <url>
cd AzureVirtualDataCenterPS1
Imagen 9: Clonar el Repositorio Template
10
G-01 03/06/2021 1
2. Descargar los artefactos generados por el pipeline Deploy-AzureProject y cópielos dentro del repositorio que
acaba de clonar, bajo el directorio configs/dataops/:
Imagen 10: Revisión del Artifact después de ejecutar el pipeline.
El Artifact que se genera es un documento tipo json que representará la configuración necesaria para los
pasos posteriores.
Imagen 11: Descarga del Artifact
11
G-01 03/06/2021 1
Después de descargado, el archivo json se debe llevar a: “./configs/dataops”
Imagen 12: Directorio al que se debe mover el archivo json generado por el pipeline
3. Generar un nuevo Commit y Push de los cambios en una nueva rama git (a partir de main)
4. Abrir un nuevo Pull Request a main
5. Ejecutar el pipeline utilizando el directorio del archivo de configuración:
12
G-01 03/06/2021 1
Imagen 13: Ejecución del pipeline.
6. Entrar al nuevo repositorio y obtenga las aprobaciones necesarias para completar el Pull Request.
7. Una vez que el Pull Request esta completado, esperar a que el pipeline de IaC-CD finalice hasta alcanzar la
etapa de producción.
8. Configurar los ambientes con las aprobaciones y comprobaciones (Gates) que se necesitan dependiendo del
proyecto siguiendo este enlace:
https://docs.microsoft.com/en-us/azure/devops/pipelines/process/environments?view=azure-
devops#approvals
Finalizado los pasos, la estructura del nuevo repositorio será la siguiente:
13
G-01 03/06/2021 1
Imagen 14: Estructura Final del Repositorio
5.6 Otorgar Permisos en Synapse
Synapse es un recurso transversal, y no es generado a través de los pipelines de automatización porque ya existe. Al ser
un recurso compartido, cuando un proyecto nuevo es desplegado, es necesario asignar permisos al service principal y al
Azure Data Factory de leer y escribir en la base de datos de Synapse.
Ejecución del pipeline
El pipeline "Grant-Permissions-Synapse.CD" tendrá que ser ejecutado manualmente después de que un nuevo proyecto
con su infraestructura haya sido creado exitosamente. El parámetro que recibe (Domain Name) es el nombre del
proyecto que acaba de ser generado, y se le darán los permisos para que lea y escriba en la base de datos de Synapse.
Imagen 15: Ejecución del pipeline de Synapse
14
G-01 03/06/2021 1
Detalles del pipeline
Este pipeline obtiene los datos de la instancia de Azure Data Factory, el service principal del proyecto de Azure DevOps
(Azure Service Connection) y los datos de Synapse a través de diferentes tareas:
1. Conectarse a Azure Devops:
Imagen 16: Conexión a Azure DevOps.
2. Obtener las Variables necesarias del Proyecto de Azure Devops:
Imagen 17: Variables Synapse
15
G-01 03/06/2021 1
Estas variables se obtienen de un Script en Powershell:
Imagen 18: Script PowerShell para obtener las variables
3. Obtener las variables del Service Principal del Proyecto
Imagen 19: Script para obtener las variables del Service Principal
4. Obtener un token de autenticación a la base de datos de Synapse, desde el proyecto

"AzureVirtualDatacenter"
Imagen 20: Obtención del token de autenticación
5. Invocar a la instancia de base de datos de Synapse para agregar al usuario. Este paso se repite para
Azure Data Factory, y para el service principal.
Imagen 20: Agregar el Usuario
La invitación a la base de datos de Synapse se hace a través del siguiente script de Powershell:
16
G-01 03/06/2021 1
Imagen 21: Invitación a la base de datos de Synapse
Todos los comandos Powershell completos se pueden encontrar en el siguiente enlace:

https://dev.azure.com/ecopetrolad/AzureVirtualDatacenter/_git/AzureVirtualDatacenterPS1?path=%2Fdocs%2Fdataop
s%2Fgrant-permissions-synapse.pipeline.md&_a=preview
6. INSTRUCTIVO EQUIPO DESARROLLO
Con los pasos anteriores, ya se tiene un proyecto base para comenzar a desarrollar un proyecto en DataOps. Sin
embargo, en el caso de que ya se tenga un dominio existente, es necesario realizar el instructivo 6.1 para migrar ese
dominio.
6.1 Migración de Datamarts y Repositorios Existentes
El anterior Instructivo está diseñado para proyectos de DataOps en los que se tenga que crear un nuevo dominio. En el
caso de que ya se cuente con un dominio existente, se debe realizar una migración del historial de GIT de un repositorio
de Azure Data Factory. (Este paso es opcional y solo se debe hacer si ya se tiene un dominio).
Para poder migrar una rama que ya existe (Long-lived) dentro de un proyecto a un repositorio de git dedicado, es
necesario ejecutar una secuencia de pasos que permita no solo migrar los archivos, pero también el historial de cambios.
Requerimientos
• PowerShell
• Un fork del repositorio template
• Autenticación Git (https://docs.microsoft.com/en-us/azure/devops/repos/git/auth-overview?view=azure-
devops)
Pasos para la migración
1. Clonar el repositorio compartido donde tiene la rama (long-lived) de Data Factory, actualmente llamado
DmDataFactoryDev:
Imagen 22: Clonar el Repositorio
2. Realizar un Checkout de la rama del proyecto (por ejemplo, DM_CADENA_SUMINISTROS):
Imagen 23: Checkout a la rama del proyecto

17
G-01 03/06/2021 1
3. Crear una rama temporal dentro del repositorio que se utilizará para la migración:
Imagen 24: Creación de una nueva rama
4. Agregar el nuevo repositorio que se ha creado utilizando el patrón de fork (ya sea a través del
Pipeline "Add Domain" de Azure DevOps o ejecutando manualmente el script Add-Domain.ps1)
como nuevo [remote] bajo el nombre Project (https://git-scm.com/book/en/v2/Git-Basics-
Working-with-Remotes ) (por ejemplo, https://../BI/DMCadenaSuministro):
Imagen 25: Agregar el nuevo repositorio
5. Crear un directorio llamado data-factory. Luego mover todos los archivos del repositorio git original de
Data Factory a este directorio. Finalmente realizar commit de los cambios:
Imagen 26: Migración de Archivos
6. Combinar (merge) el nuevo repositorio (actualmente como un remote llamado project/main) con los
cambios de la rama long-lived del repositorio original hacia el branch de migración, aceptando todos los
cambios que originalmente se realizaron en el template:
Imagen 27: Migración de la historia
7. Realizar Push de todos los cambios locales a una nueva rama (llamada en este ejemplo
DM_CADENA_SUMINISTROS_MIGRATION) en el nuevo repositorio:
Imagen 28: Git Push
18
G-01 03/06/2021 1
8. En el nuevo repositorio, abrir un Pull Request desde DM_CADENA_SUMINISTROS_MIGRATION a main y

siga los pasos para obtener las aprobaciones necesarias. La migración habrá finalizado una vez que se
complete. No utilizar Squash Commit merge strategy para mantener el historial de git.
9. Bloquear (Lock) la rama original en el repositorio compartido. Al bloquear la rama original, se

garantizará que no se realicen cambios en el repositorio y rama del que ha migrado los cambios. En este
ejemplo, se deberá bloquear DM_CADENA_SUMINISTROS en DmDataFactoryDev. Para bloquear la
rama, se puede consultar el siguiente enlace: https://docs.microsoft.com/en-
us/azure/devops/repos/git/lock-branches?view=azure-devops
10. Probablemente se quiera mantener la rama antigua (que está bloqueada) por un tiempo. Una vez
que la migración haya sido exitosa y ya se pueda continuar con el proceso de desarrollo sin
problemas, se puede eliminar esta rama original.
7. RELACIÓN DE VERSIONES
RELACIÓN DE VERSIONES
Versión Fecha Autor Descripción del cambio

1 03/06/2020 Daniel Serrano y Equipo Creación de instructivo
implementación DevOps
Para más información dirigirse a:

Elaboró: Proyecto Implementación DevOps – Elaborado por Daniel Serrano y equipo implementación DevOps.
Revisado por: Angélica Barrero, Líder DevOps - Buzón: angelica.barrero@ecopetrol.com.co
Dependencia: Coordinación Transición de Servicio, Vicepresidencia Digital
Revisado electrónicamente por: Aprobado electrónicamente por:

ANGÉLICA BARRERO PAULA CARDONA
Profesional Integral de Operación Digital B Coordinador Transición de Servicio
Coordinación de Transición de Servicio - VDI Coordinación de Transición de Servicio -VDI
Documento firmado electrónicamente, de acuerdo con lo establecido en el Decreto 2364 de 2012, por medio del cual se reglamenta el artículo 7 de la Ley 527 de
1999, sobre la firma electrónica y se dictan otras disposiciones.
Para verificar el cumplimiento de este mecanismo, el sistema genera un reporte electrónico que evidencia la trazabilidad de las acciones de revisión y aprobación
por los responsables. Si requiere verificar esta información, solicite dicho reporte a Service Desk.
19

Instructivo Data Ops

Cargado por

Copyright:

Formatos disponibles

Instructivo Data Ops

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Instructivo Data Ops

Cargado por

Copyright:

Formatos disponibles

INSTRUCTIVO GENERACIÓN DE INFRAESTRUCTURA Y PIPELINES EN DATAOPS

INSTRUCTIVO GENERACIÓN DE INFRAESTRUCTURA Y PIPELINES EN DATAOPS

En la siguiente imagen se puede apreciar la división de responsabilidades entre los equipos.

Imagen 1: Descripción general del instructivo

Los scripts y archivos de configuración se encuentran en el siguiente repositorio:

4.1 Creación de Archivo de Configuración

Después, Crear un nuevo archivo de configuración JSON en el directorio “configs/cloud-

Imagen 2: Directorios con los archivos de configuración basados en template.json

Después de crear el archivo en el directorio, es necesario:

1. Crear una nueva rama Git (ejemplo: git checkout -b <BRANCH_NAME>)

4.2 Ejecutar el CD pipeline de Cloud Setup

• En Azure DevOps, ir en la sección Pipelines y seleccionar el pipeline Deploy-AzureProject.CD:

Seleccionar la ruta del archivo de configuración creada en el paso 3.1:

Imagen 3: Preparación del pipeline para ejecutar. Seleccionar el archivo correspondiente.

• Finalmente Seleccionar el botón de RUN para ejecutar el pipeline.

5.1 Prácticas de Ingeniería

• Flujo de Trabajo de GIT:

Imagen 4: Modelo Scaled Trunk Development

La política de merge, o unión, de las ramas consistirá en las siguientes reglas:

2. El código debe ser revisado y aprobado por al menos una persona.

• Convenciones de nombre para ramas y commits

Imagen 5: Descripción de las convenciones

1. Convenciones para Ramas:

2. Convenciones para mensajes de Commits:

- docs: Utilizado para crear o actualizar nuevos documentos.

1. Cargar un Archivo de Configuración con algunos parámetros.

Imagen 6: Estructura del repositorio template

Imagen 7: Roles y permisos en Azure

Imagen 8: Configuración de las Service Connections

5.4 Despliegue de pipeline inicial

5.5 Generación de ambientes

Creación del Archivo de configuración:

git clone <url>

Imagen 9: Clonar el Repositorio Template

Imagen 10: Revisión del Artifact después de ejecutar el pipeline.

Imagen 11: Descarga del Artifact

Después de descargado, el archivo json se debe llevar a: “./configs/dataops”

4. Abrir un nuevo Pull Request a main

5. Ejecutar el pipeline utilizando el directorio del archivo de configuración:

Imagen 13: Ejecución del pipeline.

Finalizado los pasos, la estructura del nuevo repositorio será la siguiente:

Imagen 14: Estructura Final del Repositorio

5.6 Otorgar Permisos en Synapse

Ejecución del pipeline

Imagen 15: Ejecución del pipeline de Synapse

Detalles del pipeline

1. Conectarse a Azure Devops:

Imagen 16: Conexión a Azure DevOps.

2. Obtener las Variables necesarias del Proyecto de Azure Devops:

Imagen 17: Variables Synapse

Estas variables se obtienen de un Script en Powershell:

Imagen 18: Script PowerShell para obtener las variables

3. Obtener las variables del Service Principal del Proyecto

4. Obtener un token de autenticación a la base de datos de Synapse, desde el proyecto

Imagen 20: Obtención del token de autenticación

Imagen 20: Agregar el Usuario

Imagen 21: Invitación a la base de datos de Synapse

Todos los comandos Powershell completos se pueden encontrar en el siguiente enlace:

6. INSTRUCTIVO EQUIPO DESARROLLO