Service Hooks no Azure DevOps – gerenciador de eventos

Service Hooks é um recurso (event handlerdo Azure DevOps para trabalhar com ações baseadas em eventos que aconteçam em seus projetos. Em um post recente, demonstrei o uso do Service Hooks para escrever mensagens no Slack, mediante evento no Azure DevOps. Geralmente, o event handler executa um código hospedado em servidor remoto.

Como estrutura, o Service Hooks possui tipicamente três partes:

  • Publishers: são os eventos do Azure DevOps
  • Subscribers: criados a partir dos eventos
  • Consumers: componente ou serviço externo que é acionado pela subscription

E os atuais serviços disponíveis como destino do Service Hooks são:

service-hooks-availablePor aqui, vamos trabalhar com Web Hooks, utilizando o Azure Functions no Portal Azure. Criaremos uma nova função serverless, que será executada a partir de um evento configurado no Azure DevOps.

Inicie pela instalação de um novo Aplicativo de Funções. Acesse + Criar um recurso > Computação > Aplicativo de Funções e escolha a opção Criar.

azure-function-app

Em seguida, acesse Aplicativo de Funções e crie uma nova função (+ Functions). Escolha o ambiente de desenvolvimento no passo 1.

azure-functions

No passo 2, escolha o método de deployment (direto no VS ou utilizando o Deployment Center).

azure-functions-02

Feita a configuração no Aplicativos de Funções, faça a publicação da função neste serviço de aplicativo. No Visual Studio, crie um novo projeto em Cloud > Azure Functions. Após o desenvolvimento da função, escolha a opção Publicar.

Na janela inicial (Escolher um destino de publicação), selecione o serviço de aplicativo que acabamos de configurar. E então na próxima janela clique em publicar. Copie o link gerado.

azure-function-VS

Agora no Azure DevOps, acesse o Project Settings do projeto e uma nova subscription no Service Hooks.

service-hooks-azure-devops

Escolha qual será o Trigger para disparar a ação. No meu exemplo, defini que na modificação de um Work item, será executada a Action que é a função criada anteriormente.

service-hooks-subscription

Pronto! O Web hooks foi criado e podemos visualizar no histórico que a cada vez que o evento acontecer (neste caso a modificação no work item), a ação de executar a função será realizada.

service-hooks-status

Gerenciamento de Configuração e Orquestração com Puppet, Chef, Ansible e SaltStack

Continuando nossos artigos sobre Devops, vamos comparar as principais ferramentas  de Gerenciamento de Configuração que apoiam a automação da infraestrutura na sua empresa: Puppet, Chef, Ansible e SaltStack. As ferramentas de CM são projetadas para instalação e configuração dos servidores.

Já as soluções de Orquestração como CloudFormation e Terraform são projetadas para provisionar os servidores. Atualmente, as soluções passaram a incorporar os dois recursos (configuração e orquestração). A gestão eficiente considera a operação em larga escala, complexidade de  configuração, distribuição de recursos, desempenho, confiabilidade, compliance, etc.

Veja um resumo comparativo entre eles:
CM-tools

Imagem relacionada Ansible
Plataforma de gestão da configuração, orquestração, provisionamento simplificado, deployment de aplicações e workflow automatizado para CD. Permite comandos em YAML e oferece modelos push para a execução sequencial dos módulos de comando (com segurança SSH). Não exige agentes em todos os sistemas.

A orquestração é um diferencial por trabalhar com atualizações contínuas (de zero  downtime) para aplicações de várias camadas. Site: https://www.ansible.com/

Resultado de imagem para chef logo devopsChef
Plataforma de automação da infraestrutura, cloud (flexível) e DevOps workflow. Permite a instalação de aplicações em VMs e containers. A arquitetura utiliza o modelo master-agent (com respostas via SSH), abordagem pull e execução sequencial.

O diferencial é a estabilidade em deployments de larga escala. Site: https://www.chef.io/

Resultado de imagem para puppet logo Puppet
É uma solução de orquestração de deployments, provisionamento automatizado e automação da configuração para aplicações distribuídas e infraestrutura. Dispõe de templates DSL (Domain Specific Language) e ERB (Embedded Ruby) para criar arquivos Puppet. Site: https://puppet.com/.


Resultado de imagem para SaltStack logo devops SaltStack

Projetada para orquestração e automação de CloudOps e ITOps. Possui recursos de monitoramento, continuous code integrationdeployment. Utiliza YAML, modelo push e execução de comandos via SSH. Suporte aos modelos master-agent e descentralizado.

O diferencial é que habilita a comunicação de baixa latência e alta velocidade para coleta de dados. Site: https://saltstack.com/.

.NET – Projetos de testes com SpecFlow e Visual Studio

Iniciamos o SpecFlow no Azure DevOps em um post anterior e agora vamos demonstrar a aplicabilidade do SpecFlow utilizando o Visual Studio. Comece adicionando o SpecFlow for Visual Studio em Extensões e Atualizações.

specflow-vs

Em seguida, crie dois novos projetos: 1) Projeto de Teste de Unidade 2) Projeto a ser testado, no meu caso utilizei Biblioteca de Classes (.NET Framework).

specflow-unit-test

No projeto de Teste, clique com o botão direito e “Gerenciar pacotes do NuGet…”. Adicione o SpecRun.SpecFlow.

specflow-nuget

Ainda no Projeto de Teste, adicione um novo item > SpecFlow Feature File. No arquivo da feature gerado, clique com o botão direito no código e “Generate Step Definitions”.

specflow-feature

Um arquivo .cs será criado com a estrutura do teste a ser realizado. Utilizamos uma classe bem simples (arquivo Class1.cs do projeto ClassLibrary1) para realizar os testes. Lembre-se de no Projeto de Teste referenciar:

using Microsoft.VisualStudio.TestTools.UnitTesting;
using ClassLibrary1;
(adicione a referência com o botão direito Adicionar > Referência > Projeto > Solução > checar o projeto a ser testado)

specflow-vs-final.pngvs-class

Iniciando com Package Management no Azure Artifacts – Azure DevOps

Com a chegada do Azure DevOps, um novo recurso bem interessante foi incorporado na solução de DevOps – o Azure Artifacts. A partir dele podemos gerenciar feeds de pacotes (NuGet, Maven e npm) integrado aos pipelines de Build e Release.

Os feeds são configurados por padrão para utilizar fontes públicas (como upstreams). E assim, upstreams ativos ajudam a proteger contra interrupções de provedores públicos de pacotes.

Vamos começar a utilizar? Acesse o Artifacts no Azure DevOps e crie um novo feed. Nas configurações, insira o nome do Feed, a visibilidade (organização ou pessoas específicas que poderão visualizar) e os pacotes que serão utilizados.

azure-artifacts-feed

Em seguida, clique em Connect to feed. No exemplo, vou utilizar o Get do próprio NuGet, mas veja que há outras opções disponíveis, como npm, Maven e Gradle.

feed-artifacts

Acesse o Visual Studio, e na solução da sua aplicação, escolha a opção de Gerenciar Pacotes do NuGet para a solução.

manage-nuget-vsts

Clique no símbolo da engrenagem (lado direito superior), e insira uma nova Origem de Pacote, utilizando o símbolo verde +. Configure então o nome e a origem, que é o link exibido no Azure DevOps, quando executamos o Connect to feed. Desabilite a opção anterior para manter o time utilizando o novo feed como opção primária.

nuget-vs

De volta ao Azure DevOps, acesse o seu Build Pipeline e crie uma tarefa de NuGet. Altere a opção de Command para push, e o Target Feed  para o Feed que criamos anteriormente.

nuget-azure-devops

Após a execução do Build, veja no Log que a tarefa de NuGet push está entre as tarefas executas com sucesso.

build-azure-devops-nuget

Agora em Artifacts, podemos visualizar os pacotes publicados no feed do seu time. Podemos então consumi-los em outras soluções.

artifacts-azure-devops

De volta ao Visual Studio, abra a solução de outro time, por exemplo, e acesse “Gerenciar Pacotes do NuGet para a solução” (botão direito em cima da solução). Confirme se “em origem do pacote” (canto direito superior) está selecionado o feed correto. Os pacotes do feed estarão disponíveis para uso. Selecione o que será utilizado e clique na opção “Instalar”.

nuget-vs-install.png

E assim os pacotes estarão disponíveis para esta solução também. Aproveite então este novo recurso de Artifacts do Azure DevOps.

 

 

BDD e ATDD com SpecFlow no Azure DevOps

SpecFlow é um ótimo recurso para trabalhar com a gestão e execução automática dos testes de aceitação human-readable (sintaxe Gherkin que possui uma linguagem facilmente compreendida e acessível ao time do projeto) no ciclo de desenvolvimento de sistemas. É considerado o Cucumber do .Net.

SpecFlow

A ferramenta é open source BDD (Behavior-driven development)/ATDD (Acceptance test–driven development) e utiliza o analisador Gherkin. Possui suporte ao framework .Net, Xamarim e os de testes MSTest, NUnit e xUnit 2. Também faz a integração com o Visual Studio.

specflow

Adicionalmente, o SpecFlow+ é um recurso para integração com o Test Explorer do Visual Studio, Excel, LivingDoc, entre outros. Neste post, vamos ver o uso da extensão do SpecFlow+ LivingDoc no Azure DevOps e como auxiliam a construir uma documentação “viva” do sistema. Os arquivos Gherkin podem ser visualizados diretamente no Azure DevOps.

O passo inicial é acessar o Marketplace (Visual Studio) e baixar o SpecFlow+ LivingDoc e o Report Generator for SpecFlow. Em seguida, adicione a uma etapa do Build Pipeline.

specflow-tasks

Nas configurações do SpecFlow+, referencie o projeto criado no Visual Studio. Veja como criar como o SpecFlow no Visual Studio. Em seu projeto, você irá descrever a feature e o cenário de teste.

specflow-tasks-vsts

Por fim, acesse a área Test Plans > SpecFlow+ no Azure DevOps. Veja as informações disponíveis do uso do SpecFlow nos Builds. Ao lado direito da janela, você poderá manipular a licença de uso, que inicialmente estará em “evaluation mode”.

specflow-licence

Build Azure DevOps – checando vulnerabilidades com WhiteSource Bolt

No último post sobre DevSecOps, demonstramos como instalar o componente do WhiteSource Bolt no Azure DevOps e utilizá-lo nas definições de Build do seu pipeline. É altamente recomendável incluir verificações de vulnerabilidades no seu processo de desenvolvimento, e assim evitar o deploy de aplicações suscetíveis a invasões.

Componentes desatualizados, alertas e relação dos dados com políticas pré-definidas da empresa são os principais recursos da ferramenta. O gráfico abaixo da Forrester Wave™: Software Composition Analysis (SCA) Q1 2017 exibe a presença de mercado do WhiteSource Bolt e a comparação com outras soluções.

Forrester wave

Após a execução do Build da aplicação, veja que o histórico de scan e relatórios de vulnerabilidades ficam na área de Pipelines > WhiteSource Bolt. Na parte superior, fica disponível as definições de Build que utilizaram o componente e as últimas verificações. Também há um botão para exportar o relatório. Na parte de Security há um resumo distribuído em quatro quadros:

  • Vulnerability Score: resumo da classificação – Low | Med | High das aplicações analisadas, de acordo com a National Vulnerability Database (NVD).
  • Vulnerable Libraries: quantifica os componentes e bibliotecas vulneráveis. O quadro verde exibe a quantidade de itens analisados e que não foram encontradas vulnerabilidades; o vermelho exibe a quantidade de itens com vulnerabilidade.
  • Severity Distribution: dos itens classificados como vulneráveis, quantos são de risco alto, médio e baixo.
  • Aging Vulnerable Libraries: há quanto tempo foi identificada a vulnerabilidade.

whitesource-bolt-vsts

O relatório de Security Vulnerabilities traz todas as vulnerabilidades encontradas e a ação recomendada para corrigi-las. A coluna Description aponta o risco identificado naquele componente. E a coluna Top Fix descreve a recomendação para corrigir. Entre as principais estão a atualização de versão e substituição por outro componente.

security-vulnerabilities

Em seguida, o License Distribution identifica os tipos de licenças associadas aos componentes utilizados e a classificação de risco para cada uma. O link presente em cada linha direciona para o site oficial daquele provedor. O histograma (na direita) facilita a visualização, agrupando por tipo de risco. O tipo Unknown identifica as licenças que não foram analisadas por especialistas legais da WhiteSource.

license-risks

Por fim, o Outdated Libraries relaciona os componentes e bibliotecas presentes nas aplicações analisadas e que não estão atualizadas em suas últimas versões. O Inventory  é o inventário de todos os componentes open source identificados.

outdated-librariesinventory

Para mais detalhes, sugiro acessar a documentação completa no site da WhiteSource Bolt.

Automação de testes com Selenium e Azure DevOps

Compartilho aqui o link dos artigos publicados em três revistas de um case de sucesso com automação de testes utilizando o Selenium. Neste projeto utilizamos o Azure DevOps da Microsoft como solução para gestão das atividades, processo de integração contínua e planos de teste.

“Utilizar ferramentas como o Azure DevOps e Selenium, entre outros serviços do Portal Azure (Microsoft), foram fundamentais na gestão de projetos ágeis como esse, integração contínua, hospedagem, monitoramento e qualidade das entregas” Leonardo Matsumota.

revistas-automacao-teste.png