ALM, DevOps

Série Azure DevOps #2 – Configurando seu ambiente

Uma vez escolhido o Azure DevOps com sua ferramenta, precisamos configurar o ambiente com detalhes fundamentais para uso dos serviços e dos projetos criados.

Acessando a home page da ferramenta (https://dev.azure.com/suaconta/) podemos personalizar o ambiente com um todo, usuários, licenciamento, projetos, autenticação e muito mais. Vamos conhecer um pouco desta opções.

Lembrando que toda instância possui sua configurações individualizadas.

Entendendo as principais configurações do Azure DevOps

General >> Overview

Neste sessão podemos ter acesso aos dados gerais da instância entre as principais podemos destacar:

  • Name
    • Nome da instância escolhida. Basicamente é através dela que acessamos nossa ferramenta, tanto via browser quanto através de ferramentas complementares como Visual Studio, Eclipse, etc. É importante saber que podemos alterar este nome a qualquer momento, desde que ele ainda esteja disponível, e claro sempre que ele for alterado todo e qualquer ferramenta que esta acessando a instância precisará ser reconfigurado.
  • Organization owner
    • Principal “dono” da ferramenta aqui temos a conta que tem poder máximo dentro do ambiente, sempre recomendamos que aqui esteja uma conta ligado a sua empresa evitando assim que o acesso a estas informações sejam perdidas.
  • Delete organization
    • Esta opção nos permite excluir a instância criada da ferramenta, bem como todo seu conteúdo, portanto cuidado. Também podemos salientar que ao confirmar a exclusão a instância fica desativada por 30 dias, excluído efetivamente após este período.
  • Billing Information
    • Aqui temos a associação de uma assinatura Azure, esta assinatura será responsável pela cobrança de eventuais gastos com sua instância, como licenciamento de novos usuários ou mesmo compra de novos recursos ou ferramentas.

General >> Projects

  • Projects
    • Com Azure DevOps podemos gerenciar o ciclo completo de DevOps de diversos produtos de uma organização. Nesta sessão podemos criar, renomear e excluir projetos (produtos em desenvolvimento). Cada projeto criado deve seguir um processo como modelo, além de liberar o uso dos recursos da ferramenta citados no artigo Série Azure DevOps #1 – Començando, de maneira individualizada para cada projeto.

Para criarmos novos projetos é simples, basta clicar no botão New team project… e preencher os dados como Project name, Description, Visibility, Version control e o modelo de processo em Work Item Process.

General >> Users

  • Manage user
    • Para que um usuário possa ter acesso ao Azure DevOps é necessário que o administrador da ferramenta o inclua na lista de usuário nesta sessão, e também atribuir uma licença de uso. Portante nesta interface pode fazer toda a gestão de usuários e licenciamento dos mesmo.
    • Licenças no Azure DevOps (Access level)
      • Basic
        • A Microsoft fornece até cinco licenças gratuitas, este acesso permite que o usuário seja colaborador ativo do projeto, tendo acesso recursos como controle de versão, ferramentas de gestão ágil, build e releases.
      • Stakeholder
        • Usuários ilimitados na ferramenta, usuários com este tipo de acesso tem acesso a recursos como gestão de backlogs, atividades através dos Work Items e as consultas ou queries.
      • Visual Studio Subscriber
        • Este tipo de acesso também é ilimitado e faz um associação com a licença Visual Studio atribuída para o usuário, ou seja, o usuário incluído com esta licença precisa ter um licença de Visual Studio relacionado ao seu usuário. Este usuários tem acesso aos mesmo recursos de uma licença Basic, e em alguns casos estes usuários podem ter acesso a recursos adicionais como extensões especificas e ao Test Manager.
    • A gestão de usuários pode ser feito individualmente ou através do que chamamos de Group Roles, facilitando a gestão.
Adicionando usuário ao Azure DevOps
Criando grupos de acesso ao Azure DevOps

General >> Global Notification

  • Notifications
    • Central de notificações globais do projeto. Aqui conseguimos visualizar e desabilitar notificações por e-mail. Estas notificações são administradas para todo projeto.
    • Sessões
      • Default subscriptions
        • Visualizamos todas as assinaturas de notificação padrão do projeto.
      • Subscribers
        • Visualizamos as inscrições de notificação para um grupo, equipe ou indivíduo específico.
      • Statistics
        • Visualize as assinaturas mais ativas e os principais iniciadores de eventos
      • Settings
        • Aqui conseguimos gerenciar as configurações no nível da organização, como preferências de entrega nas notificação.

General >> Usage

  • Usage
    • Como qualquer outra ferramenta em nuvem vendida como serviço o Azure DevOps utiliza multilocação para obtermos redução de custo e para melhorarmos a escalabilidade. Para isso o Azure DevOps limita os recursos que os usuários podem consumir e o número de solicitações que podem fazer para determinados comandos. Quando esses limites são excedidos, as solicitações subsequentes podem ser atrasadas ou bloqueadas.
    • Azure DevOps Services Throughput Units (TSTUs)
      • Todos os serviços compartilhados e disponibilizados pelo Azure DevOps consumem muitos recursos. Atividades como upload de uma grande quantidade de arquivos ao Git, ou por exemplo a execução de uma consulta de acompanhamento complexa de itens de trabalho criará carga em um Banco de Dados SQL do Azure, com a quantidade de carga, dependendo do número de itens de trabalho na organização. Todas estas operações consomem CPU e memória em uma ou mais camadas de aplicativos ou agentes de trabalho do Azure DevOps Services. Este consumo de recursos dos serviços do Azure DevOps é expresso em unidades abstratas chamadas Azure DevOps Services Throughput Units (TSTUs)
    • Nesta tela podemos fazer a monitoria das requisições e consumos que os usuários estão fazendo na instância do seu Azure DevOps.

General >> Extensions

  • Extensions
    • O Azure DevOps é uma ferramenta muito completa, mas todos sabemos que uma ferramenta realmente completa permite que seus usuários possam customizar e criar novos recursos claro tudo isso seguindo os padrões da mesma. A Microsoft portanto nos permite customizar, criar recursos os quais estão disponíveis em uma plataforma chamada Marketplace (https://marketplace.visualstudio.com/azuredevops) que nos permite consumir estas criações em nossa instância.

General >> Azure Active Directory

  • Azure Active Directory
    • O Azure DevOps permite que pessoas acessem a mesma através de contas Microsoft, ou via o serviço de Azure Active Directory. Para que possamos fazer a ligação da instância com o Azure utilizamos esta sessão.

Secutiry >> Policies

  • Política
    • Aqui podemos configurar/habilitar os modelos de autenticação/conexão que utilizaremos na instância.
    • Políticas de conexão de aplicativos
      • Alternate authentication credentials
        • Permite a criação de credenciais unicas para o acesso de aplicações não nativas. Como por exemplo o acesso as APIs REST do Azure DevOps com autenticação básica devemos ter esta opção habilitada.
      • Third-party application access via OAuth
        • Serve para gerar tokens para acessar APIs REST do Azure DevOps e do Team Foundation Server. Estas APIs de perfil suportam apenas o OAuth.
      • SSH authentication
        • Permite gerar chaves de criptografia para usarmos autenticação via Lunux, MacOS ou Git para Windows. Além disso conseguimos gerar o Personal Access Tokens (PAT) tudo isso para https.
    • Políticas de segurança
      • Allow public projects
        • Permite a criação de projetos públicos dentro de sua instância de Azure DevOps.

Security >> Permissions

  • Permissions
    • Nos permite fazer a gestão do permissionamento da instância do Azure DevOps. Aqui temos os grupos padrões da ferramenta, sendo eles:
    • Project Collection Administrators
      • Os membros deste grupo podem executar todas as operações privilegiadas na dentro da coleção de projetos.
    • Project Collection Build Adminstrators
      • Os membros desse grupo possuem poder para administrar os recursos de Build.
    • Project Collection Build Service Accounts
      • Os membros desse grupo são contas de serviços usadas para execução e administração dos serviços de Build da collection.
    • Project Collection Proxy Service Accounts
      • Este grupo deve contar contas de serviço utilizadas nas configurações de Proxy configuradas para iteração com esta coleção de projetos.
    • Project Collection Service Accounts
      • Grupo com contas de serviços da coleção de projetos.
    • Project Collection Test Service Accounts
      • Este grupo deve contar contas de serviço utilizadas por Test Controllers conectados com esta coleção de projetos.
    • Project Collection Valid Users
      • Contém todos os usuários que possuem acesso a coleção de projetos.
    • Security Service Group
      • Os usuários que recebem permissão explícita para um recurso serão automaticamente adicionadas a este grupo se não forem anteriormente membros de qualquer outro grupo.

Boards >> Process

  • All processes
    • Processes
      • Como já comentado anteriormente todo projeto dentro do Azure DevOps deve seguir um modelo de processo. A Microsoft fornece dentro da ferramenta quatro modelos para iniciarmos os trabalhos. A partir desta sessão podemos criar projetos baseado em algum dos processos, além de trocar o processo de algum outro anteriormente criado.
      • Modelos
        • Basic
          • Esse modelo é flexível para qualquer processo e ótimo para equipes que estão começando com o DevOps do Azure.
        • Agile
          • Modelo funcionará muito bem para a maioria das equipes que usam métodos de planejamento ágeis, incluindo aqueles que praticam o Scrum.
        • Scrum
          • Este modelo é para equipes que seguem o framework Scrum.
        • CMMI
          • Este modelo é para projetos mais formais que exigem uma estrutura para melhoria de processos e um registro auditável de decisões.
    • Fields
      • Todas as informações armazenadas dentro do Azure DevOps é feita através dos processos e seus campos. Nesta sessão temos todos os campos usados dentro dos modelos de processos, aqui também podemos criar novos campos pensando em uma futura customização. (veremos mais sobre a customização de processos nos próximos artigos)

Pipelines >> Agent pools

  • Agent pools
    • Aqui temos os agentes e as filas disponibilizadas pela Microsoft para utilizarmos no processo de Build e Release dos projetos. Podemos também configurar agentes locais dentro de uma infraestrutura própria.
    • Dentre os agentes e filas disponibilizados pela Microsoft hoje temos:
      • Default
      • Hosted
      • Hosted macOS
      • Hosted Ubuntu 1624
      • Hosted VS2017
      • Hosted Windows 2019 with VS2019
      • Hosted Windows Container
Processo de instalação de agentes locais

Pipelines >> Deployment pools

  • Deployment pools
    • Aqui podemos criar um conjunto de máquinas para deployment em grupo. Estes grupos são disponibilizados por projetos e suas configurações são feitas por sistema operacional, todos os agentes são instalados via PowerShell

Pipelines >> Retention and parallel jobs

  • Retention and parallel jobs
    • Todo trabalho envolvido no processo de pipeline do Azure DevOps é feito através de filas e agentes e Microsoft disponibiliza estes recursos gratuitamente respeitando a seguinte configuração:
      • Projetos Privados
        • Microsoft-hosted: 1 job com 1800 minutos por mês. (estes valores respeitam a data de 26/03/2019)
        • Self-hosted: 2 jobs, sendo 1 free e 1 para assinantes do Visual Studio Enterprise.
      • Projetos Públicos
        • Microsoft-hosted: 10 jobs gratuitos
        • Self-hosted: Ilimitado
    • Portanto nesta sessão podemos fazer a administração e licenciamento do serviços de agentes de pipelines do Azure DevOps.

Pipelines >> OAuth configurations

  • OAuth configurations
    • Nos permite configurarmos uma conexão com um repositório GitHub, permitindo conexão a servidores Git externos no padrão do GitHub.

É realmente temos muitas configurações, mas para uma ferramenta como Azure DevOps, pode acreditar são poucas.

Até o próximo artigo da série

Aproveitem e até o próximo artigo da série!!!

Não quer perder mas nenhuma informação sobre ALM, DevOps e Cloud, então não esqueça de me acompanhar nas redes sociais

Deixe uma resposta