- Reseña de un proyecto open source para migrar de Jira a GitLab
- Motivo
- La noticia de que el soporte para los productos de servidor de Jira terminaría el 15 de febrero de 2024
- Alternativas disponibles: Pivotal Tracker, IBM Engineering Requirements Management DOORS Next, Rally Software, GitLab, ServiceNow Agile Development, GitHub, etc.
- ¿Qué harán quienes usaban Jira Server? ¿Y si creamos un proyecto para migrar a GitLab?
- Estado actual de la funcionalidad de migración Jira → GitLab
- En GitLab se copian el
title, description y label de los issues de Jira
- El resto de los metadatos se traen dentro de la
description
- Se ofrece una UI para mapear usuarios de Jira a usuarios de GitLab
- Restricciones de la migración Jira → GitLab
- Es obligatorio configurar Jira Integration
- Solo se ofrece Jira API v3
- Jira y GitLab usan sintaxis diferentes, por lo que la migración no queda exacta
- En la
description, Heading 1, Heading 2, Heading 3 se trasladan como Numbered, SubNumbered, SubNembered 2
- GitLab usa sintaxis Markdown, mientras que Jira usa un formato propietario llamado
ADF(Atlassian Document Format), y de ahí surge la diferencia
issue type, priority y label tampoco se migran con total precisión
- Dirección del proyecto interno de migración
- Objetivos:
- Tomar decisiones sobre a dónde deben ir los épicos de Jira y a dónde deben ir los issues
- Definir concretamente a qué campos de GitLab deben ir campos de issues de Jira como
title, description, label, component, etc., y realizar la migración
- Al mover épicos de Jira a épicos de GitLab, se dio libertad para que el usuario decidiera si migrarlos como subépicos en un subgrupo o como épicos en un grupo superior
- Los issues se migran como issues
- Limitaciones:
- También se quería migrar los subtasks como tareas dentro de issues bajo subtareas, pero la API de tareas de GitLab no lo soporta
- Jira tiene demasiados campos;
- Funciones simples como
description, label y component sí están soportadas en GitLab y pueden migrarse
- Pero!!! los campos relacionados con
time tracking y seguridad no están soportados en GitLab, así que no pueden migrarse
- Diseño final
- Proyecto de Jira → proyecto de GitLab
- Épico de Jira → épico de GitLab
- Issue de Jira → issue de GitLab
title, description, version, story point, resolution de Jira se mapean tal cual en GitLabresolution de Jira → closed de GitLab, story point de Jira → weight de GitLabissue type, component, status, priority de Jira → migración usando label y scoped label de GitLab- También se desarrolló
custom field
- La
description se parsea completamente con expresiones regulares y su contenido se convierte a Markdown para migrarlo
- Resultados del proyecto
- Migrar el modo puro de Jira resulta bastante útil
- Si se excluyen plugins y automatizaciones, la migración funciona bien
- La mayoría se mapea con GitLab Label
- Se crean épicos en el grupo superior de destino
- Los enlaces entre issues conectados en Jira también se migran a GitLab
- El wiki markup de Jira se convierte con un convertidor a Markdown
- También se agregan
attachment y comment a los issues
- Si se crean muchos
custom field, la migración se vuelve difícil
- Aciertos
- Primero se creó la versión cloud y luego se añadió la versión para servidor
- Con solo configurar el mapeo de
custom field, se puede migrar la mayor parte
- Se organizó adecuadamente el procesamiento en paralelo para que la migración fuera más de 3 veces más rápida que sin ello
- La configuración se gestionó en YAML, alineada con las tendencias actuales
- Se hizo open source para que cualquiera pudiera migrar
- El paquete se distribuyó con Brew
- Puntos a mejorar
- Al migrar desde Jira Server
- Se necesita agregar el mapeo de sprints
- No hay forma de manejar los campos Cascade
- Al migrar desde Jira Cloud
- Hace falta probar muchos casos reales, como la migración de datos relacionados con plugins
- Página del proyecto open source:
Aún no hay comentarios.