Piper (sistema de control de fuentes)

Piper es un sistema de control de versiones centralizado utilizado por Google para el desarrollo interno de su software. Diseñado originalmente para Linux , es compatible con Microsoft Windows y macOS desde octubre de 2012. ^{[ 1 ]}

Desde sus años de fundación, Google ha utilizado una base de código central . ^{[ 2 ]} Durante más de 10 años, Google dependió de una única instancia de Perforce , utilizando almacenamiento en caché propietario para la escalabilidad. ^{[ 3 ]} La necesidad de una mayor escalabilidad llevó al desarrollo de Piper. ^{[ 4 ]} Actualmente, el control de versiones de Google "es un caso extremo": ^{[ 5 ]} a partir de 2016,El repositorio almacenaba 86 terabytes de datos, que comprendían dos mil millones de líneas de código en nueve millones de archivos (dos órdenes de magnitud más que en el repositorio del kernel de Linux ). 25 000 desarrolladores contribuían con 16 000 cambios diarios, además de 24 000 operaciones de confirmación realizadas por bots. Las solicitudes de lectura diarias se medían en miles de millones. ^{[ 6 ]}

Piper utiliza soluciones de almacenamiento estándar de Google Cloud , originalmente Bigtable y posteriormente Spanner , distribuidas en 10 centros de datos en todo el mundo y replicadas a través del protocolo Paxos . ^{[ 3 ]}

Al usar Piper, los desarrolladores aplican los cambios a una copia local de los archivos, similar a una copia de trabajo en Subversion , un clon local en Git o un cliente en Perforce. Las actualizaciones realizadas por otros desarrolladores se pueden obtener del repositorio central y fusionar con el código local. Las confirmaciones solo se permiten después de una revisión de código mediante la herramienta Critique. ^{[ 7 ] [ 8 ]}

El uso típico implica Clientes en la Nube ( CitC ). Este sistema utiliza un backend en la nube y un sistema de archivos FUSE local para crear la ilusión de cambios superpuestos sobre un repositorio completo. Este enfoque permite una navegación fluida y el uso de herramientas Unix estándar sin operaciones de sincronización explícitas, lo que mantiene la copia local muy pequeña (el tamaño promedio de una copia local es inferior a diez archivos). Todas las escrituras de archivos se asignan a instantáneas , lo que permite restaurar estados anteriores del código sin instantáneas explícitas. Debido a su funcionamiento siempre conectado, CitC permite cambiar fácilmente de ordenador, así como compartir código modificado con otros desarrolladores y utilizar el sistema de compilación automatizado y las herramientas de prueba. ^{[ 7 ]} Como resultado, la mayoría de los desarrolladores de Google practican el desarrollo basado en trunk sin ramas personales ; las ramas se utilizan principalmente para lanzamientos. ^{[ 9 ]}

La mayor parte del código fuente es visible para todos los desarrolladores; los archivos individuales sensibles (menos del 1 % a partir de 2016) tienen control de acceso. Todas las operaciones con Piper se registran; los archivos que se hayan subido accidentalmente pueden eliminarse. ^{[ 7 ]}

• Blank-Edelman, DN (2018). Buscando SRE: Conversaciones sobre la gestión de sistemas de producción a gran escala . O'Reilly Media. ISBN 978-1-4919-7881-8. Consultado el 31 de octubre de 2024 .
• Potvin, Rachel; Levenberg, Josh (24 de junio de 2016). «¿Por qué Google almacena miles de millones de líneas de código en un solo repositorio?» . Communications of the ACM . 59 (7). Association for Computing Machinery (ACM) : 78–87 . doi : 10.1145/2854146 . ISSN 0001-0782 . 
• Sadowski, Caitlin; Kurnia, Ilham; Rohlfs, Ben (28 de febrero de 2020). «Crítica: la herramienta de revisión de código de Google» . En Winters, Titus; Manshreck, Tom; Wright, Hyrum (eds.). Ingeniería de software en Google: lecciones aprendidas de la programación a lo largo del tiempo . O'Reilly Media, Inc. ISBN 978-1-4920-8276-7. Consultado el 21 de julio de 2025 .