Migra tus repositorios a GitHub: Guía detallada
Son muchas las opciones que tienes si quieres cambiar de productos GitHub, como de GitHub Enterprise Server a Cloud, o de otras plataformas de alojamiento de código, como GitLab. Cuando esto ocurra, querrás llevar contigo tu trabajo, como tu código, el historial de este o todas tus conversaciones y colaboraciones pasadas.
GitHub ofrece una gran variedad de herramientas para ayudarte en estas migraciones y que proporcionan diferentes niveles de fidelidad. Recopilamos las mejores prácticas y algunos ejemplos para que puedas comenzar tus migraciones cuanto antes.
Migración a GitHub: Mejores prácticas
Lo primero que debes plantearte antes de empezar con la migración es definir qué deseas migrar y cuándo. Una vez que se tenga claro esto, se debe determinar desde dónde se van a mover los datos. Dependiendo del tamaño y complejidad de tu negocio, es posible que se estén utilizando varias plataformas de alojamiento de código diferentes.
Y, claro está, debes tener claro a qué producto de GitHub estás migrando: tu destino de migración.
Construir un inventario básico
Una vez que ya tengas estos dos puntos claros, deberás concretar qué datos necesitas para migrar.
Crea un inventario de migración con una lista de todos los repositorios en sus orígenes de migración que vas a migrar. Este deberá recoger datos como: nombre, propietario, URL, última marca de tiempo actualizada, número de solicitudes de extracción, número de emisiones.
Sea cual sea el enfoque que elijas para tu inventario, toma nota del proceso que seguiste o de los comandos que ejecutaste. Una vez que tengas la lista de repositorios, puedes elegir cuál migrar. Será también la oportunidad perfecta para evaluar y eliminar los que no sean necesarios, lo que simplificará mucho la migración.
Medir los tamaños
Cuando ya tengas tu inventario de migración básico, recopila información sobre el tamaño de tus repositorios. Si son grandes pueden hacer que la migración sea más larga y limitar las herramientas disponibles.
Si utilizas Git como sistema de control de versiones, no solo importan los archivos grandes, también el historial del repositorio. Para continuar, deberás agregar los siguientes datos al inventario para cada repositorio: el tamaño de archivo más grande (blob) y el tamaño total de todos los archivos (blobs).
Si, por el contrario, usas un sistema de control de versiones diferente o los archivos no son rastreados por ninguno, primero deberás mover los repositorios a Git. Y, posteriormente, utilizar git-sizer para obtener estos datos.
Decidir el tipo de migración
Al decidir qué tipo de migración se va a elegir, se deben considerar las necesidades de tu empresa y las herramientas disponibles. De hecho, se pueden elegir estrategias diferentes según el tipo de repositorio.
Los tres enfoques para hacerlo son:
- Instantáneo de origen: se migra el estado actual del código, sin nada del historial de revisiones. Es posible para todos los orígenes y destinos, incluso si el código aún no está rastreado en un sistema de control de versiones.
- Fuente e historia: se migra el estado actual del código y su historial. Solo es posible si los cambios están rastreados en Git o en un sistema de control de versiones que se pueda convertir a Git antes de la migración.
- Fuente, historia y metadatos: se migra el código actual, su historial de revisiones y el de colaboración (problemas, solicitudes de extracción y configuraciones). Requiere de herramientas especializadas que no están disponibles para todas las rutas de migración.
Diseñar la estructura de la organización
Cada repositorio pertenece a una organización, las cuales son cuentas compartidas donde las empresas y los proyectos de código abierto pueden colaborar en varios proyectos a la vez.
Por ello es tan importante definir la estructura más efectiva para cada organización y repositorio después de la migración. Este diseño puede maximizar la colaboración y minimizar la carga administrativa, o crear silos y gastos innecesarios.
La recomendación que hacen desde GitHub es minimizar el número de organizaciones y estructurarlo según uno de cinco arquetipos.
Realizar una prueba
Antes de continuar con la planificación, es muy útil realizar una migración de prueba que incluya todos tus repositorios.
Este ensayo te permitirá verificar que las herramientas elegidas funcionan para tu caso, que cumplen tus requisitos, comprenderás mejor qué datos se migran y cuáles no, así como el tiempo que llevará la migración.
Planificación de los pasos previos y posteriores
Habrá algunos datos o configuraciones que deberás hacer de forma manual. Los pasos necesarios para hacerlo dependerán de cada circunstancia específica, pero los previos más importantes son:
- Informar a tus usuarios sobre el timing de la migración.
- Configurar cuentas de usuario para el equipo.
- Enviar instrucciones para actualizar los repositorios locales que apunten al nuevo sistema
También hay que tener en cuenta los pasos post-migración:
- Informar a los usuarios de que la migración ha finalizado.
- Vincular la actividad a los usuarios en su destino de origen.
- Desmontar el origen migratorio.
Migración de integración continua (CI) y entrega continua (CD)
Si ya te estás moviendo entre productos de GitHub, estarás usando GitHub Actions para CI/CD y no habrá que hacer gran cosa al respecto, pues los archivos de flujo de trabajo en tus repositorios se migrarán automáticamente.
Si, por el contrario, no usas GitHub Actions, la situación es más complicada. Deberás verificar que el proveedor de CI/CD sea compatible con GitHub y conectarlo a la nueva organización y repositorios.
Sin embargo, si quieres cambiar a GitHub Actions, no es recomendable hacerlo al mismo tiempo que migras tus repositorios. Es mejor esperar hasta que haya terminado y migrar el CI/CD como un paso separado.
Gestión de equipos y permisos
Si migras el historial de colaboración o los metadatos, deberás vincular la actividad de los usuarios a sus nuevas identidades en el destino de migración. El proceso de atribución es el que te permitirá hacerlo.
Luego podrás crear tus equipos y agregar miembros del equipo antes de migrar tus repositorios. Los podrás administrar a través de tu proveedor de identidad (IdP), vinculando tus equipos a grupos de IdP.
Partner GitHub Migration
A la hora de hacer la migración puedes optar por una migración de autoservicio, en la que planificas y ejecutas tu propia migración, sin ningún soporte profesional de GitHub. Sin embargo, la mejor opción es confiar en un profesional de la materia en la que podrás beneficiarte del conocimiento y experiencia de un experto.
Si necesitas contar con un partner especializado y no sabes a quién elegir, te damos varias razones para escoger a Plain Concepts:
- Somos el primer partner en España acreditado por GitHub.
- Llevamos más de 17 años trabajando en la cultura Agile referente en la comunidad DevOps.
- Contamos con un equipo especializado compuesto por más de 350 ingenieros senior en App Innovation y DevOps.
- Acreditados como AMMP.
- DevSecOps con MVPs.
Conseguirás numerosos beneficios, como: los puntos clave de las migraciones y escollos a evitar, capacitación de tu personal para las próximas migraciones, documentación sobre el proceso de migración y, finalmente, los repositorios migrados.
Si quieres comenzar ya con la migración, no esperes más para contactar con nosotros y nuestro equipo de expertos estará encantado en ayudarte a ponerla en marcha.
