Partilhar via


Gráficos de pacote em Artefatos do Azure

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

Ao lançar 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 seu 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 o feed A upstreams para alimentar B, que upstreams para alimentar C e, eventualmente, alimentar C upstreams 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 solicitações A de B, depois solicitações B de C e, finalmente, solicitações C de volta para A, formando um loop.

As fontes a montante são concebidas 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 consultar o 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 tenham sido 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 através de uma fonte upstream de outro feed podem resolver com sucesso 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 fontes 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 a instalar apenas as versões 1.0.0 e 3.0.0 do pacote Gizmos. O mesmo se aplica ao feed AdventureWorks, onde 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 a montante.

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 de 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.