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

Kick-off meeting – iniciando seus projetos ágeis e tradicionais

reunião de Kick-off é importante para determinar o início do projeto, alinhamento dos objetivos, mobilizar os recursos e garantir o entendimento do time de projeto. Em gestão tradicional de projetos, este evento tende a ser mais formal. Já na gestão ágil, focamos em atividades de team building ao invés de detalhes do escopo.

Entre os participantes da reunião, sugiro incluir o patrocinador do projeto, o time chave do projeto, champions, e os usuários finais. O formato e participantes da reunião podem variar de acordo com a cultura da sua empresa. Traga sentido aos envolvidos! Só assim você consegue o engajamento e o senso de importância de todos. Se necessário, faça as adaptações necessárias, por exemplo, trabalhando em um formato híbrido.

A agenda do kick-off pode ter o seguinte formato:

1. Introdução

Apresente os objetivos (goals) e entregáveis (deliverables) do projeto. Aproveite a presença de múltiplos departamentos e empresas na reunião para introduzir as pessoas no projeto. Alinhe o direcionamento do projeto e seus principais benefícios.

2. Time do projeto e responsabilidades

Após a introdução do projeto e apresentação das pessoas, compartilhe quais serão as responsabilidades de cada um no projeto. Neste ponto, é importante um contato preliminar com os gestores de cada departamento, afim de evitar “surpresas” no dia da reunião. Assim, todos os participantes do projeto já terão um alinhamento prévio de suas atividades e poderão contribuir melhor na fase inicial do projeto.

3. Premissas e restrições

As premissas são hipóteses que assumimos verdadeiras (por ainda não termos informações suficientes ou por depender de fatores externos) para fins de planejamento.

  • Liberação dos recursos A, B e C para o projeto
  • Budget disponível para contratação de hosting em Cloud

E as restrições são limitações internas ou externas ao projeto. Por exemplo, requisitos obrigatórios ou até cláusulas contratuais exigidas pelo cliente.

  • O sistema deverá ser publicado até 31/12/2018

4. Plano preliminar do projeto

O plano preliminar do projeto comunica em high level o cronograma, os principais  milestones, o custo (CAPEX e OPEX) do projeto e o modelo de governança (gestão ágil ou tradicional; cadência).

Timeline
Defina um timeline preliminar com as principais entregas do projeto. O time do projeto precisa ter conhecimento para administrar os riscos e tarefas associadas.

timeline

Custos
O custo total do projeto, incluindo o valor dos recursos, infraestrutura, licenças, aquisições de equipamentos, etc.

custos

Governança
Estabeleça a cadência do projeto. Seja em gestão tradicional ou ágil, compartilhe como será o gerenciamento do projeto, as principais reuniões, envolvidos e o time alocado.

cadencia.png

5. Key Success Factors

O que é necessário para o projeto atingir seus objetivos com sucesso? Veja alguns fatores chaves de sucesso nos projetos:

  • Engajamento do time do projeto e áreas relacionadas
  • Governança leve e ambiente agradável
  • Patrocínio onipresente
  • Práticas DevOps e Cloud Solution
  • Outras áreas que podem ser incluídas: planejamento, processos, pessoas, capacidade e estratégia de contingência

Palestra DevOps Days RJ – Continuous Deployment com Azure DevOps

Palestrante: Leonardo Matsumota
Cargo: IT Systems Manager
Evento: DevOps Days – Rio de Janeiro
Tema: DevSOXOps – Continuous Deployment com Azure DevOps em ambientes de compliance
Data: 09/11/2018
Material: DevSOXOps – DevOps Days RJ

image1.jpeg

Tópicos da apresentação

  • Inovação & Controle
    • Time to market
    • Build – test – release – monitor – plan
    • Compliance e auditorias
    • ITGCs – itens de controle
  • SOX – Sarbanes Oxley
  • Processo de Change Management
    • Lead Time
    • Gargalos
    • Processos Manuais
  • Pilar Pessoas
  • Pilar Processos
    • Boas práticas, Continuous Integration e Testes
  • Pilar Ferramentas
    • Microsoft Azure DevOps e extensões

 

Ciclo de vida da aplicação com Azure DevOps – do backlog a homologação

E como está o processo de desenvolvimento e homologação das entregas no seu time? Além da DoD (Definition of Done), recomendo estabelecer um processo que compartilhe as responsabilidades entre as áreas durante o ciclo de vida da aplicação, e assim, garantir a qualidade desde a entrada do backlog até a liberação para homologação.

Veja o diagrama proposto, iniciando a construção do backlog com o PO. O SM facilita o time de desenvolvimento na quebra das histórias em tarefas e estimativas. O time de desenvolvimento utiliza boas práticas (como testes unitários, check-in frequentes, etc.) para liberar a área de QA. Por aqui temos a proposta da execução dos planos de testes e também da automação deles*.

QA-dev-processo
* avalie a maturidade da sua equipe em relação a testes automatizados. Claro, que a automação pode ser incorporada na sua equipe de desenvolvimento.

Azure DevOps possui uma solução completa para te apoiar neste processo. Por exemplo, no Azure Boards podemos criar o backlog da Sprint e gerenciar a capacidade do time. No Azure Pipelines Azure Repos trabalhamos com o desenvolvimento das aplicações, integração contínua e versionamento. E o Azure Test Plans permite criar os planos de testes para estes work items.

azure-devops-01

Azure Boards: além da configuração das Sprints, é imprescindível estruturar o backlog em Epic – Feature – User Story com as tarefas para o time de desenvolvimento executar.

backlog-estrutura.png

Utilize as melhores práticas (INVEST, etc.) para auxiliar o PO a escrever boas estórias com critérios de aceitação claros. As técnicas como planning poker contribuem nas estimativas das histórias.

historias-VSTS

Azure Pipelines e Azure Repos: para mais informações, veja meu post de Pipeline de Build e Release.

azure-devops-pipeline-06.png

Azure Test Plans: o Plano de Testes também pode ser criado no Azure DevOps. Visite este post e veja o passo-a-passo deste processo.