Ingeniería de software en Google

Lecciones sobre programación aprendidas a lo largo del tiempo

Titus Winters, Tom Manshreck, Hyrum Wright

• Publisher: Marcombo
• Year: 2022
• ISBN:
  9788426734877
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Graphics
• Index: Computer Science

Hoy en día, los ingenieros de software necesitan saber no solo cómo programar eficazmente, sino también cómo desarrollar prácticas de ingeniería para que la base de código sea sostenible y funcione bien. Este libro hace hincapié en esta diferencia, entre la programación y la ingeniería de software. ¿Cómo pueden gestionar los ingenieros de software una base de código viva que evoluciona y responde a requisitos y demandas cambiantes a lo largo de su vida?A partir de su experiencia en Google, los ingenieros de software Titus Winters y Hyrum Wright, junto con el escritor técnico Tom Manshreck, presentan una mirada sincera y perspicaz sobre cómo construyen y mantienen el software algunos de los principales profesionales del mundo.Este libro trata de la cultura, los procesos y las herramientas de ingeniería exclusivas de Google, y de cómo estos aspectos contribuyen a la eficacia de una organización de ingeniería de software. Explorará tres principios fundamentales que las organizaciones de software deben tener en cuenta a la hora de diseñar, establecer la arquitectura, escribir y mantener el código: - Cómo afecta el tiempo a la sostenibilidad del software y cómo hacer que su código resista el paso del tiempo.- Cómo afecta la escala a la viabilidad de las prácticas de software dentro de una organización de ingeniería de software.- Qué contrapartidas debe tener en cuenta el ingeniero de software al evaluar las decisiones de diseño y los desarrollos.

CAPÍTULO 16

Control de versiones y gestión de ramas

Autor: Titus Winters
Editor: Lisa Carey

Quizá ninguna herramienta de ingeniería de software haya sido tan universalmente adoptada por la industria como el control de versiones. Difícilmente se puede imaginar una organización de software con algo más de unas pocas personas que no cuente con un sistema de control de versiones (VCS) formal para gestionar su código fuente y coordinar las actividades entre los ingenieros.

En este capítulo, veremos por qué el uso del control de versiones se ha convertido en una norma tan inequívoca en la ingeniería de software, y describiremos los diversos enfoques posibles para el control de versiones y la gestión de ramas, incluyendo la explicación de cómo lo hacemos a escala en todo Google. También examinaremos los pros y los contras de los distintos enfoques; aunque creemos que todo el mundo debería utilizar el control de versiones, algunas políticas y procesos de control de versiones podrían funcionar mejor para su organización (o en general) que otras. En particular, consideramos que el «desarrollo basado en troncos», tal y como lo popularizó DevOps¹ (un repositorio, sin ramas de desarrollo), es el enfoque de una política particularmente escalable, y proporcionaremos algunas sugerencias sobre el porqué de tal afirmación.

¿Qué es el «control de versiones»?

Esta sección puede ser un poco elemental para muchos lectores: el uso del control de versiones se encuentra, después de todo, bastante omnipresente. Si quiere saltarse esta sección, le sugerimos que vaya a «Fuente de verdad», en la página 334.

VCS es un sistema que rastrea las revisiones (versiones) de los archivos a lo largo del tiempo. VCS mantiene algunos metadatos del conjunto de archivos que se gestionan, y a una copia de los archivos y metadatos se la llama comúnmente «repositorio»² (abreviadamente, «repo»). VCS ayuda a coordinar las actividades de los equipos, al permitir que varios desarrolladores trabajen en el mismo conjunto de archivos simultáneamente. Los primeros VCS lograban esta posibilidad al otorgar a una sola persona, a la vez, el derecho a editar un archivo; ese tipo de bloqueo es suficiente para establecer la secuenciación (un acuerdo sobre «qué es más reciente», una característica importante de VCS). Los sistemas más avanzados garantizan que los cambios en una colección de archivos enviados a la vez se traten como una sola unidad (atomicidad, cuando un cambio lógico afecta a varios archivos). Los sistemas como CVS (un popular VCS de los años noventa), que no tenían esta atomicidad para la confirmación de las transacciones, eran susceptibles de corrupción y se podían perder los cambios. Al garantizar la atomicidad, se elimina la posibilidad de que los cambios anteriores se sobrescriban involuntariamente, pero requiere el seguimiento de la última versión que se sincronizó (en el momento de la confirmación, se rechaza si cualquier archivo se ha modificado en head durante el proceso, desde la última vez que el desarrollador local se sincronizó). Especialmente en un VCS con seguimiento de cambios, la copia del trabajo de un desarrollador de los archivos gestionados necesitará sus propios metadatos. Dependiendo del diseño del VCS, esta copia del repositorio puede ser un repositorio en sí mismo, o puede contener una cantidad reducida de metadatos; dicha copia reducida suele ser un «cliente» o «espacio de trabajo».

Esto parece muy complejo: ¿por qué es necesario un VCS? ¿Qué tiene este tipo de herramienta que le ha permitido convertirse en una de las pocas casi universales para el desarrollo y la ingeniería de software?

Imagínese, por un momento, trabajando sin un VCS. Para un grupo (muy) pequeño de desarrolladores diseminados que trabajan en un proyecto de alcance limitado sin ningún conocimiento del control de versiones, la solución más sencilla y de menor infraestructura sería, simplemente, pasar copias del proyecto de un lado a otro. Esto funciona mejor cuando las ediciones no aparecen simultáneas (las personas están trabajando en diferentes zonas horarias o, al menos, con distintos horarios de trabajo). Si existe la posibilidad de que la gente no sepa qué versión es la más actual, se nos plantea de inmediato un problema molesto: rastrear qué versión se halla actualizada. Cualquiera que haya intentado colaborar en un entorno sin red probablemente recordará los horrores de copiar archivos de ida y vuelta llamados Presentación v5 - final - líneas rojas - versión v2 de Josh. Y, como veremos, cuando no existe el acuerdo de una sola fuente de verdad, la colaboración genera una gran fricción y se muestra propensa a errores.

La introducción del almacenamiento compartido requiere un poco más de infraestructura (obtener acceso al almacenamiento compartido), pero proporciona una solución fácil y obvia. Coordinar el trabajo en una unidad compartida puede ser suficiente durante un tiempo con un número relativamente pequeño de personas, pero aún requiere la colaboración fuera de lo habitual, para evitar sobrescribir el trabajo de los demás. Aparte, trabajar directamente en ese almacenamiento compartido significa que cualquier tarea de desarrollo que no mantenga la compilación funcionando continuamente obstaculizará a todos en el equipo: si hago un cambio en alguna parte de este sistema al mismo tiempo que usted inicia una compilación, esta no funcionará. Obviamente, esto no se escala bien.

En la práctica, la falta de bloqueo de los archivos, y de seguimiento de las fusiones, provocará inevitablemente colisiones y que se sobrescriba el trabajo. Es muy probable que un sistema de este tipo introduzca una coordinación fuera de lo habitual, para decidir quién trabaja en un archivo determinado. Si ese bloqueo de archivos está codificado en el software, hemos empezado a reinventar un control de versiones de primera generación como RCS (Revision Control System, entre otros). Una vez que se dé cuenta de que otorgar permisos de escritura de un archivo a la vez aparece demasiado burdo y comience a desear el seguimiento a nivel de línea, definitivamente estamos reinventando el control de versiones. Parece casi inevitable que queramos contar con algún mecanismo estructurado para gobernar dichas colaboraciones. Dado que parece que estamos reinventando la rueda en esta hipótesis, podríamos utilizar una herramienta estándar.

¿Por qué es importante el control de versiones?

Si bien el control de versiones es ahora prácticamente omnipresente, no siempre fue así. Los primeros VCS se remontan a la década de los setenta (SCCS) y ochenta (RCS), muchos años después de las primeras referencias a la ingeniería de software como una disciplina independiente. Los equipos participaron en «el desarrollo multipersonal de software multiversión (https://arxiv.org/pdf/1805.02742.pdf)», antes de que la industria tuviera una noción formal del control de versiones. Este evolucionó como respuesta a los nuevos desafíos de la colaboración digital. Se necesitaron décadas de evolución y difusión para que el uso fiable y coherente del control de versiones se convirtiera en la norma que es hoy³. Entonces, ¿cómo llegó a ser tan importante y, dado que parece una solución evidente, por qué alguien podría resistirse a la idea del VCS?

Recuerde que la ingeniería de software es la programación integrada en el tiempo; estamos haciendo una distinción (en dimensionalidad) entre la producción instantánea de código fuente y el acto de mantener ese producto a lo largo del tiempo. Esta distinción básica explica, en gran medida, la importancia de los sistemas de control de versiones y las dudas al respecto: en el nivel más básico, el control de versiones conforma la principal herramienta del ingeniero para gestionar la interacción entre el código fuente y el tiempo. Podemos conceptualizar el VCS como una forma de ampliar un sistema de archivos estándar. Este se corresponde con la asignación de los nombres de archivos a los contenidos. Un VCS extiende lo anterior para proporcionar la asignación desde (nombre de archivo y hora) hasta el contenido, junto con los metadatos necesarios para rastrear los últimos puntos de sincronización y el historial de auditoría. En el control de versiones, el tiempo se considera una parte explícita de la operación: innecesaria en una tarea de programación, crítica en una tarea de ingeniería de software. En la mayoría de los casos, un VCS también permite una entrada adicional a esa asignación (un nombre de rama), para permitir asignaciones paralelas; por lo tanto:

VCS (nombre de archivo, hora, rama) => contenido del archivo

Por defecto, se entiende que esa entrada de rama tendrá un nombre predeterminado: lo llamamos «cabeza», «por defecto» o «tronco», para denotar la rama principal.

La (pequeña) duda que queda en relación con el uso coherente del control de versiones proviene casi directamente de la confusión entre la programación y la ingeniería de software: enseñamos a programar, formamos a los programadores, hacemos entrevistas de trabajo basadas en problemas y técnicas de programación… Resulta perfectamente razonable que una persona recién contratada, incluso en un lugar como Google, tenga poca o ninguna experiencia con el código en el que trabaja más de una persona o durante más de un par de semanas. Teniendo en cuenta esa experiencia y la comprensión del problema, el control de versiones parece una solución extraña. El control de versiones resuelve un problema que nuestro nuevo empleado no ha experimentado necesariamente: un «deshacer», no para un solo archivo, sino para todo un proyecto, lo que añade mucha complejidad para obtener unos beneficios a veces no evidentes.

En algunos grupos de software, se produce el mismo resultado cuando la dirección considera el trabajo de los técnicos como «desarrollo de software» (sentarse y escribir código) en lugar de «ingeniería de software» (elaborar código, mantenerlo en funcionamiento y en estado útil durante algún tiempo). Con un modelo mental de programación como tarea principal y una escasa comprensión de la interacción entre el código y el paso del tiempo, es fácil ver algo descrito como «volver a una versión anterior para deshacer un error» como un lujo extraño y exagerado.

Además de permitir el almacenamiento por separado y la referencia a las versiones a lo largo del tiempo, el control de versiones nos ayuda a cerrar la brecha entre los procesos de un solo desarrollador y de múltiples desarrolladores. En términos prácticos, esta es la razón por la que el control de versiones parece tan crítico a la ingeniería de software, porque nos permite escalar equipos y organizaciones, aunque lo usemos con poca frecuencia, como un botón de «deshacer». El desarrollo es intrínsecamente un proceso de bifurcación y fusión, tanto cuando se coordina entre varios desarrolladores como cuando lo hace un solo desarrollador en diferentes momentos. Un VCS elimina la pregunta de «¿cuál es más reciente?». Con el uso del control de versiones moderno, se automatizan las operaciones propensas a errores, como el seguimiento del conjunto de cambios que se han aplicado. El control de versiones es cómo nos coordinamos entre múltiples desarrolladores y/o múltiples puntos en el tiempo.

Debido a que VCS se ha integrado tan profundamente en el proceso de ingeniería de software, incluso las prácticas legales y regulatorias se han puesto al día. VCS permite un registro formal de cada cambio en cada línea de código, que es cada vez más necesario para satisfacer los requisitos de auditoría. Al combinar el desarrollo interno y el uso apropiado de fuentes de terceros, VCS ayuda a rastrear la procedencia y el origen de cada línea de código.

Además de los aspectos técnicos y normativos del seguimiento de la fuente a lo largo del tiempo y el manejo de las operaciones de sincronización/bifurcación/fusión, el control de versiones desencadena algunos cambios no técnicos en el comportamiento. El ritual de comprometerse con el control de versiones y producir un registro de confirmación constituye el detonante para un momento de reflexión: ¿qué ha logrado desde su última confirmación? ¿Está la fuente en un estado que le agrada? El momento de introspección asociado con comprometerse, escribir un resumen y marcar una tarea como completa puede tener valor por sí solo para muchas personas. El inicio del proceso de confirmación conforma un momento perfecto para realizar una lista de comprobación, ejecutar análisis estáticos (véase el capítulo 20), cotejar la cobertura de las pruebas, ejecutar pruebas y análisis dinámicos, etc.

Como cualquier proceso, el control de versiones viene acompañado de algunos gastos generales: alguien ...