Gráficos de pacote no Azure Artifacts

  • Artigo

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

Ao liberar um pacote, é crucial garantir que todas as dependências desse pacote estejam disponíveis em seu feed, consumindo-as de uma fonte upstream. Depois de consumir um pacote de uma fonte upstream, uma cópia é salva no feed. Isso garante que, mesmo que a fonte upstream se torne inacessível, sua cópia continuará disponível para você e seus consumidores de feed.

Como os upstreams constroem o conjunto de pacotes disponíveis

Como os feeds de Artefatos do Azure podem ter outros feeds como upstreams, há um potencial para criar ciclos de fontes upstream, onde feed A upstream para alimentar B, que upstream para alimentar C e, eventualmente, alimentar C upstream de volta para alimentar A. Tal ciclo, se não for gerenciado corretamente, pode levar a problemas com solicitações de pacote, criando um loop infinito onde um usuário solicita um pacote do feed A, depois A solicita de B, depois B solicita de C e, finalmente, C solicita de volta para A, formando um loop.

As fontes a montante são projetadas para evitar tais situações. Quando um feed procura um pacote de suas fontes upstream, ele recebe os pacotes na exibição configurada para essa fonte upstream. Isso significa que a consulta ao feed A não aciona uma consulta transitiva para alimentar C (A -> B -> C) porque as exibições são somente leitura. Como resultado, o feed A terá acesso a todos os pacotes de C que foram salvos anteriormente em B por um usuário, mas não ao conjunto completo de pacotes disponíveis em C.

Isso coloca a responsabilidade no feed B para garantir que seus pacotes locais representem um gráfico de dependência completo. Ao fazer isso, os usuários que consomem o pacote de B por meio de uma fonte upstream de outro feed podem resolver com êxito o gráfico e instalar o pacote B desejado sem encontrar problemas.

Exemplo: construir o conjunto de pacotes disponíveis

Vamos considerar três feeds: Fabrikam, Contoso e AdventureWorks. Nesta ilustração, examinaremos os pacotes disponíveis para o feed da Fabrikam à medida que introduzimos os códigos-fonte upstream.

Inicialmente, a Fabrikam não tem fontes upstream, permitindo que os usuários conectados à Fabrikam instalem apenas as versões 1.0.0 e 2.0.0 do pacote Widgets. Da mesma forma, a Contoso não tem fontes upstream, restringindo os usuários conectados à Contoso para instalar apenas as versões 1.0.0 e 3.0.0 do pacote do Gizmos. O mesmo se aplica ao feed AdventureWorks, em que os usuários conectados só podem instalar as versões 1.0.0 e 2.0.0 do pacote Gadgets ou a versão 1.0.0 do pacote Things.

Uma ilustração mostrando três feeds diferentes sem fontes upstream.

Agora, vamos explorar o cenário em que a Contoso adiciona o AdventureWorks como uma fonte upstream. Quando um usuário está conectado à Contoso, ele obtém acesso a uma gama mais ampla de pacotes. Eles podem instalar qualquer versão do Gizmos, Gadgets ou Coisas. Por exemplo, se o usuário instalar o Gadgets@2.0.0, essa versão específica do pacote será salva na Contoso com um link de volta para o AdventureWorks.

Uma ilustração da Contoso adicionando AdventureWorks como uma fonte upstream.

Agora, vamos considerar uma situação em que o feed da Fabrikam adiciona a Contoso como uma fonte upstream. Um usuário conectado à Fabrikam pode instalar qualquer versão do Widgets, qualquer versão do Gizmos, mas SOMENTE versões salvas do Gadgets (2.0.0).

Uma ilustração da Fabrikam adicionando a Contoso como uma fonte upstream.

O usuário não poderá instalar a versão 1.0.0 dos Gadgets ou qualquer versão do Things, porque essas versões do pacote não foram salvas na Contoso por um usuário da Contoso.

Uma ilustração dos pacotes disponíveis para os usuários da Fabrikam.