Gráficos de paquetes en Azure Artifacts

Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Al publicar un paquete, es fundamental asegurarte de que todas las dependencias de dicho paquete estén disponibles en tu feed, obteniéndolas de una fuente de origen. Una vez que consume un paquete de una fuente upstream, se guarda una copia en su feed. Esto garantiza que, incluso si la fuente ascendente deja de ser accesible, su copia seguirá estando disponible tanto para usted como para los consumidores de su feed.

Cómo construyen las fuentes el conjunto de paquetes disponibles

A medida que los feeds de Azure Artifacts pueden tener otros feeds como ascendentes, existe la posibilidad de crear ciclos de orígenes ascendentes, donde el feed A tiene como ascendente al feed B, que a su vez tiene como ascendente al feed C, y finalmente, el feed C asciende de nuevo al feed A. Dicho ciclo, si no se gestiona adecuadamente, podría provocar problemas con las solicitudes de paquetes, creando un bucle infinito donde un usuario solicita un paquete del feed A, luego A solicita de B, después B solicita de C y, por último, C solicita de nuevo a A, formando un bucle.

Las fuentes ascendentes están diseñadas para evitar tales situaciones. Cuando un feed busca un paquete en sus fuentes upstream, recibe los paquetes en la vista configurada para esa fuente upstream. Esto significa que la fuente de consulta A no desencadena una consulta transitiva para alimentar C (A -> B -> C) porque las vistas son de solo lectura. Como resultado, la fuente A tendrá acceso a los paquetes de C que un usuario guardó previamente en B , pero no al conjunto completo de paquetes disponibles en C.

Esto coloca la responsabilidad en la fuente B para asegurarse de que sus paquetes locales representan un gráfico de dependencias completo. Al hacerlo, los usuarios que consumen el paquete de B a través de una fuente ascendente de otro feed pueden resolver correctamente el grafo de dependencias e instalar su paquete B deseado sin encontrar problemas.

Ejemplo: construir el conjunto de paquetes disponibles

Consideremos tres fuentes: Fabrikam, Contoso y AdventureWorks. En esta ilustración, examinaremos los paquetes disponibles para el feed de Fabrikam mientras introducimos fuentes upstream.

Inicialmente, Fabrikam no tiene orígenes ascendentes, lo que permite a los usuarios conectados a Fabrikam instalar solo las versiones 1.0.0 y 2.0.0 del paquete widgets. De forma similar, Contoso no tiene orígenes ascendentes, lo que restringe a los usuarios conectados a Contoso para instalar solo las versiones 1.0.0 y 3.0.0 del paquete Gizmos. Lo mismo se aplica a la fuente AdventureWorks, donde los usuarios conectados solo pueden instalar las versiones 1.0.0 y 2.0.0 del paquete Gadgets o la versión 1.0.0 del paquete Things.

Ilustración que muestra tres fuentes de datos diferentes sin fuentes de origen.

Ahora, vamos a explorar el escenario en el que Contoso agrega AdventureWorks como origen ascendente. Cuando un usuario está conectado a Contoso, obtiene acceso a una gama más amplia de paquetes. Pueden instalar cualquier versión de Gizmos, Gadgets o Things. Por ejemplo, si el usuario instala Gadgets@2.0.0, esta versión específica del paquete se guarda en Contoso con un vínculo a AdventureWorks.

Ilustración que muestra cómo Contoso agrega AdventureWorks como origen upstream.

Consideremos ahora una situación en la que el feed de Fabrikam añade Contoso como fuente upstream. Un usuario conectado a Fabrikam puede instalar cualquier versión de Widgets, cualquier versión de Gizmos, pero solo las versiones guardadas de Gadgets (2.0.0).

Ilustración que muestra Fabrikam agregando Contoso como origen ascendente.

El usuario no podrá instalar la versión 1.0.0 de Gadgets ni ninguna versión de las cosas, ya que un usuario de Contoso no guardó esas versiones del paquete.

Ilustración en la que se muestran los paquetes disponibles para los usuarios de Fabrikam.