De Perforce a Git: por qué dar el paso

Workflow

Aparte de tener otras funciones, una herramienta de SCM sirve básicamente para trabajar en colaboración: permitir que un equipo de desarrolladores trabaje en un conjunto compartido de archivos de software. Git ofrece ramificaciones sencillas y computacionalmente económicas, lo que abre la puerta a una variedad de flujos de trabajo muy interesantes. Ramificación de tareas, Git Flow y repositorios bifurcados: hay un flujo de trabajo rápido y sencillo para cualquier tipo de equipo (tanto si desarrolla proyectos profesionales como de código abierto) con potentes herramientas de colaboración y revisión de código.

Git también facilita la colaboración más allá del entorno de la empresa, un requisito habitual en el desarrollo multifuncional. Incluso si no es posible acceder a un repositorio compartido de Git a través de una red física, las herramientas que ofrece la solución para crear parches y paquetes permiten compartir datos fácilmente.

Perforce, por otro lado, mantiene un registro de ramas por archivo, mientras que Git lo hace por confirmación. ¿Qué significa esto? Para empezar, genera una gran cantidad de metadatos en la base de datos de Perforce cada vez que creas una rama. Esto puede provocar que se produzcan problemas de rendimiento en implementaciones grandes, hasta el punto que muchos administradores de Perforce restringen la creación de ramas.

Imagínatelo por un momento: cada vez que quieras crear una rama de tareas para probar una nueva función, tendrás que pedir permiso. Si no puedes crear ramas de tareas, puedes insertar código inestable en la rama principal, o simplemente esperar hasta que "termines" antes de confirmar nada. Sacrificas la ventaja de tener CI/CD en tus ramas de tareas y poder realizar un seguimiento granular del trabajo en curso. El resultado final es una disminución de la productividad, ya que los desarrolladores se contentan con flujos de trabajo menos productivos o simplemente comienzan a usar Git de forma paralela y buscan la manera de fusionar manualmente su trabajo con Perforce.

Las ramas de Perforce, además de ser costosas, no favorecen el tipo de flujo de trabajo que prefieren la mayoría de los desarrolladores. Las ramas se comparten, por lo que no existe una rama de tarea privada con fusión periódica mediante cambio de base. Además, los algoritmos de fusión de Perforce son excesivamente complicados. Se han escrito artículos enteros que explican cómo fusionar archivos cuyo nombre se ha cambiado o cuyos atributos se han modificado.

¿Y cómo se comparte código entre servidores Perforce? Tienes que compartir archivos tar sin un historial común. El modelo de datos de Perforce mantiene el historial del software en un solo servidor. En cambio, con Git es muy fácil clonar y compartir el historial.

Popularidad y comunidad

Dejando a un lado a los competidores comerciales, ¿por qué Git ha superado a Mercurial y a otros competidores importantes? Sin duda, la potencia es significativa y Git la tiene. Git es una solución creada originalmente por Linus Torvalds para dar respuesta a las dificultades de desarrollo distribuido del proyecto kernel de Linux y, en la actualidad, es la herramienta de SCM estándar para Linux, Android, OpenStack y la mayoría de los demás proyectos de código abierto importantes. Es una herramienta muy popular, así que si eres responsable de selección de personal, probablemente puedes dar por sentado que un ingeniero nuevo puede (y querrá) trabajar con Git sin necesidad de recibir mucha formación.

Y, por supuesto, cuentas con toda la fuerza que aporta la dinámica comunidad de código abierto que hay detrás de Git. Git está evolucionando rápidamente para resolver problemas del mundo real, con la aparición de importantes funciones nuevas como Git LFS. Puedes aportar tu propio código al proyecto de Git si hay un error que quieras que se solucione y no tendrás las limitaciones propias de los productos comerciales que se ciñen a una hoja de ruta y un ritmo marcados por una sola empresa. Estos son los programas cliente de Git disponibles: varias GUI de escritorio potentes, integración con el Explorador de Windows, complementos para cada IDE y herramientas para desarrolladores.

GUI y herramientas para desarrolladores

Al principio, la GUI y las herramientas de Git presentaban ciertas carencias. Esto era un obstáculo para los usuarios que preferían una interfaz visual para interactuar con sus repositorios de Git, especialmente para los colaboradores que no tenían un perfil técnico, como los artistas de videojuegos. El complemento Explorador de Windows de Perforce fue un éxito entre este tipo de usuarios.

Pero, por suerte, esa época ya ha pasado a la historia. Hay interfaces como Sourcetree que ofrecen una experiencia interactiva y también hay numerosas integraciones de shell para Git. Bitbucket proporciona revisión de código, solicitudes de fusión e incorporación de cambios, bifurcación, navegación de código en línea y muchas otras herramientas de colaboración. De hecho, usuarios de todo tipo, desde científicos de datos hasta agencias creativas, están creando comunidades que utilizan la colaboración abierta que hacen posible Git y Bitbucket.

Los desarrolladores de videojuegos son un mundo aparte

Dicho esto, ¿qué ha impedido que algunas comunidades, como los desarrolladores de videojuegos y los investigadores que trabajan con grandes conjuntos de datos, sigan los mismos pasos que el resto de los usuarios? Básicamente, el tipo de datos y la complejidad de la organización de los proyectos.

Archivos binarios

Los desarrolladores de videojuegos, y en particular los artistas, necesitan trabajar con objetos binarios grandes como las texturas y los recursos de audio. Los científicos de datos pueden tener conjuntos de datos enormes con miles de millones de ejemplos de eventos.

Esto plantea dos problemas a Git.

• Estos archivos no se pueden fusionar. Es práctico tener un mecanismo de bloqueo centralizado. Perforce ofrece uno. Sin embargo, ten en cuenta que incluso los servidores centralizados solo ofrecen un mecanismo de bloqueo en una sola rama, por lo que usar esta función implica que el flujo de trabajo es muy restringido.
• Estos archivos hacen que Git se ralentice a medida que aumenta el tamaño del repositorio.

El problema del tamaño del repositorio se soluciona en gran medida con Git LFS, una extensión que permite a Git gestionar archivos grandes y delegar el almacenamiento de archivos real a otra función.

El problema del bloqueo de archivos requiere un examen en dos frentes. Desde la perspectiva de la gestión de la configuración de software, Git LFS ofrece un mejor tipo de bloqueo de archivos. Git LFS te permitirá coordinar el bloqueo de archivos binarios en varias ramas con un algoritmo que asegura que estés trabajando en la última versión, independientemente de la rama en la que te encuentres. Esto ofrece más flujos de trabajo de ramificación a los usuarios que trabajan con archivos binarios grandes, en comparación con el modelo de bloqueo de una sola rama de Perforce.

También hay que tener en cuenta que el bloqueo de archivos puede generar un problema de coordinación. Si vas a empezar a trabajar en un recurso compartido que no se puede fusionar, ¿cómo difundes ese conocimiento a todas las partes interesadas? Una vez más, aquí es donde resultan especialmente útiles los flujos de trabajo modernos que utilizan solicitudes de incorporación de cambios y la colaboración en equipo en tiempo real. Puedes comunicar rápidamente tus intenciones a través de HipChat y comprobar si hay algún trabajo pendiente en curso en un archivo concreto.

También es interesante considerar cómo evolucionará el problema de la gestión de archivos grandes en la era del Big Data. Para probar un trabajo de análisis de Big Data, es posible que necesites un conjunto de datos de varios terabytes de tamaño. Olvídate de usar un sistema de SCM; este proyecto se prueba y se ejecuta en un sistema de archivos compatible con Big Data. Lo que se necesita aquí es un sistema de CI/CD que pueda orquestar una canalización más compleja con artefactos que residen en HDFS o S3. Esto nos lleva al siguiente tema.

Proyectos grandes

El desarrollo de videojuegos es un ejemplo típico de proyecto de software con varios módulos o componentes: el motor del juego, la interfaz de usuario, el arte estático, las representaciones de vídeo, etc. Perforce, al ser un repositorio centralizado monolítico, puede alojar todos estos módulos en un único servidor y permitir que los usuarios elijan qué partes quieren incluir en su propio espacio de trabajo.

Sin embargo, esta ventaja ahora es bastante discutible. Los sistemas Git modernos como Bitbucket permiten gestionar más fácilmente las herramientas de varios módulos de Git, como los submódulos y los subárboles. Y lo que es más importante, proyectos grandes como Android han demostrado que se puede gestionar un proyecto complejo con herramientas de composición de nivel superior. Muchas de estas lecciones se han incorporado a herramientas modernas de CI/CD como Bamboo y Bitbucket Pipelines, que pueden orquestar flujos de trabajo complejos de integración continua, modelar las dependencias entre proyectos y gestionar artefactos entre proyectos.

Esta tendencia sigue en gran medida la filosofía de Git (y *nix) de crear una herramienta que haga un solo trabajo muy bien. La integración continua y la entrega continua (CI/CD) son una práctica en sí misma, con herramientas dedicadas a comprender el flujo de trabajo de compilación y publicación. También siguen las prácticas recomendadas de desarrollo de software moderno, que apuestan por utilizar pequeños microservicios independientes en lugar de proyectos monolíticos.

Pasos siguientes

Está claro que la transición de "Perforce a Git" está ganando adeptos, y que Git y las herramientas modernas de CI/CD ahora están preparadas para gestionar las tareas de desarrollo más grandes y complejas. De hecho, Perforce incluso ha creado una herramienta llamada Git Fusion que permite extraer parte de un repositorio central de Perforce como repositorio de Git.

Lamentablemente, si bien Git Fusion ha sido un esfuerzo admirable, intentar colocar Git en un sistema de SCM centralizado no es muy fácil; si intentas mezclar tus modelos de uso, puedes dañar fácilmente la vista de los datos de un sistema. Si no mezclas tus modelos de uso, es difícil ver el valor que tiene poner un backend centralizado de uso comercial detrás de Git. La tendencia, como hemos visto, va justo en la dirección contraria: ¿cómo se colocan en Git las últimas piezas restantes de SCM centralizado que fueron útiles?

Si utilizas Perforce para desarrollar software o videojuegos, probablemente te estés preguntando (impacientemente) cómo migrar a Git. ¿Cómo se hace? ¿Compensa el coste que supone el cambio? Eso es exactamente lo que trataremos en el próximo artículo.