Saltar al contenido principal Saltar al contenido complementario

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.

Nota informativaEl control de versiones no está disponible con una suscripción a Qlik Talend Cloud Starter.

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.

Conexión a 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.

Nota informativaSe creará una conexión del tipo GitHub - Control de versiones en su espacio personal. Todos los usuarios dispondrán de una conexión personal de control de versiones, por lo que no es necesario gestionarla.

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.

Conecte un proyecto al control de versiones.

Lista desplegable con las distintas regiones durante la configuración del espacio empresarial inquilino.
  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.

Flujo de trabajo para un proyecto con varios desarrolladores con el control de versiones

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

  2. 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. 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. 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. 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. También debe tener permiso para acceder el espacio donde reside la conexión de destino del proyecto.

  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.

Nota informativaSi solo aplica las tareas seleccionadas, debe tener cuidado de mantener la validez estructural del proyecto. Por ejemplo, si aplica una nueva tarea de almacenamiento, debe aplicar también la tarea de ubicación de destino/aterrizaje de origen. Añadir manualmente el conjunto de datos de ubicación de destino no funciona.

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 generales cuando se trabaja 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.

    Si comienza con un repositorio vacío, el control de versiones de Qlik Talend Cloud añadirá automáticamente un archivo README.md vacío.

  • En general, debería dejar que el control de versiones de Qlik Talend Cloud gestione el repositorio de GitHub.

  • 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 de manera predeterminada 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.

Trabajar en ramas

Puede crear un proyecto, diseñarlo y, cuando esté listo, implementarlo en producción utilizando la rama PRINCIPAL. La versión en PRINCIPAL corresponde a su proceso de producción. Nunca debe editar la rama PRINCIPAL directamente después de la primera implementación.

Cada vez que un desarrollador desea realizar un nuevo cambio en un proyecto, como añadir una función o corregir un error, es necesario crear una nueva rama.

Los desarrolladores pueden crear cualquier número de ramas para sus necesidades de desarrollo

  • Utilice prefijos de esquema para las ramas a fin de evitar conflictos en la base de datos al realizar los cambios.

  • En una rama, los desarrolladores pueden realizar cualquier número de cambios, y pulsar confirmar y enviar tantas veces como necesiten. Se recomienda aislar cada cambio en una confirmación autónoma e independiente. Por ejemplo, si realiza un cambio en una tarea de transformación que también afecta al mercado de datos, asegúrese de incluir ambos cambios en una única confirmación.

  • Todos los miembros del equipo deben utilizar Aplicar cambios remotos en cualquier momento para asegurarse de que su rama PRINCIPAL está actualizada, especialmente antes de confirmar sus cambios.

Cuando los desarrolladores terminan de trabajar en su rama, pueden crear una solicitud de extracción para la revisión por pares.

Nota informativaActualmente es necesario crear una solicitud de extracción antes de poder utilizar Aplicar cambios remotos y fusionar los cambios de la rama de nuevo a la principal.

Cree una solicitud de extracción en GitHub en Pull requests. Debe especificar la rama desde la que crear una solicitud de extracción (pull request).

Tras la revisión y aprobación de los demás miembros del equipo, puede fusionar la solicitud de extracción o pull request con la versión PRINCIPAL.

Por último, utilice Aplicar cambios remotos en el proyecto para arrastrar los cambios aprobados de la rama a la rama PRINCIPAL (producción).

Nota informativaTodos los miembros del equipo deben utilizar Aplicar cambios remotos en cualquier momento para asegurarse de que su rama PRINCIPAL está actualizada.

Trabajar en espacios

Para implementaciones más grandes y críticas se recomienda utilizar espacios específicos para el desarrollo y la producción con el fin de aislar los cambios y garantizar la integridad del proceso. Utilice conexiones de datos específicas para las fuentes y el destino en cada espacio.

  • La rama PRINCIPAL refleja lo que está en producción. Esto significa que solo existe una versión PRINCIPAL de un proyecto.

    La producción se aísla en un espacio de datos específico, por ejemplo, PROD. Las conexiones específicas se asignan al espacio de producción.

    No se realizan cambios directamente en el espacio de producción/rama PRINCIPAL. Todos los cambios se realizan en otros espacios con conexiones específicas, utilizando ramas.

    Puede reutilizar la versión PRINCIPAL de un proyecto existente en GitHub. Cree un proyecto vacío con el mismo nombre que el proyecto existente en GitHub. Esto recupera la última versión disponible en la rama PRINCIPAL para empezar a editar.

    Los usuarios crean una nueva rama, realizan sus cambios, crean solicitudes de extracción pull requests, fusionan y vuelven a lanzarlo a PRINCIPALMAIN/Producción.

  • Los desarrolladores pueden aislar sus cambios en un espacio de datos específico, por ejemplo, DEV. Las conexiones específicas se asignan al espacio DEV.

    Los cambios se aíslan mediante ramas, normalmente una rama por desarrollador. Utilice prefijos de esquema cuando se cree una rama para evitar conflictos en la base de datos al realizar los cambios.

  • Los revisores tienen acceso a los espacios de desarrollo y a las conexiones:

    • Abra y pruebe las ramas del proyecto en Qlik Talend Cloud.

    • Apruebe las solicitudes de extracción para proceder a la fusión en GitHub.

    • Informe a los miembros del equipo de cuándo se pueden retirar los cambios aprobados a PRINCIPAL/Producción.

Cuando vuelva a implementar los cambios aprobados en el espacio PRINCIPAL/Producción, deberá volver a asignar conexiones a las conexiones del espacio de producción.

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.

¿Esta página le ha sido útil?

No dude en indicarnos en qué podemos mejorar si encuentra algún problema en esta página o su contenido, como, por ejemplo, errores tipográficos, pasos que falta o errores técnicos.