Topics Version control ¿Qué es un sistema de control de versiones centralizado?

¿Qué es un sistema de control de versiones centralizado?


Un sistema de control de versiones centralizado ofrece a los equipos de desarrollo de software una forma de colaborar mediante el uso de un servidor central.

Sistema de control de versiones centralizado (CVS)

En un sistema de control de versiones centralizado (CVCS), también conocido como control de fuente o sistema de control de revisiones centralizado, un servidor actúa como el repositorio centralizado principal que almacena todas las versiones de código. Al usar el control de fuente centralizado, cada usuario realiza las confirmaciones directamente a la rama principal, por lo que este tipo de control de versiones suele funcionar bien para equipos pequeños, porque los miembros del equipo tienen la capacidad de comunicarse rápidamente para que no haya dos desarrolladores que quieran trabajar en la misma pieza de código simultáneamente. La comunicación y la colaboración sólidas son importantes para garantizar el éxito de un flujo de trabajo centralizado.

Los sistemas de control de versiones centralizados, como CVS, Perforce y SVN, requieren que los usuarios extraigan la última versión del servidor para descargar una copia local en su máquina. Luego, los contribuidores envían las confirmaciones al servidor y resuelven cualquier conflicto de fusión en el repositorio principal.

Al tratarse de un modelo cliente-servidor, un flujo de trabajo centralizado permite bloquear archivos, de modo que cualquier parte del código que se esté comprobando en ese momento no será accesible para los demás, lo que garantiza que solo un desarrollador pueda contribuir al código a la vez. Los miembros del equipo usan ramas para contribuir al repositorio central, y el servidor desbloqueará los archivos después de las fusiones.

Ejemplos de sistemas de control de versiones centralizados

Los sistemas de control de versiones centralizados más comunes son Concurrent Versions System (CVS), Perforce y Subversion (SVN). También está Microsoft Team Foundation Server (TFS), que ahora se conoce como Azure DevOps Server.

Cabe destacar que, Git, el sistema de control de versiones más común no es un VCS centralizado, sino un VCS distribuido.

¿Cuáles son las ventajas de un sistema de control de versiones centralizado?

Funciona bien con archivos binarios

Los archivos binarios, como los activos gráficos y los archivos de texto, requieren una gran cantidad de espacio, por lo que los desarrolladores de software recurren a sistemas de control de versiones centralizados para almacenar estos datos. Con un servidor centralizado, los equipos pueden extraer algunas líneas de código sin guardar el historial completo en su máquina local. Los usuarios de sistemas distribuidos tienen que descargar todo el proyecto, lo que ocupa tiempo y espacio y les impide hacer diffs. Si un equipo trabaja habitualmente con archivos binarios, un sistema centralizado ofrece el enfoque más eficiente para el desarrollo de código.

Ofrece visibilidad completa

Con una ubicación centralizada, todos los miembros del equipo tienen visibilidad completa del código en el que se está trabajando actualmente y de los cambios que se realizan. Este conocimiento ayuda a los equipos de desarrollo de software a comprender el estado de un proyecto y proporciona una base para la colaboración, ya que los desarrolladores comparten el trabajo en el servidor central. Un sistema de control de versiones centralizado solo tiene dos repositorios de datos que los usuarios deben monitorear: la copia local y el servidor central.

Disminuye la curva de aprendizaje

El control de versiones centralizado es fácil de entender y usar, por lo que los desarrolladores de cualquier nivel de habilidad pueden realizar cambios y comenzar a contribuir al código base rápidamente. La configuración del sistema y el flujo de trabajo también es simple, y no se requiere una inversión de tiempo significativa para establecer cómo el equipo de desarrollo de software debe usar la herramienta. Cuando los desarrolladores pueden navegar por un flujo de trabajo de forma rápida y sencilla, pueden centrarse en el desarrollo de funciones en lugar de memorizar una serie de pasos complicados para fusionar los cambios de versiones. Disminuir la curva de aprendizaje también ayuda a los nuevos desarrolladores a causar un impacto lo antes posible.

¿Cuáles son las desventajas de un sistema de control de versiones centralizado?

Un punto de falla único arriesga los datos

La mayor desventaja es el punto de falla único integrado en el servidor centralizado. Si el servidor remoto deja de funcionar, nadie puede trabajar en el código ni enviar cambios. La falta de acceso sin conexión significa que cualquier interrupción puede afectar significativamente el desarrollo de código e incluso provocar la pérdida de código. Todo el proyecto y el equipo se detienen durante una interrupción. En caso de corrupción del disco duro, los equipos de desarrollo de software deben confiar en las copias de seguridad para recuperar el historial de ejecución de un proyecto. Si las copias de seguridad no se guardaron correctamente, el equipo lo pierde todo. Al almacenar todas las versiones en un servidor central, los equipos corren el riesgo de perder su código fuente en cualquier momento. Solo se pueden recuperar las instantáneas en las máquinas locales, pero es una pequeña cantidad de código en comparación con todo el historial de un proyecto.

A diferencia de un VCS centralizado, un sistema de control de versiones distribuido permite a cada usuario tener una copia local del historial de ejecución en su máquina, por lo que si hay una interrupción, cada copia local se convierte en una copia de seguridad y los miembros del equipo pueden continuar el desarrollo sin conexión.

La velocidad lenta retrasa el desarrollo

Los usuarios del sistema de control de versiones centralizado suelen tener dificultades para ramificarse rápidamente, porque los usuarios deben comunicarse con el servidor remoto para cada comando, lo que ralentiza el desarrollo de código.

La ramificación se convierte en una tarea que requiere mucho tiempo y permite que aparezcan conflictos de fusión, porque los desarrolladores no pueden enviar sus cambios al repositorio central lo suficientemente rápido como para que otros los vean. Si los miembros del equipo tienen conexiones de red lentas, el proceso de desarrollo de código se vuelve aún más tedioso cuando se intenta conectarse con el servidor remoto.

La velocidad a la que operan los equipos de desarrollo de software tiene un impacto directo en la rapidez con la que pueden enviar funcionalidades y ofrecer valor comercial. Si los equipos tardan en desarrollar, la iteración y la innovación se estancan y los desarrolladores pueden frustrarse con el tiempo que tardan en ver sus cambios en la aplicación. Es posible que se pierdan lanzamientos si el servidor remoto o las redes están inactivos, y los miembros del equipo no podrán recuperar el tiempo perdido e impulsar rápidamente los cambios.

Pocos momentos estables para enviar los cambios

Un flujo de trabajo centralizado es fácil de utilizar para los equipos pequeños, pero hay limitaciones cuando los equipos más grandes intentan colaborar. Cuando varios desarrolladores quieren trabajar en la misma pieza de código, se hace difícil encontrar un momento estable para enviar los cambios. Los cambios inestables no se pueden enviar al repositorio central principal, por lo que los desarrolladores tienen que mantenerlos de manera local hasta que estén listos para su lanzamiento.

Debido a que los usuarios demoran en enviar los cambios, los proyectos de desarrollo de software pueden retrasarse y pueden surgir conflictos de fusión, porque el resto del equipo no tiene visibilidad de los cambios que solo existen en la máquina de un usuario. Una vez que los cambios finalmente se envíen al repositorio central, después de lidiar con los problemas de estabilidad y velocidad, los usuarios tendrán que resolver los conflictos rápidamente al realizar la fusión para garantizar que el resto del equipo pueda contribuir al código. La falta de estabilidad es lo que lleva a muchos equipos a migrar a un sistema de control de versiones diferente, como Git.

Conclusión

En el ámbito dinámico del desarrollo de software, un sistema de control de versiones centralizado (CVCS) surge como la piedra angular para los equipos que buscan una colaboración eficiente y procesos optimizados. Este sistema aprovecha la potencia de un servidor central para mantener un historial de versiones completo. Al permitir que los desarrolladores individuales contribuyan directamente a la rama principal, el CVCS simplifica el proceso de desarrollo.

La esencia del CVCS radica en su capacidad de ofrecer una plataforma unificada para el control de versiones, al garantizar que cada miembro del equipo trabaje con el código más reciente, mejorando así la productividad y fomentando una cultura de transparencia.

Descubra cómo GitLab moderniza el desarrollo de software

Pruebe GitLab

Descubra todo lo que su equipo puede lograr desde una única plataforma para la entrega de software.

Obtener prueba gratuita
Headshots of three people

¿Tiene alguna pregunta? Estamos aquí para ayudar.

Hablar con un experto