Sistema de control de versiones, autoritarismo y libertad de codificar

Sistema de control de versiones, autoritarismo y libertad de codificar

El Control de Versiones es hoy en día imprescindible para el Desarrollo Continuo de software: viene a ser la base de la Liberación e Implementación Continua Software.

En anterior artículo, desarrollado de manera un tanto extensa, os describimos cómo en Pandora FMS NG estamos empeñados en aumentar nuestra flexibilidad y añadir mejores características (y por supuesto corregir las excepciones de programación lo más pronto posible). Al momento de escribir estas líneas hemos liberado la versión 723… ¿y por qué hablo en plural como tercera persona, “hemos liberado”? Mejor aun, ¿qué demonios tiene que ver el Control de versiones en todo esto?

Introducción

Como bien sabréis, Pandora FMS consta de dos componentes: la base, que es la versión hecha en código abierto, la cual es completamente funcional y tan cierta es esta afirmación que para poder usar la versión empresarial primero debemos instalar y configurar la versión comunitaria y luego actualizar. Si tenéis hasta 100 dispositivos que monitorizar pues no necesitáis más; sin embargo, si son miles los dispositivos os recomendamos “Enterprise” (su nombre en inglés y que nos recuerda tanto a la nave de la serie de televisión “Star Trek”): con consultaría y soporte para los clientes y características adecuadas para administrar toda vuestra flota de naves… ¡perdón, ordenadores!

Breve historia

Hasta este punto no os hemos hablado del Control de Versiones pero aquí vamos: nuestra versión en código abierto (“open source” en inglés) está alojada en línea, donde podréis revisar, línea a línea, comando por comando, los diferentes componentes y donde publicamos frecuentemente las modificaciones al sistema Pandora FMS: eso, de hecho, es un Sistema de Control de Versiones.

¿Cómo hemos llegado hasta este punto, esta forma de trabajar y mantener nuestros queridos algoritmos? Hagamos memoria y veamos un panorama de manera general. Mantened vuestras mentes abiertas.

La década de 1980

Sí, nos tocó vivir esa época cuando el uso de la hoja de cálculo fue la “aplicación asesina” que impulsó la compra en masa de los ordenadores personales para pequeños negocios y algunos hogares. Para llevar un “Control de Versiones” de nuestros documentos simplemente copiábamos en otro disco flexible, haciendo una carpeta con el título correspondiente acompañado de fecha y hora (también en el nombre del directorio). Simple, ¿no?

El problema venía luego: saber de cual disco podíamos recuperar algo que habíamos borrado o cortado. Los más avezados, para cada semana o mes, titulaban un disco con el nombre del dueño y el período histórico y como vemos ya íbamos dando forma a un rudimentario Control de Versiones. Si os lo preguntáis, la situación no era muy diferente ni distante en las empresas y universidades para documentos de propósito común.

La década de 1990

Ya con el aumento de la potencia de los ordenadores y el tamaño y precio asequible de los discos duros, pues dejamos todo allí con diferentes directorios tal como comentamos. El Internet estaba pespunteando el alba y con procesadores más veloces tuvimos la oportunidad de tener programas que comprimían y descomprimían ficheros y mantenían la estructura y jerarquía de los directorios que la contenían. Algunos programas procesadores de palabras comenzaron a llevar un Control de Versiones interno de manera opcional en el mismo fichero que contenía el documento, pero de verdad que era voluminoso y lento.

Para esta época las empresas fueron más allá y comenzaron a usar software privativo con el modelo de cliente y servidor: no nos avergüenza decirlo pero usamos el “Microsoft Visual Source Safe®” (GNU/Linux estaba aun en pañales). En el ambiente Unix es donde iban más adelantados, pero siempre con el sistema centralizado en mente con el veterano “Concurrent Versions System” o CVS y que llevaba tiempo en uso (desde 1986) como software libre para varias plataformas (y no, no había nada mejor que eso, aunque en 2000 le llegaría un reemplazo un poco mejor).

Para aquella época creíamos que el software privativo era infalible, hasta que llegó fiasco del milenio “2K” y que nos restregó en cara que, ante cualquier otra situación parecida, estábamos inermes y sin acceso al código fuente para corregir errores que podían hacer colapsar nuestros sistemas.

Siglo XXI: década de 2000

Ya las redes de área local domésticas estaban establecidas y las grandes y pequeñas empresas e institutos educativos las usaban desde hace buen tiempo. Compartir discos discos duros en red era más fácil y las famosas memorias extraíbles fueron más bien para transportar rápidamente, ya que el Internet no era tan rápido como hoy día (lo mismo diremos dentro de diez años). Nada parecía perturbar nuestra aparentemente idílica situación y cuando creíamos que ya todo se había inventado…

Llegó Linus Torvalds a meter las manos en el control de versiones. Programador consumado, no lo negamos, pero este señor que habla finlandés e inglés a la perfección es una persona de muy “malas pulgas”. Para abreviar la larga historia, el Sr. Torvalds había acumulado gran experiencia con el desarrollo del kernel de Linux y conocía al dedillo todos los problemas que implicaba la administración y manejo del Control de Versiones: todo un trabajo equivalente a programar el mismo kernel. El necesitaba un respiro, desde 1998 hasta 2002 fue creciendo la comunidad de entusiastas y seguidores que mucho podían aportar a la cultura y surgimiento del software libre. Aunque no formamos parte directamente del proceso, comenzaba el principio del fin del autoritarismo y comenzaba la libertad de codificar: cada quien aportaba su propuesta por medio del Sistema de Control de Versiones. Utilizaban Subversion, un programa de Control de Versiones de código abierto, pero que era un gran reflejo de lo que os narramos de las décadas anteriores: un manejo con estructura de directorios y ficheros y una administración centralizada; en eso no habíamos mejorado mucho que digamos.

La mejor opción en ese momento era un programa de Control de Versiones privativo llamado BitKeeper (de manera irónica, desde 2016, liberado en software libre) de la empresa BitMover y tras un acuerdo (que nunca gustó al Padre Fundador Richard Stallman) se llegó a un convenio o compromiso un tanto leonino con la comunidad “linuxera”.

Un buen día -luego de tres años y cientos de gigabytes escritos- el Sr. Torvalds colmó su paciencia y se liberó de todas las ataduras que le imponía esa corporación (el Software Libre no trata de tener libertad de escoger un amo, sino de no tener amo), comisionó al Sr. Andrew Tridgell (creador de rsync y Samba Server) y rápidamente elevaron un escalón y crearon el “SourcePuller” (devenido de BitKeeper) y eso fue la gota que rebosó el vaso: el divorcio fue inevitable.

Por ello, un buen día de 2005, el Sr. Torvalds anunció al mundo no un nuevo programa, sino un paradigma y protocolo en el Control de Versiones: nació Git.

Git, Control de Versiones

Aprovechando la experiencia y bondades de rsync se pudo construir sobre base sólida y unificar todos los conceptos, deseos, anhelos, correcciones, ¡en fin!, un “batiburrillo digital” y la excelencia es, de todo eso, sacar un proyecto abierto para todos y todas y sacarlo adelante. Esto que decimos lo afirmamos: las ideas en este mundo globalizado y conectado sobran, lo difícil es poner trabajo, empeño, tiempo, dinero y esfuerzo en sacarlo adelante y eso fue muy bien lo que hicieron:

• Lo más importante: descentralización de los proyectos. Es más, los proyectos como tal no existen: un directorio contiene un conjunto de ficheros importantes para nosotros, estén relacionados entre sí o no, eso no es problema para Git que no tiene ninguna jerarquía (la página web SourceForge, que utiliza Subversion, aún mantiene la necesidad de crear un proyecto como condición para publicar).
• Está enfocado en el rendimiento sin descuidar la seguridad. Un programa inspirador para desarrollar Git fue Monotone, el cual guarda en una base de datos que es clonada por cada uno de los participantes. Eso quiere decir que los ficheros están contenidos en ficheros más grandes (bases de datos) que se deben sincronizar y si sumamos las comprobaciones de integridad de datos pues allí perderemos valioso tiempo.
• El desarrollo no es lineal (esto en realidad no lo inventó Git, ya existía): consiste en la posibilidad de que a partir de puntos o fotografías del repositorio sacar ramas provisionales de desarrollo, que bien luego podremos integrarla a la rama principal o simplemente desecharlas.
• Completamente distribuido: cada persona tiene una copia completa del repositorio; a pesar de esto Git sigue siendo increíblemente rápido en la creación y manejo de ramificaciones.
• Tampoco fue atado un protocolo de transporte: actualmente no se utiliza rsync a favor de HTTP, HTTPS, FTP o SSH, y hasta el que necesite implementar por medio de un socket web. Incluso ofrece compatibilidad para emular a CVS en su transporte.
• También ofrece un control sobre las transferencias no realizadas correctamente o incompletas que pueda comprometer la integridad de los datos.
• Otra característica, que otros programas también tenían desde hace tiempo, es colocar etiquetas a cada una de los conjuntos de modificaciones que subamos al servidor Git para luego solicitarlos o simplemente observar la descripción de los cambios realizados.

Son apenas unas cuantas características relevantes, el tema es denso pero en Internet abunda información si queréis ahondar sobre algún punto.

Servidor Git

Hoy en día podemos almacenar nuestros propios repositorios, las obras que desarrollemos (documentos, programación, hojas de cálculo, etc.) en nuestro propio servidor Git. Basta que tomemos algún ordenador viejo con un disco duro decente conectado a la red de área local y le instalemos un sistema operativo GNU/Linux Debian, o mejor aun Ubuntu. En la terminal de comando ejecutaremos simplemente:

sudo apt-get install git-all

Establecemos configuración y las credenciales y estaremos listos para administrarnos nosotros mismos de una manera organizada. Si queremos un bonito editor gráfico para ver los cambios podremos instalar QGit:

sudo apt-get install qgit

• GitLab Community Edition.
• GitTea.
• GNU Savannah.
• GitBucket.
• Gogs.

Como toda nueva tecnología siempre habrá quien se aproveche económicamente para realizar este trabajo de configuración y alojamiento por nosotros, así que por eso hablaremos brevemente sobre GitHub®, empresa que fue recientemente adquirida por el gigante Microsoft®.

Git y GitHub® como industria del Control de Versiones

GitHub llegó en el momento justo para ofrecernos este ahorro de trabajo y equipo agregando sistemas de autenticación sobre servidores web y adaptando el protocolo Git a sus intereses. Hasta ahora su esquema de trabajo es dar alojamiento gratuito al desarrollo de software libre y cobrar por alojamiento privado a quienes desarrollen software privativo.

Esta manera de trabajar es frecuente crítica, porque GitHub® alberga una gran cantidad de lecciones y código a medias, producto de los estudiantes de lenguajes de programación, amén de guías de estudio, artículos científicos y hasta borradores sobre leyes o seguimiento de las mismas. Esto lo consideran un desperdicio de recursos, pero, si a la empresa GitHub® no le disgusta, ¿por qué habría de molestarnos a nosotros? Otras empresas utilizan a GitHub® como vitrina: en realidad no lleva allí el código, sino que reflejan lo que hacen en sus propios servidores Git.

El punto de acierto de GitHub® fue acercar al público en general a los grandes proyectos de software, reportar incidencias e incluso proponer mejoras. ¡Libertad de codificar con fraternidad e igualdad!

Otras alternativas a GitHub

• GitPrep.
• Kallithea.
• Phabricator.
• Tuleap.

Conclusión

Este artículo no pretende ser una autoridad sobre el tema. Acerca del Control de Versiones sesudos licenciados e ingenieros han escrito libros y libros al respecto; en todo caso nos ha servido como recordación -o presentación, si sois nuevo lector o lectora por aquí- de la existencia de los repositorios públicos de Pandora FMS: flexibilidad ante todo. ¿Escribimos algo incorrecto o que no es cierto? ¡Escribid abajo vuestros comentarios, observaciones e indicaciones por favor!