O que é o Azure Artifacts?
Nesta unidade, você terá uma breve visão geral de como usar o Azure Artifacts para criar e gerenciar pacotes com segurança para seus aplicativos consumirem.
Vamos falar novamente com a equipe, que está decidindo se o Azure Artifacts é a melhor maneira de hospedar o pacote do .NET.
Clara: Parece-me que faria sentido hospedar o novo pacote Modelos no Azure Artifacts. Todos já fazemos parte da organização do Microsoft Azure DevOps, assim, a autenticação seria mais fácil do que tentar configurá-la em um gerenciador de pacotes diferentes.
Paulo: Analisei isso antes da reunião e me pareceu simples. Eu concordo com Clara.
Marina: O que é o Azure Artifacts?
Paulo: O Azure Artifacts é um repositório em sua organização do Azure DevOps em que você pode gerenciar as dependências para sua base de código. O Azure Artifacts pode armazenar seus artefatos e binários. Ele fornece um contêiner, chamado de feed, para grupos de dependências. Os desenvolvedores que têm acesso ao feed podem facilmente consumir ou publicar pacotes.
Como faço para criar um pacote e usá-lo no pipeline?
Pedro: Então, se eu estou entendendo bem, o código do aplicativo já usa pacotes do NuGet. Vamos criar nosso próprio pacote e hospedá-lo no Azure Artifacts. Você pode traçar as partes e como elas funcionarão juntas? Estou com dificuldades para imaginar todo o processo.
Paulo: Claro. Vamos repassar o processo de criar um pacote e usá-lo em nosso pipeline do Azure DevOps.
Paulo vai até o quadro de comunicações.
Criar o pacote
Primeiro, precisamos criar um projeto no Azure Artifacts. 
Podemos fazer isso usando o Azure DevOps.
Em seguida, vamos criar um pipeline no Azure Pipelines que se conecte ao repositório do GitHub para o código de pacote. Então, o pipeline compila o código, o empacota e envia o pacote por push para o Azure Artifacts. 
Precisamos atualizar o aplicativo que consome esse pacote para apontar para o feed do Azure Artifacts que criamos. 
Depois disso, atualizamos o pipeline que cria o aplicativo. A atualização nos permite usar nosso feed do Azure Artifacts para efetuar pull da nova dependência de pacote e compilar como sempre. 
Atualizar o pacote
Pedro: E se alguém atualizar o pacote?
Paulo: Quando você atualizar o pacote com um novo recurso ou correção de bug e executar testes para garantir que ele funcione corretamente, aumente o número de versão do pacote. Então faça commit da alteração. O pipeline do pacote verá o commit e criará um artefato no Azure Artifacts com o novo número de versão. Não se preocupe, o pacote antigo com o número de versão inferior ainda está lá para aplicativos que dependem dessa versão. Por esse motivo, você normalmente não remove um pacote da lista.
Nosso aplicativo talvez queira usar essa versão mais nova do pacote. Nesse caso, podemos atualizar o aplicativo para fazer referência à versão mais recente e executar os testes localmente para garantir que essa nova versão funcione com nosso aplicativo. Quando estivermos satisfeitos de que tudo funciona, enviaremos a alteração do aplicativo para o pipeline. Ele é criado com a nova versão da dependência de pacote.
Marina: Esse parece um bom plano e ajudará a outra equipe também. Isso também impedirá que o código sofra desvios, como você disse. Isso ajudará a garantia de qualidade também.
Incluir uma estratégia de controle de versão no pipeline de build
Quando você usa um pipeline de build, os pacotes precisam de versões para que possam ser consumidos e testados. No entanto, somente depois de testar o pacote, você pode saber sua qualidade. Como as versões do pacote nunca devem ser alteradas, é desafiador escolher uma determinada versão com antecedência.
O Azure Artifacts associa um nível de qualidade a cada pacote nos feeds, bem como a distinção entre versões de pré-lançamento e de lançamento. O Azure Artifacts oferece diferentes modos de exibição na lista de pacotes e suas versões, que os separam com base no nível de qualidade. Essa abordagem funciona bem com o controle de versão semântico, que é útil para prever a intenção de uma versão específica. O Azure Artifacts também usa um descritor para incluir metadados adicionais do feed do Azure Artifacts. Um uso comum de exibições é compartilhar versões de pacote que foram testadas, validadas ou implantadas, mas reter pacotes que ainda estão em desenvolvimento e não estão prontos para o consumo público.
Os feeds no Azure Artifacts têm três exibições diferentes por padrão. Essas exibições são adicionadas no momento que um feed é criado. Os três modos de exibição são:
- Lançamento: a exibição @release contém todos os pacotes considerados versões oficiais.
- Pré-lançamento: a exibição @prerelease contém todos os pacotes que apresentam um rótulo no número de versão.
- Local: a exibição @local contém todos os pacotes de lançamento e pré-lançamento, bem como os pacotes baixados de origens upstream.
Você pode usar exibições para ajudar os consumidores de feed de pacotes a filtrar entre versões lançadas e não lançadas de pacotes. Essencialmente, as exibições permitem que um consumidor tome uma decisão consciente ao escolher pacotes de lançamento ou aceitar pré-lançamentos com um determinado nível de qualidade.
Segurança do pacote no Azure Artifacts
Garantir a segurança de seus pacotes é tão importante quanto garantir a segurança do restante do código. Um aspecto da segurança do pacote é proteger o acesso aos feeds do pacote (em que um feed, no Azure Artifacts, é o local em que você armazena os pacotes). A definição de permissões no feed permite compartilhar os pacotes com o número de pessoas que o cenário exigir.
Permissões do feed
Os feeds têm quatro níveis de acesso: proprietários, contribuidores, colaboradores e leitores. Cada nível de acesso tem um determinado conjunto de permissões. Por exemplo, os proprietários podem adicionar qualquer tipo de identidade, sejam indivíduos, equipes ou grupos, em qualquer nível de acesso. Por padrão, o serviço de build da coleção de projetos é um colaborador, e sua equipe de projeto é um leitor.
Configurar o pipeline para acessar as classificações de segurança e licença
Há várias ferramentas disponíveis de terceiros para ajudá-lo a avaliar a classificação de segurança e licença dos pacotes de software que você usa.
Algumas dessas ferramentas verificam os pacotes conforme eles são incluídos no pipeline de build ou de CD. Durante o processo de build, a ferramenta verifica os pacotes e fornece feedback instantâneos. Durante o processo de CD, a ferramenta usa os artefatos de build e executa verificações. Dois exemplos dessas ferramentas são Mend Bolt e Black Duck. Com o Azure DevOps, você usa tarefas de build para incorporar a verificação ao seu pipeline.