056.2 Lección 1

El sistema de gestión de código fuente es el corazón de un proyecto de software. Aunque se realizan trabajos importantes en foros de debate y otros lugares, el sistema SCM representa tanto la historia del proyecto como su estado actual como entidad viva.

El repositorio de código fuente es una especie de taller digital para un proyecto. Así como un taller físico almacena todas las herramientas y elementos necesarios para fabricar una pieza de trabajo, un repositorio de código fuente almacena todos los archivos, documentos y códigos relacionados con un proyecto de software. Proporciona un entorno estructurado para organizar y gestionar los activos del proyecto.

La información se almacena normalmente en forma de árbol de directorios. Los sistemas SCM suelen utilizar un modelo cliente-servidor, en el que cualquier usuario puede extraer datos del repositorio y también introducirlos en este. El sistema lleva un registro de quién realizó cada cambio y cuándo se realizó, lo que garantiza la transparencia y la rendición de cuentas dentro del equipo.

Imagina que estás trabajando en un proyecto con varios desarrolladores y se descubre un error en el código. Con un SCM, puedes examinar fácilmente los cambios entre versiones para identificar el cambio de código específico responsable del error.

Como el sistema recuerda cada versión de los archivos a medida que cambian, un usuario tiene acceso a cualquiera de estas versiones y puede volver a versiones anteriores (en caso de que se hayan realizado cambios incorrectos). Por lo tanto, el repositorio también es una especie de archivo, que otorga acceso a todos los cambios realizados en el proyecto y al estado del proyecto en cualquier momento de su historia.

Los sistemas SCM ahorran espacio al realizar un seguimiento de los cambios realizados en un archivo en lugar de almacenar el archivo completo cada vez que se realiza un cambio. Este eficiente método de almacenamiento garantiza que las versiones históricas sean accesibles sin consumir recursos excesivos.

Muchas herramientas, como la integración continua/entrega continua (CI/CD) y las pruebas, giran en torno al sistema SCM. Las personas también construyen su reputación a través del sistema al hacer que sus contribuciones sean visibles para todos. Por lo tanto, la gestión del código fuente no se trata solo de realizar un seguimiento de los cambios; se trata de preservar la integridad de su base de código y fomentar la colaboración entre los desarrolladores, lo que garantiza que sus proyectos puedan evolucionar en un panorama dinámico y en constante cambio.

Los sistemas SCM más populares son Git, Subversion y CVS. Al igual que muchas otras funciones de software, SCM suele ser proporcionado por proveedores especializados. En otras palabras, es un software como servicio (SaaS) o un servicio “en la nube”: los participantes tienen el software en sus sistemas locales para gestionar sus cambios personales, pero cargan sus cambios en un repositorio central que se beneficia de las características típicas de la nube, como tiempo de actividad 24 horas al día, 7 días a la semana, copias de seguridad y acceso seguro.

Millones de desarrolladores utilizan ahora servicios en la nube, en particular GitHub. GitLab es una alternativa basada en código abierto. Tanto GitHub como GitLab permiten a las personas trabajar en los repositorios en la nube del proveedor o configurar una versión local del sistema SCM. Una ventaja de trabajar en esos sistemas es la reputación que se puede ganar a través de sus sistemas de “estrellas”, que permiten a los usuarios calificar el trabajo de los demás. Los servicios en la nube añaden atracciones adicionales, como rastreadores de solicitudes de cambio, sistemas de calificación, wikis y foros de debate.

Los repositorios pueden contener tanto proyectos personales como corporativos, lo que significa que no son necesariamente exclusivos del uso empresarial. Cualquier desarrollador que quiera iniciar un proyecto de desarrollo o trabajar en un proyecto de código abierto, copiándolo y modificándolo según sus necesidades, puede hacerlo. En todos estos casos, es importante tener un control firme sobre quién puede acceder a su repositorio.

Comprender la terminología relacionada con el control de versiones y la gestión del código fuente es fundamental para comprender su uso. En las siguientes secciones, analizamos en profundidad algunos de estos conceptos y términos.

Un desarrollador crea una confirmación (commit) cada vez que hace un cambio en el repositorio. Las confirmaciones representan instantáneas de los cambios realizados en el código base en un momento determinado. Cada confirmación incluye metadatos como el nombre del autor, una marca de tiempo y un mensaje descriptivo que explica los cambios. Las confirmaciones ayudan a los desarrolladores a realizar un seguimiento de la evolución del código base y comprender el historial de cambios específicos.

Considere un equipo de desarrolladores que trabaja en una aplicación web. Cada vez que realizan cambios en el código base, crean una confirmación para documentar esos cambios. Por ejemplo, alguien que agrega una nueva característica a la aplicación puede crear una confirmación con un mensaje como “Se agregó una característica de autenticación de usuario”. Esta confirmación captura el estado del código base después de que se implementó la característica.

Cuando un desarrollador corrige un error, el mensaje de confirmación generalmente se refiere al número del error en el sistema de seguimiento de errores del proyecto.

Las etiquetas (Tags) son referencias con nombre a confirmaciones específicas. Por lo general, marcan puntos importantes en el historial del proyecto, como lanzamientos o hitos. Las etiquetas proporcionan una forma de etiquetar y hacer referencia a versiones importantes del código base, lo que facilita la gestión y la navegación por el historial del proyecto.

Las ramas (branches) entran en juego cuando los desarrolladores necesitan trabajar en diferentes tareas al mismo tiempo. Las ramas son líneas de desarrollo independientes que se apartan del código base principal. Permiten a los desarrolladores trabajar en funciones o correcciones de forma aislada sin afectar el código principal hasta que estén listos para la integración. Las ramas ayudan a organizar los esfuerzos de desarrollo y facilitan la colaboración entre los miembros del equipo.

Por ejemplo, un desarrollador está trabajando en agregar una nueva característica a la aplicación mientras otro está solucionando un error. Cada uno puede crear ramas separadas para aislar sus cambios. Una vez que su trabajo esté completo, pueden fusionar (merge) sus ramas nuevamente en la base de código principal (<<branches> >).

Cuando varias personas trabajan en el mismo archivo o están enviandolos en otra rama, en ocasiones puede suceder que dos personas realizan un cambio en la misma línea de ese archivo. Cuando la segunda persona que realiza un cambio intenta despacharlo, el sistema advierte de un conflicto.

Algunos VCS simplemente no permiten que un desarrollador registre un archivo si contiene un conflicto con la versión actual en el repositorio. El desarrollador debe verificar la versión actual y averiguar cómo resolver el conflicto, y luego registrar una nueva versión.

Los sistemas basados en la nube ofrecen solicitudes de fusión o de extracción. Estas solicitudes las crea un desarrollador que ha trabajado en un sistema o rama local y cree que sus cambios son adecuados para incluirlos en otra rama. Los desarrolladores de la rama de destino deciden si aceptan la solicitud.

A menudo sucede que para el desarrollo de un proyecto de software (por ejemplo, un sitio web complejo) se necesita el código de otro proyecto independiente (por ejemplo, un reproductor multimedia). En lugar de copiar el código del reproductor multimedia en parte o en su totalidad en su propio proyecto, muchos VCS ofrecen la función de subrepositorios, también conocidos como submódulos.

En nuestro ejemplo, el repositorio del reproductor multimedia se integra en el repositorio del sitio web como subrepositorio. Aparece como un directorio independiente en el árbol de directorios. Esto significa que la base de código del reproductor multimedia está completamente disponible, pero sigue siendo independiente. Si es necesario, incluso se puede actualizar desde el repositorio original del reproductor multimedia. Esta capacidad resulta valiosa para gestionar proyectos complejos con numerosas dependencias o para integrar bibliotecas y marcos de terceros en una base de código. Los submódulos mejoran la organización del proyecto y facilitan la colaboración al permitir que los desarrolladores trabajen con bases de código interconectadas de manera eficiente.

Cada participante de un proyecto comienza creando una identidad, normalmente vinculada a su dirección de correo electrónico única. Un sistema basado en la nube administra las identidades a través de cuentas, como lo hacen los sitios de redes sociales y otras organizaciones.

Los nuevos desarrolladores pasan por una secuencia como la siguiente cuando utilizan un sistema SCM:

Los administradores de proyectos deciden en quién confiar y en quién dar acceso al repositorio. Los desarrolladores senior tienen la importante responsabilidad de decidir cuándo los cambios enviados por otros colaboradores están listos para incluirse en la rama principal del repositorio.

En los sistemas basados en la nube, el propietario de un proyecto puede controlar la accesibilidad de un repositorio configurando su visibilidad como pública o privada. Los repositorios públicos otorgan acceso de lectura a cualquier persona en Internet. Sin embargo, los repositorios privados limitan el acceso únicamente al propietario, a las personas con las que el propietario ha compartido explícitamente el acceso y, en el caso de los repositorios de la organización, a miembros específicos de la organización.

Imaginemos un equipo de desarrolladores que trabaja en un sitio web de comercio electrónico. Deciden añadir una nueva función que permita a los clientes realizar un seguimiento de sus pedidos. Para implementar esta función, crean una rama de funciones con un nombre como seguimiento de pedidos (order-tracking), donde pueden trabajar en los cambios de código necesarios sin afectar al código base principal. Una vez que la función está completa y probada, fusionan esta rama con la rama de desarrollo principal para una mayor integración y prueba.

La rama de desarrollo principal funciona como un punto central donde se reúnen todas las nuevas funciones para realizar pruebas. Por ejemplo, si varios desarrolladores trabajan en distintas funciones al mismo tiempo, pueden fusionar sus ramas de funciones en la rama de desarrollo para garantizar que todo funcione en conjunto sin problemas. Este proceso de integración ayuda a identificar y resolver cualquier conflicto o problema de compatibilidad desde el principio.

Cuando llega el momento de lanzar una nueva versión del sitio web de comercio electrónico, el equipo crea una rama de lanzamiento, como v2.0, a partir de la rama de desarrollo. Se concentran en estabilizar la base de código, corregir errores de último momento y realizar pruebas exhaustivas para garantizar un lanzamiento sin problemas. Una vez que el lanzamiento está listo, el código de la rama de lanzamiento se implementa en producción y el ciclo comienza de nuevo.

Algunos de los sistemas de control de versiones más conocidos son Git, Subversion (también conocido como SVN) y CVS. Todos ellos son de código abierto.

Git es un sistema de control de versiones distribuido que se utiliza ampliamente en el desarrollo de software y en otros campos. Al utilizar Git, cada desarrollador tiene una copia completa del código base en su computadora.

Este enfoque descentralizado permite a los desarrolladores trabajar sin conexión y colaborar sin problemas, sin depender de un servidor central. Es decir, los desarrolladores pueden trabajar de forma independiente en diferentes funciones o correcciones y combinar sus cambios sin problemas. Incluso si el servidor central se desconecta, los desarrolladores pueden seguir trabajando y compartir actualizaciones entre ellos.

Pensemos en el desarrollo del núcleo Linux, que inicialmente dependía de un sistema de control de versiones centralizado llamado BitKeeper. Cuando se revocó el estatus gratuito de BitKeeper, Linus Torvalds y la comunidad Linux desarrollaron Git como una alternativa distribuida. Esta decisión permitió el desarrollo no lineal y la gestión eficiente de proyectos grandes como el núcleo Linux. El éxito de Git para el núcleo Linux (un proyecto extremadamente complejo con miles de desarrolladores e innumerables ramas) muestra el poder y la escalabilidad de Git.

Hoy en día, la mayor parte del desarrollo de software utiliza Git. Las ofertas de SaaS extremadamente populares se basan en este.

Git trata los conflictos entregando al desarrollador un archivo con ambas versiones de la línea modificada, y marcando claramente de qué versión del archivo provienen las líneas. El desarrollador debe decidir cómo resolver el conflicto y registrar una versión coherente del archivo.

Subversion (SVN) probablemente fue el sistema de gestión de contenido más popular antes de que se inventara Git. A diferencia de Git, Subversion está centralizado: el historial de versiones reside en un servidor central. Los desarrolladores se conectan a este servidor para realizar cambios, lo que garantiza que todos trabajen con la última versión del código base.

Supongamos que forma parte de un equipo que trabaja en un proyecto que utiliza Subversion. Cada vez que necesita realizar cambios en el código base, se conecta al servidor SVN central para extraer una copia funcional del código. Esto garantiza que está trabajando con la versión más actualizada del proyecto. Después de realizar los cambios, los envía de nuevo al servidor y actualiza el repositorio central con las modificaciones. El flujo de trabajo centralizado ayuda a mantener la coherencia y garantiza que todos trabajen para alcanzar los mismos objetivos.

Antes de Subversion, CVS era un sistema de control de versiones centralizado muy popular. Tenía problemas de diseño que llevaron al diseño de Subversion como alternativa.