Administrar sus proyectos con el control de versiones

Puede utilizar el control de versiones para gestionar el desarrollo de un proyecto de datos y hacer un seguimiento de los cambios.

Al trabajar con el control de versiones, puede confirmar versiones de los proyectos durante el diseño. Esto le permite ver los cambios entre dos versiones del proyecto. También puede desarrollar sus proyectos de datos utilizando una estrategia de ramificación. Esto le permite trabajar en una versión aislada del proyecto en cada área de trabajo o rama. El área de trabajo puede ser compartida por varios usuarios. A continuación, puede fusionar sus cambios desde el área de trabajo a una rama principal para implementarlos en producción.

GitHub se utiliza como proveedor para el control de versiones.

Comenzar

• Cree un usuario en GitHub que el espacio empresarial inquilino pueda utilizar para acceder a GitHub. Es posible que un administrador ya lo haya creado para usted.

  El usuario debe tener los siguientes ámbitos:

  • repo

  • read:org

  • read:user

  • read:project

• Necesita permiso de escritura en los repositorios que planea modificar.

• Debe crear un token de acceso personal a GitHub (clásico). No se admiten tokens de acceso personal detallados.

  Para más información, consulte la documentación de GitHub: Gestión de sus tokens de acceso personales.

• La organización es obligatoria en la configuración de GitHub.

• Necesita el rol Puede editar en el espacio donde reside el proyecto para realizar acciones de control de versiones.

• Antes de empezar a utilizar el control de versiones, debe establecer una configuración para conectarse a GitHub con el usuario de GitHub que ha creado.

  Establecer la configuración en GitHub

• Cuando haya establecido una conexión con GitHub, podrá conectar un proyecto a un repositorio.

  Conexión de un proyecto a un repositorio

Establecer la configuración en GitHub

Todos los usuarios que deseen trabajar con el control de versiones deben establecer una configuración para conectarse a GitHub utilizando una cuenta de usuario de GitHub.

Puede configurar GitHub en Proyectos. Asegúrese de que se ha preparado según Comenzar.

1. Haga clic en y luego en Configuración de GitHub.

2. Configure la autenticación utilizando su organización y el token de acceso personal de GitHub descrito en Comenzar.

3. Haga clic en Aceptar.

Ahora puede conectar sus proyectos a un repositorio.

Conexión de un proyecto a un repositorio

Debe conectar un proyecto con un repositorio antes de poder empezar a utilizar el control de versiones. Asegúrese de que ha establecido una conexión con GitHub.

1. En Proyectos, haga clic en ... en un proyecto y seleccione Conectar con el control de versiones.

2. Seleccione a qué repositorio desea asociar el proyecto.

3. Añada una ruta de directorio base.

   Si desea conectarse a un proyecto existente en GitHub, debe utilizar la misma ruta.

4. Puede seleccionar confirmar el proyecto y enviar el proyecto al repositorio remoto después de la conexión. Introduzca un mensaje de confirmación.

   Si no lo confirma pulsando Confirmar y enviar, se creará una rama principal en el área de trabajo, pero no en el repositorio remoto.

5. Haga clic en Conectar.

El proyecto está ahora conectado al repositorio seleccionado. Esto se indica en la parte inferior de la ficha del proyecto con , el nombre del repositorio y la rama actual.

Cuando abra el proyecto, la fila del título contendrá ahora un menú de GitHub con opciones de control de versiones. Al nombre del proyecto se le añadirá también el nombre de la rama actual.

Desarrollar un proyecto con control de versiones

Puede utilizar el control de versiones con diferentes enfoques:

• Trabajar directamente en la rama principal. Esto es adecuado sobre todo para un único desarrollador en un proyecto que desee hacer un seguimiento de los cambios, pero también puede utilizarlo un grupo de desarrolladores que trabajen de forma sincronizada.

• Trabajar con una estrategia de ramificación, en la que puedan contribuir varios desarrolladores. También puede crear ramas para aislar nuevas funciones o cambios entre sí.

Flujo de trabajo simplificado para un proyecto de un solo desarrollador

Puede trabajar directamente en la rama principal de un proyecto. Este enfoque es más sencillo y contiene menos operaciones, pero le permite seguir los cambios. Si hay más de un desarrollador, deben tener el cuidado de estar sincronizados.

Cuando haya realizado cambios en el proyecto que desee aplicar, solo tiene que pulsar Confirmar y enviar.

Flujo de trabajo para un proyecto de varios desarrolladores

Este flujo de trabajo puede utilizarse si hay más de un desarrollador trabajando en un proyecto o si desea aislar los cambios. Esto implica la creación de una rama de desarrollo que puede compartir con otros usuarios. Con este flujo de trabajo, los desarrolladores pueden hacer un seguimiento de los cambios de los demás usuarios y decidir cuándo fusionar los cambios en la rama principal.

1. Crear una nueva rama

   Cree una nueva rama de desarrollo a partir de la rama principal. Puede compartir la rama con más usuarios.

2. Desarrollar

   Realice todos los cambios necesarios en el proyecto.

   Nota informativaLos esquemas y conexiones de las bases de datos no se mantienen en el control de versiones.

3. Aplicar cambios remotos

   Aplique los cambios remotos de otra rama a su área de trabajo para asegurarse de que está al día de los cambios de la otra rama. Esto es útil para evitar o mitigar cambios conflictivos.

   Si tiene dos ramas que contienen cambios que pueden entrar en conflicto, una solución alternativa es:

   1. Confirme los cambios en ambas áreas de trabajo.

   2. Fusione ambas ramas con la principal.

   3. Vuelva a aplicar los cambios remotos.

4. Confirmar y enviar

   Confirme y envíe sus cambios a la rama de desarrollo. Todos los objetos se enviarán, por lo que es una buena idea validar su proyecto antes de confirmarlo.

5. Abrir una solicitud de extracción y fusionar

   Cuando esté listo con el desarrollo, es el momento de fusionar los cambios del área de trabajo con la rama principal. La fusión de una rama de desarrollo con la rama principal debe realizarse en GitHub abriendo una solicitud de extracción (pull request). Puede configurar la aprobación para que la rama se fusione con la rama principal. Para más información, consulte la documentación de Pull requests de GitHub

Crear una nueva rama

1. En Proyectos, haga clic en ... en un proyecto y seleccione Crear nueva rama.

   El proyecto debe estar conectado al control de versiones.

2. Seleccione esta opción para crear una rama a partir de la rama principal.

3. Indique un nombre para la rama.

4. Establezca un prefijo que se añadirá a todos los esquemas del proyecto en Prefijo de rama para todos los esquemas. Esto permite que todos los esquemas tengan un nombre único para evitar conflictos de denominación.

5. Haga clic en Crear

Se crea una nueva rama a partir de la principal y se extrae del repositorio. La rama contiene una nueva versión del proyecto, con todas las tareas en estado Nuevo. Es decir, no están preparados y no contienen datos.

Aplicación de cambios remotos

Puede aplicar los cambios desde el repositorio remoto a su área de trabajo. Podría tratarse de cambios creados fuera del control de versiones integrado en Qlik Cloud, por ejemplo en GitHub o mediante otras herramientas. Esto le ayudará a evitar conflictos cuando quiera confirmar y enviar sus cambios a la rama.

1. En Proyectos, haga clic en ... en un proyecto y seleccione Aplicar cambios remotos.

   El cuadro de diálogo Aplicar cambios remotos al área de trabajo aparece si se han encontrado cambios.

2. Ahora puede seleccionar a qué tareas aplicar los cambios e inspeccionarlos. Para cada cambio, puede seleccionar qué versión utilizar, la versión remota o la versión de su área de trabajo.

3. Haga clic en Aplicar cambios remotos

Debe añadir conexiones de origen y conexiones de destino si los cambios incluyen nuevas tareas de datos.

Confirmar y enviar

Puede confirmar y enviar sus cambios a la rama. Como los cambios remotos que no se aplican a su área de trabajo podrían sobrescribirse, debe pulsar Aplicar cambios remotos antes de confirmar y enviar.

1. En Proyectos, haga clic en ... en un proyecto y seleccione Confirmar y enviar.

   El diálogo Confirmar y enviar se muestra si se han encontrado cambios.

2. Añada un mensaje de confirmación que puede ayudarle a realizar un seguimiento de lo que ha cambiado.

3. Pulse Confirmar y enviar

Borrar una rama

Puede eliminar una rama cuando haya fusionado sus cambios con la rama principal.

1. En Proyectos, haga clic en ... en la rama que desee eliminar y seleccione Eliminar rama.

   También puede seleccionar eliminar la rama remota en el control de versiones.

   Si hubiera cambios no confirmados deberá confirmar que estos cambios se perderán al eliminar la rama.

Eliminación del control de versiones de un proyecto

Puede desconectar su proyecto del control de versiones. Si existen ramas, deberán eliminarse antes de poder desconectar el proyecto.

1. En Proyectos, haga clic en ... en el proyecto que desea desconectar y seleccione Desconectar de GitHub.

Compartir un proyecto con otros espacios o espacios empresariales inquilinos

Puede compartir una versión de un proyecto con un espacio diferente del mismo espacio empresarial inquilino o en otro espacio empresarial diferente. Esto resulta útil cuando desea crear dos entornos, por ejemplo uno para desarrollo y otro para producción.

1. Cree un nuevo proyecto con el mismo nombre que el proyecto original.

   Establezca el mismo caso de uso y tipo de plataforma. Puede utilizar diferentes conexiones.

2. Conecte el nuevo proyecto a la misma ruta del repositorio y del directorio base que el proyecto original.

   Nota informativaNo seleccione la opción Confirmar y enviar.

3. Si la conexión de la plataforma apunta al mismo objetivo que el proyecto original, asegúrese de cambiar la base de datos o los esquemas de las tareas de datos. Una forma de cambiar los esquemas de todas las tareas es cambiar Prefijo para todos los esquemas en la configuración del proyecto Metadatos antes de aplicar los cambios remotos. Esto garantiza que todas las tareas se creen con este prefijo.

4. Aplique los cambios remotos, seleccionando todos los archivos.

5. Añada las conexiones de origen que faltan para todas las tareas de ubicación de destino/aterrizaje de datos.

   Haga clic en Seleccionar fuente de datos en la tarea de ubicación de destino, seleccione la conexión y haga clic en Guardar.

   Nota informativaLa conexión debe ser del mismo tipo de fuente y apuntar a tablas con los mismos nombres que en el proyecto original.

6. Añada las conexiones de origen y destino que faltan para todas las tareas de replicación.

Esto crea otra zona de trabajo. Puede realizar cambios en el proyecto en una de las áreas de trabajo y utilizar Aplicar cambios remotos para sincronizar la otra área de trabajo.

Consideraciones específicas de seguridad

Asegúrese de mantener sincronizadas las configuraciones de seguridad entre Qlik Talend Data Integration y GitHub.

• En Qlik Talend Data Integration los permisos se basan en espacios que pueden contener varios proyectos. En GitHub, los permisos se basan en repositorios que también pueden contener varios proyectos. La mejor práctica consiste en alinearlos y conectar todos los proyectos de un espacio al mismo repositorio.

• Tenga en cuenta que Qlik Talend Data Integration y GitHub utilizan diferentes permisos y roles para los usuarios.

Mejores prácticas

Estas son algunas de las mejores prácticas a la hora de trabajar con proyectos que utilizan el control de versiones.

• Añada un archivo README que describa el repositorio en GitHub. Para más información, consulte Acerca de los README.

• Confirme únicamente los proyectos que sean válidos y cuya ejecución haya sido probada.

  Si añade proyectos con tareas de ubicación de destino/aterrizaje o datos registrados que no se han preparado o transformado, las columnas de origen todavía no se incluirán. Las columnas de origen se añaden cuando se prepara y transforma la tarea.

• Cuando cree una rama para proyectos de replicación, debe tener en cuenta que las ramas utilizan por defecto el mismo destino. Esto significa que las tareas en ejecución en la rama pueden anular los datos de la versión principal. Para evitar la pérdida de datos, cambie la configuración de destino en la rama para que no entre en conflicto con la versión principal.

• Al crear una rama, puede haber cambios remotos que aún no se hayan aplicado al área de trabajo. Aplique los cambios remotos antes o después de crear la rama, a menos que desee descartar los cambios remotos.

• Realizar cambios en el mismo conjunto de datos en dos ramas diferentes puede dar lugar a conflictos de fusión difíciles de resolver.

Limitaciones

• No es posible desconectar o eliminar un proyecto mediante el control de versiones si existen ramas. Las ramas deben eliminarse antes de poder desconectar o eliminar el proyecto.

• No es posible cambiar el nombre de un proyecto utilizando el control de versiones.

• Cuando elimine un espacio empresarial inquilino, los objetos almacenados con control de versiones en GitHub no se eliminarán. Deberá eliminar estos objetos manualmente.

• Si un repositorio es utilizado por muchos proyectos o contiene muchos archivos que no se almacenan en Qlik Talend Data Integration, el rendimiento puede disminuir.

• Los esquemas y conexiones de las bases de datos no se mantienen en el control de versiones.

• No se admiten tokens de acceso personal detallado de GitHub.

• Una rama (excepto la rama principal) solo puede ser utilizada por un proyecto por repositorio, aunque haya dos proyectos en el mismo repositorio.

• No es posible aplicar cambios remotos desde un proyecto que utilice una plataforma de destino diferente. Por ejemplo, si confirma cambios en un proyecto en Snowflake, no podrá aplicar los cambios a un proyecto de Databricks.