Gráficos de paquetes en Azure Artifacts

  • Artículo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Al liberar un paquete, es fundamental asegurarse de que todas las dependencias de ese paquete están disponibles en la fuente al consumirlos desde un origen ascendente. Una vez que consuma un paquete de un origen ascendente, se guarda una copia en la fuente. Esto garantiza que incluso si el origen ascendente deja de estar accesible, la copia seguirá estando disponible tanto para usted como para los consumidores de fuentes.

Cómo construye upstreams el conjunto de paquetes disponibles

A medida que las fuentes de Azure Artifacts pueden tener otras fuentes como ascendentes, hay un potencial para crear ciclos de orígenes ascendentes, donde la fuente A ascendentes para alimentar B, que ascendentes para alimentar C y, finalmente, volver a alimentar C ascendentes a la fuente A. Este ciclo, si no se administra correctamente, podría dar lugar a problemas con las solicitudes de paquete, creando un bucle infinito donde un usuario solicita un paquete desde la fuente A, luego A solicitudes de B, después solicitudes B de C y, por último, solicitudes de C a A, formando un bucle.

Los orígenes ascendentes están diseñados para evitar tales situaciones. Cuando una fuente busca un paquete de sus orígenes ascendentes, recibe los paquetes de la vista configurados para ese origen ascendente. 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 un origen ascendente de otra fuente pueden resolver correctamente el gráfico 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 en la fuente Fabrikam a medida que presentamos orígenes ascendentes.

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 diferentes sin orígenes ascendentes.

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 de Contoso que agrega AdventureWorks como origen ascendente.

Ahora, vamos a considerar una situación en la que la fuente fabrikam agrega Contoso como origen ascendente. 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 de Fabrikam que agrega 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 de los paquetes disponibles para los usuarios de Fabrikam.