Un administrador de depósitos de objetos binarios ( binary repository manager en inglés) es una herramienta de software diseñada para optimizar la descarga y el almacenamiento de objetos binarios utilizados y producidos en el contexto del desarrollo de software (generalmente archivos). Centraliza la gestión de todos los artefactos generados y utilizados por el software de la organización (editor de software). Permite dar respuesta al problema de complejidad derivado de la diversidad de tipos de objetos binarios, su posición en todo el flujo de trabajo así como las dependencias entre ellos.
Un repositorio de objetos binarios es un repositorio de software para paquetes, artefactos y sus metadatos. Se puede usar para almacenar binarios producidos por la propia organización (versiones y compilaciones de productos intermedios) o para almacenar binarios de terceros (dependencias) que deben tratarse de manera diferente por razones técnicas y legales.
El desarrollo de software puede ser un proceso complejo que involucra a muchos desarrolladores, posiblemente en varios países (problema de zona horaria, barrera del idioma, etc.). Estos equipos de desarrolladores comparten los mismos repositorios de código , acceden a las mismas herramientas de compilación, descargan y usan un conjunto común de recursos binarios e implementan los mismos componentes dentro del mismo software.
El administrador del repositorio de objetos binarios fue creado para centralizar los artefactos binarios que las aplicaciones necesitan para ser construidas (compiladas), probadas y ejecutadas.
Para administrar archivos de código fuente en el desarrollo de software, las organizaciones suelen utilizar el control de revisión . Este software tiene como objetivo centralizar el código fuente de un software permitiendo que varias personas trabajen en él simultáneamente y permitiendo además (entre otras funciones) llevar el historial de las modificaciones realizadas en cada archivo. Para ello, los gerentes integran o utilizan herramientas como los comparadores de texto ( diff ).
Estos numerosos archivos de origen se integran en última instancia (compilados o no) en uno o más artefactos binarios y constituyen los componentes de un producto de software.
El resultado de las compilaciones y construcciones de componentes está sujeto a los mismos principios que los archivos fuente (sostenibilidad, disponibilidad, historial, etc.). Por lo tanto, el administrador del repositorio de objetos binarios converge hacia los administradores de versiones y puede considerarse como un administrador de versiones para objetos binarios. De este modo, se supera la limitación que tienen los administradores de versiones (textuales) en el manejo de contenido binario que están obligados a almacenar tal cual porque no pueden analizar su contenido y, por lo tanto, ocupan mucho espacio en las no bases de datos. tipo de contenido.
Además, el software puede utilizar artefactos externos (puestos a disposición por uno o más terceros) que se descargan de repositorios (gratuitos, de código abierto o patentados) y / o se adquieren (de forma gratuita o se compran de fuentes comerciales). Por tanto, un software puede incluir decenas, cientos o incluso miles de objetos binarios que deben gestionarse para mantener de forma eficaz un todo coherente y funcional.
Al igual que con los administradores de versiones, los administradores de repositorios de objetos binarios son compartidos por diferentes equipos de desarrollo, lo que garantiza que todos usen los mismos recursos.
El administrador del repositorio de objetos binarios se diferencia de los administradores de versiones en que debe integrar un conjunto de elementos que no son propiedad de la organización (se deben tener en cuenta las restricciones legales). De hecho, es por tanto responsable de crear y mantener un contexto histórico (entorno) en el que se crea el software que permita recrearlo si es necesario sin riesgo de variaciones debido a los ciclos de vida de los componentes internos y de terceros.
A diferencia de los administradores de versiones, los administradores de repositorios de objetos binarios no tienen como objetivo almacenar todas las evoluciones intermedias de los artefactos como lo hacen los administradores de versiones para los archivos de código fuente. Solo las versiones marcadas como tales (a través de metadatos) se almacenan y son accesibles.
Es una práctica común tener una versión particular (o incluso varias cuando el proyecto administra varias versiones en paralelo) llamada instantánea o compilación nocturna en la que la organización está trabajando y que probablemente cambie con frecuencia. Esta versión generalmente no está disponible para otros equipos de desarrollo y su historial no se guarda, solo se puede acceder a la última versión creada, las demás se sobrescriben.
Cuando la versión está congelada (validada), se crea un número de versión definitivo y el administrador del repositorio de objetos binarios almacena los elementos creados en un artefacto específico y el conjunto ya no sufrirá evolución. Las correcciones de errores se realizarán en una versión separada identificada por otro número de versión.
Por lo tanto, el administrador del repositorio de objetos binarios no maneja la noción de rama como los administradores de versiones, ya que no es posible fusionar ramas o comparaciones. Cada rama ( versión en el sentido del administrador del repositorio de objetos binarios) es completamente independiente de las otras versiones del software, mientras que para un administrador de versiones, el contenido de una rama es solo la suma de las modificaciones realizadas a los archivos desde el momento se creó la rama (por lo tanto, la rama solo se puede utilizar en asociación con los elementos anteriores del historial).
La industria del software está en constante evolución. Los administradores de objetos binarios no son una excepción a la regla y se están moviendo gradualmente hacia administradores de paquetes universales. Estos administradores de paquetes tienen como objetivo estandarizar la forma en que las empresas acceden y utilizan todos los paquetes que necesitan en su proceso de desarrollo. Proporcionan herramientas para el análisis de seguridad y compatibilidad de tipos de artefactos. Los gestores de paquetes universales tienen una posición central en la cadena de herramientas de desarrollo (sistemas de compilación, empaquetadores, herramientas de documentación, análisis de código, entrega ...) explotadas por las organizaciones.
Algunos administradores de paquetes universales conocidos:
Como parte del ciclo de vida del desarrollo de software, el código fuente se compila regularmente en objetos binarios durante el proceso de integración continuo .
Durante esta operación, el sistema de gestión de código interactúa con el gestor del repositorio de objetos binarios para obtener las dependencias necesarias para la operación de compilación, procesamiento y ejecución, así como para depositar dentro del repositorio objetos binarios de producción propia (hablamos de publicación). Esta comunicación implica el uso de artefactos para identificar los recursos necesarios y hacer que los objetos binarios creados estén disponibles para otras herramientas o software.
Esta estrecha interacción con los servidores de integración continua permite el almacenamiento de metadatos como:
Los artefactos y los paquetes son dos cosas inherentemente diferentes.
Los artefactos representan un conjunto (a veces reducido a una sola entrada) de elementos (generalmente archivos como JAR , WAR , EAR , DLL , SO, ZIP ...) uno de los cuales contiene metadatos (por ejemplo, el POM en Maven ) que les permite estar identificado de forma única (id, paquete, versión, licencia y otros ...).
Por el contrario, los paquetes se componen de un único archivo de almacenamiento en un formato bien definido (por ejemplo, NuGet de Microsoft , RPM de Red Hat o DEB de Debian ). Este archivo contiene todos los archivos proporcionados por el formato (como DLL, PDB, etc.).
Los artefactos generalmente se generan mediante compilaciones. Los paquetes son esencialmente aplicaciones o bibliotecas de software.
En comparación con los archivos de origen, los artefactos binarios son mucho más grandes. Rara vez se eliminan o modifican (a excepción de los artefactos en desarrollo que se sobrescriben regularmente con actualizaciones y que no están oficialmente disponibles para terceros).
Los metadatos describen un artefacto binario. Se almacenan por separado del artefacto en sí y pueden tener diferentes usos.
La siguiente tabla muestra los tipos de metadatos más comunes y sus usos.
| Tipos | Usos |
|---|---|
| Versiones disponibles | permite la actualización ascendente (actualización) o descendente (degradación) |
| Dependencias | especifica los artefactos de los que depende el artefacto descrito |
| Dependencias de impacto | da la lista de artefactos dependiendo del artefacto descrito |
| Licencia | contenido (o referencia) de la licencia legal a la que está sujeto el artefacto descrito (por ejemplo: GPL , CC , Apache ...) |
| Fecha y hora de construcción | permite la trazabilidad del artefacto |
| Documentación | proporciona documentación fuera de línea del artefacto |
| Información de aprobación | indica la trazabilidad del proceso de validación y aprobación de artefactos |
| Medidas | agrega información relacionada con la calidad del código, la cobertura de necesidades, los resultados de las pruebas, etc. |
| Metadatos de usuario | enumera la información adicional proporcionada por los desarrolladores (informes, documentación técnica, proceso, etc.) |
A continuación se enumeran las principales características proporcionadas por los administradores de repositorios de objetos binarios que deben tenerse en cuenta al adoptar dichos sistemas: