A step-by-step guide to migrating from Perforce to Git
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:
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:
Material relacionado
Cómo mover un repositorio de Git completo
VER LA SOLUCIÓN
Aprende a usar Git con Bitbucket Cloud
- 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
Hands-on example *In order to work through this example you’ll need a Perforce server with Git Fusion already operational.* Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Keep in mind that with Perforce you see branches as additional directories in the tree. Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file: [@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/… … Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, clone from Git Fusion: git clone https:///acme cd acme git remote add bitbucket git push –u --all bitbucket git push --tags Bitbucket That’s it! You should now see the imported history in 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.
**Hands-on example** Go into your Perforce workspace (the directory where the main branch of your project data is checked out) and run: p4 sync This fetches the latest revision of your files. Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, create a new Git repo in your workspace and push to Bitbucket: git init . git remote add origin git push –u --all origin git push --tags origin You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.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
A Perforce working copy may actually map in read-only copies of data from several modules. In Git, this is done either using submodules, subtrees, or by leveraging CI/CD or artifact management systems. There’s no easy answer here, but some data import tools can model a submodule relationship between Git repos. For a more in depth look on how to use submodules or subtrees, you can read about each here: https://www.atlassian.com/git/tutorials/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.
Step 6: Mirrors and clusters
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.
Step 7: ALM tools
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.
Compartir este artículo
Tema siguiente
Lecturas recomendadas
Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.
Blog de Bitbucket
Ruta de aprendizaje de DevOps
