Guía paso a paso para migrar a Git desde Perforce

Como comentamos en el artículo anterior, Git es ahora el estándar de facto para la gestión de configuración de software (SCM) en casi cualquier tipo de desarrollo digital. Pero si tienes años de historial valioso en Perforce, probablemente estés sopesando los costes que implica el cambio. En este artículo, abordaremos esas inquietudes de frente y te explicaremos cómo migrar datos a Git. Hemos dividido el proceso de migración de Perforce a Git en ocho pasos:

• Traslado de datos de Perforce
• Asignación de usuarios y permisos a un nuevo repositorio de Git
• Archivos binarios grandes
• Dependencias complejas
• Estructuración de tu equipo durante la migración
• Replicación de datos
• Herramientas de ALM
• Cómo definir el éxito después de una migración de Perforce a Git

Paso 1: Traslado de datos de Perforce

Hay dos estrategias generales para trasladar datos de Perforce a Git. Antes de profundizar en este tema, debemos tener en cuenta una diferencia fundamental entre la forma en que se gestionan los proyectos de software en Perforce y Git.

Un servidor de Perforce puede alojar decenas o cientos de proyectos de software distintos, cada uno con su propio modelo de creación de ramas. Un desarrollador define una “vista” que indica al servidor de Perforce qué archivos poner en una copia de trabajo. Por otro lado, un repositorio de Git normalmente contiene un solo proyecto de software con sus ramas y etiquetas (aunque existen grandes repositorios de Git monolíticos). Por lo general, clonas el repositorio y, de forma opcional, revisas los submódulos o subárboles.

Por lo tanto, el proceso de traslado de los datos tiene dos partes: extraer datos de Perforce y traducirlos en un conjunto equivalente de repositorios de Git.

Opción 1 para trasladar los datos de Perforce: usar Git Fusion

Si quieres conservar todo tu historial de datos de Perforce, puedes usar la propia herramienta Git Fusion de Perforce para extraer una sección de un servidor de Perforce (un solo proyecto) e incorporarla a un repositorio de Git. Básicamente, tienes que hacer esto:

• Instalar Git Fusion
• Configurar las vistas correctas de tus datos, incluida la estructura de creación de ramas
• Usar cualquier cliente de Git para clonar desde Git Fusion
• Enviar tu repositorio a Bitbucket

 Ejemplo práctico *Para seguir los pasos de este ejemplo, necesitarás un servidor de Perforce con Git Fusion ya operativo.* Supongamos que tienes un proyecto de Perforce alojado en la ruta de repositorio //depot/acme/... (en la sintaxis de la vista de depósito de Perforce). Tiene tres ramas: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Ten en cuenta que con Perforce ves las ramas como directorios adicionales en el árbol. El primer paso es configurar Git Fusion para que comprenda la relación de ramificación en Perforce. Para ello, crea un archivo de configuración de repositorio: [@repo] description = Acme project charset = utf8 [main] git-branch-name = main view = //depot/acme/main/… … [r1.0] git-branch-name = r1.0 view = //depot/acme/r1.0/… … [r1.1] git-branch-name = r1.1 view = //depot/acme/r1.1/… … Envía este archivo a Perforce en la ruta //.git-fusion/repos/acme/p4gf_config Ahora crea un proyecto vacío llamado “acme” en Bitbucket con las herramientas de administración normales de Bitbucket. Puedes configurar el control de acceso y los miembros del equipo como suelas hacerlo. A continuación, clona desde Git Fusion: git clone https:///acme cd acme git remote add bitbucket  git push –u --all bitbucket git push --tags Bitbucket ¡Eso es todo! Ahora deberías ver el historial importado en Bitbucket.

No obstante, es posible que esto no produzca una copia 100 % fiel de tus datos de Perforce. Hay algunas operaciones de Perforce, como las fusiones parciales, que simplemente no tienen equivalente en Git. Pero, en general, este método obtendrá la mayor parte de tu historial sin demasiado esfuerzo.

Ten en cuenta que conservar los últimos 10 años del historial de creación de ramas de una SCM heredada no implica que tengas que seguir utilizando el mismo flujo de trabajo. En particular, deberías plantearte adoptar flujos de trabajo de ramas de función como Git Flow como un primer paso práctico.

Pros y contras

• Es la opción que requiere más trabajo de configuración y tiempo de ejecución
• Conserva una parte mayor del historial, lo que te permite prescindir de tu servidor de Perforce antiguo
• Mantiene el modelo de creación de ramas que se usaba en el historial

Opción 2 para trasladar los datos de Perforce: empezar desde cero

La otra opción es empezar desde cero. Olvídate de complicaciones con el historial: simplemente extrae el head (extremo) de cada rama de Perforce que corresponda a tu proyecto e incorpóralos todos a un nuevo repositorio de Git vacío. Para hacerlo, debes tener espacios de trabajo de Perforce definidos con una “vista” correcta de los datos que quieres.

Esta es la técnica más sencilla y rápida. No importa lo complicado que sea tu historial de Perforce: tu nuevo repositorio de Git será sencillo y eficiente, y tendrás la oportunidad de iniciar un nuevo flujo de trabajo basado en Git sin cargas acumuladas.

El principal inconveniente es que probablemente te convenga conservar el antiguo servidor de Perforce en modo de solo lectura por si alguien necesita consultar el código antiguo. No tendrás que pagar costes de licencia, pero implica mantener activo el servidor antiguo durante un tiempo.

 **Ejemplo práctico** Ve a tu espacio de trabajo de Perforce (el directorio donde se extrae con checkout la rama principal de los datos de tu proyecto) y ejecuta: p4 sync Este comando obtiene la última revisión de tus archivos. Ahora crea un proyecto vacío llamado “acme” en Bitbucket con las herramientas de administración normales de Bitbucket. Puedes configurar el control de acceso y los miembros del equipo como suelas hacerlo. A continuación, crea un nuevo repositorio de Git en tu espacio de trabajo y envíalo a Bitbucket: git init . git remote add origin  git push –u --all origin git push --tags origin Ahora deberías ver la instantánea más reciente de tu código como la primera confirmación en tu nuevo proyecto de Bitbucket.

Pros y contras

• Es un método rápido y sencillo
• Te permite rediseñar el modelo de creación de ramas y el flujo de trabajo
• Tienes que mantener el antiguo servidor de Perforce con acceso de solo lectura

Paso 2: Usuarios y permisos

Después de mover los datos, la siguiente tarea suele ser empezar a asignar tus usuarios y permisos a nuevos proyectos de Bitbucket. Si usas el protocolo LDAP para el directorio de usuarios, ahorrarás tiempo en este paso. Si no es así, puedes extraer fácilmente un conjunto de cuentas de usuario de Perforce con el comando “p4 users –o” y luego introducirlas en cada proyecto de Bitbucket.

Traducir los permisos de Perforce a permisos equivalentes de Bitbucket puede resultar difícil, ya que los permisos de Perforce son detallados y complejos, con la posibilidad de excluir el acceso a archivos individuales. Este complicado esquema de permisos es una de las razones por las que puede ralentizarse un servidor de Perforce: cada intento de acceso puede causar que el servidor tenga que hacer un procesado costoso en una estructura de datos complicada.

En la mayoría de los casos, es más rápido pedir a los responsables del proyecto que definan un conjunto más sencillo de permisos en Bitbucket utilizando los permisos normales a nivel de proyecto, repositorio y rama. De hecho, conviene que revises tu configuración de permisos de todos modos, ya que Git ofrece muchas opciones nuevas de flujo de trabajo. Por ejemplo, puede que hayas restringido la creación de ramas en Perforce, mientras que en Bitbucket puede que solo necesites restringir el acceso mediante push a la rama principal.

Paso 3: Archivos binarios

Si habías almacenado blobs binarios grandes en Perforce, piensa detenidamente en cómo quieres gestionarlos en Git. Puedes probar Git LFS o simplemente usar un sistema de gestión de artefactos normal. En cualquier caso, no conviene que envíes a ciegas blobs grandes a un repositorio de Git.

Paso 4: Dependencias complejas

Puedes mapear una copia de trabajo de Perforce en copias de solo lectura de datos de varios módulos. En Git, esto se hace mediante submódulos, subárboles o sistemas de gestión de artefactos o CI/CD. No hay una solución fácil, pero algunas herramientas de importación de datos pueden modelar una relación de submódulos entre repositorios de Git. Puedes obtener más información sobre cómo usar submódulos o subárboles en este enlace: https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/.

Paso 5: Cómo estructurar tu equipo durante la migración

Pongamos que tu servidor de Perforce tiene 100 proyectos de 10 equipos. Tienes una estrategia y un conjunto de herramientas para la migración. Solo queda programar el periodo de mantenimiento y listo, ¿no?

Ojalá fuera tan sencillo...

Recuerda que cambiar de herramienta de SCM afecta tanto a los desarrolladores como a los datos. Tienes que tener en cuenta las personas, los procesos y los plazos; no te precipites, es demasiado arriesgado.

Debes crear un plan de proyectos durante la fase de migración (puede que sea un buen momento para probar un nuevo flujo de trabajo de Jira). Estas son algunas opciones que puedes plantearte:

• Migrar equipo por equipo y proyecto por proyecto. Intenta comenzar un proyecto y un equipo al comienzo de un sprint o incremento del programa, cuando tengas tiempo para adaptarte.
• Migrar de forma incremental. Importa todos tus datos en un fin de semana, pero luego deja que los equipos completen lentamente el cambio a Git con el tiempo. Recoge periódicamente los deltas volviendo a ejecutar tus herramientas de importación. Aunque es más compleja, esta estrategia es buena si tienes dependencias entre equipos y los primeros usuarios necesitan al menos una instantánea reciente en Git para alimentar su canalización de CI/CD.
• Utilizar ambos sistemas a la vez durante un tiempo. No es un método para cualquiera, pero es técnicamente factible usar Git Fusion para hacer un intercambio de datos bidireccional, siempre y cuando no se realicen operaciones complejas que interfieran en el traslado de datos.

Por último, asegúrate de informar de los cambios al equipo: los motivos y los pasos para hacerlo. Elige un equipo “pionero” que incluya ingenieros que tengan experiencia con todo el ciclo de vida del desarrollo de software y haz que ese equipo sea un modelo para los demás. Busca expertos en Git que ayuden a quienes tengan dificultades. Hacer cambios pequeños, comprensibles e iterativos ayudará a que este proceso sea todo un éxito.

Paso 6: Réplicas y clústeres

Perforce tiene un sistema simple pero eficaz de replicación de datos en sitios remotos para reducir el efecto de la latencia. Tiene un sistema más complejo para ejecutar un conjunto de réplicas locales para la agrupación en clústeres de solo lectura. Aunque la latencia no es una gran preocupación en Git, si estás ejecutando una operación a nivel mundial, deberías plantearte utilizar Bitbucket Data Center tanto para la agrupación en clústeres como para la replicación, ya que acelerará enormemente los tiempos de clonación de un equipo global.

Paso 7: Herramientas de ALM

Y ahora, buenas noticias: tienes muchas opciones para tu pila de herramientas de gestión del ciclo de vida de las aplicaciones (ALM) si pasas de Perforce a Git. Prácticamente todas las herramientas de ALM funcionan con Git, y prácticamente todos los desarrolladores trabajan con Git. Y, por supuesto, Bitbucket te ofrece una gran integración con Jira y Bamboo. A medida que hagas la transición a Git, puedes probar las funciones de Bamboo, como las ramas de plan, que aprovechan un flujo de trabajo de ramas de función.

Paso 8: Definición del éxito

Entonces, ¿cómo se mide exactamente el éxito durante una migración de Perforce a Git? En muchos proyectos de migración, tendemos a centrarnos demasiado en la fidelidad de la transferencia de datos. Pero esa métrica no es útil por muchos motivos. Es probable que nunca puedas obtener en Git un historial idéntico al de un sistema de SCM centralizado como Perforce.

Un enfoque más práctico es utilizar la CI/CD para la verificación. Después de cambiar tu canalización de CI/CD de Perforce a Git, ¿pasas todas tus pruebas sin problemas? ¿Y sigues pudiendo implementar tu software? Si todas tus compilaciones antiguas importantes aún pueden pasar por tu canalización de CI/CD, ¡es la hora de celebrarlo!

Has terminado

Ya has visto por qué hay tanto movimiento de Perforce a Git y cómo hacerlo. El siguiente paso es elegir una solución de Git. Si te cambias de Perforce a Git para el desarrollo de juegos, descubre por qué a los desarrolladores de juegos les encanta Bitbucket.