Testes exploratórios com Request Feedback no VSTS

Dando continuidade ao ALM – ciclo de vida da aplicação

O VSTS da Microsoft oferece um recurso muito bom para validar as estórias com os usuários. Trata-se do Request Feedback, disponível na guia Test da ferramenta.

Com ele, o usuário pode realizar testes exploratórios e prover feedback ao time de desenvolvimento com os recursos de gravar vídeos, capturar telas ou gravar comentários que ficam associadas a uma determinada estória.

Para instalar, basta clicar no botão Install Now conforme imagem abaixo. Será direcionado ao Marketplace do Visual Studio.

request-feedback-install

Escolha a extensão para o navegador desejado e adicione o Test & Feedback.

request-feedback-extension

Configure a conexão com o servidor do VSTS, informando a URL do seu projeto. Em seguida, todas as outras opções estarão disponíveis (Capture screen | Note | Record Screen | Create bug | Create task | Create test case).

Escolha um Work Item para avaliar (lado direito da imagem abaixo), clicando em explore selected work item. O usuário deve então verificar se o critério de aceitação da tarefa foi cumprido. Utilize os recursos do feedback request para registrar a validação.

request-feedback-connection

No exemplo abaixo, fiz uma consideração (Note) com relação a cor das estrelas de avaliação.

request-feedback-note

E tirando um Screenshot para facilitar o entendimento do time de desenvolvimento.

request-feedback-screenshot

Tudo isso ficará associado ao User Story (em template Scrum) ou Requirement (em template CMMI) como histórico.

Também podemos solicitar o Request Feedback direto na US ou Requirement (imagem da esquerda). Um e-mail será enviado ao usuário, solicitando a validação. Veja (imagem da direita) que há um campo de instruções para descrever ao usuário o que deve ser feito na validação.

request-feedback-work-item

O usuário receberá então o e-mail de feedback request. Ao clicar em Provide Feedback, terá acesso aos mesmos recursos apresentados anteriormente (Capture screen | Note | Record Screen | Create bug | Create task | Create test case).

provide-feedback

Ao realizar a validação, veja que no US ou Requirement ficará registrado um novo work item do tipo Feedback Request com os registros feitos.

feedback-request

Post To Slack com VSTS – interação de build e release com mensagens

Post To Slack é uma extensão bem valiosa para os times de desenvolvimento que já trabalham com a ferramenta de colaboração Slack (tecnologia social) e VSTS em CD/CI.

aplicabilidade que vamos demonstrar neste Post é de postagem de mensagens nos canais dos grupos a cada promoção da Release em ambientes diferentes – por exemplo, servidor de Dev | Homolog | Produção.

E qual a finalidade disso? Fica algumas sugestões:

  • Notificar a equipe sobre a disponibilidade de uma nova release em um ambiente
  • Também pode ser utilizado nas tarefas de build
  • Facilidade na comunicação entre os membros do time
  • Apoiar o processo de gestão da mudança e transição de ambientes


Marketplace
Para começar a utilizar o Post To Slack, acesse o Marketplace da Microsoft (o link está disponível em Extensões do VSTS) e busque pelo nome: Post To Slack. Em seguida, será enviada a requisição para aprovação. No VSTS, acesse Extensões e na guia Requested, basta fazer a aprovação e acionar a instalação do mesmo.

post-to-slack

Post To Slack – VSTS
Após a instalação, já podemos utilizá-lo no Agent Phase das tarefas de Build Release. Mas, será necessária a configuração do Token para interagir com o Slack. No exemplo abaixo, utilizamos nas tarefas da Release, incluindo a mensagem e o canal do Slack onde serão publicadas.

post-to-slack-release

Slack
Feito o deploy da release mencionada anteriormente, a mensagem é postada no canal do Slack. E assim, o time todo será notificado, principalmente o responsável pela Release.

slack-vsts

 

 

 

VSTS – Pipeline de releases e gestão da mudança com aprovadores

Contexto: já vimos os benefícios e desafios dos processos de CI (Continuous Integration) e CD (Continuous Delivery) em outros posts. Além de habilitar esteiras velozes e eficientes para publicação de releases, é um dos pontos determinantes na adoção de práticas DevOps na empresa.

Este post é direcionado as empresas que possuem processos mais formais, regidos por compliance.release neste caso depende de aprovações como do gestor da mudança (change management) e outras áreas, como a homologação do solicitante (geralmente o Product Owner), antes de ir para a produção.

VSTS – Configurando aprovações no pipeline de releases
Iniciamos criando uma nova definição de release. Para isso, acesse o VSTS na opção de Build and Release. Em Releases, clique em + Create Release Definition. A janela abaixo será aberta com as configurações da release. Escolha os ambientes (environments) e artefatos que serão trabalhados.

release

Em seguida, todas as Releases criadas serão exibidas na tela. Neste exemplo já haviam outras releases criadas, por isso apareceram várias. Clique em Edit para configurar o Pipeline com os Artefatos e Tarefas da release.

releases.png

O Pipeline habilita a configuração Artefato (na esquerda) e dos Ambientes (na direita). É nesta área que definimos os aprovadores, triggers e agendamento das tarefas.

pipeline-releases

Artefato
Ao adicionar um novo artefato, escolha o tipo do artefato – Build | Source Control | etc., referencie o nome do projeto e as definições de Build (por termos escolhido o Build no source type). 
artifact-release

Environments
Ao adicionar os ambientes em + New Environment, podemos criar por exemplo, os ambientes de desenvolvimento, homologação e produção. Utilize a opção clone environment após a criação do primeiro ambiente para copiar as configurações (se aplicável) a fim de facilitar.

Com os ambientes criados, clique na própria caixa do ambiente para configurar as tarefas que serão executadas pelo Agent (lado direito da imagem abaixo).

release-environments

Também na configuração do ambiente, mas no canto esquerdo da caixa há uma imagem que representa triggers e aprovadores para pré ou pós deployment. Clique nela:
trigger-approval

Em seguida, será exibida uma tela com a configuração de Pre-deployment:

  • Triggers: define se o evento acontecerá After release | After Environment | Manual Only
  • Pre-deployment approvals: insira os usuários que precisam aprovar a release antes de subir em produção, ou mesmo no ambiente de QA.
  • Schedule: se o build (que inicia a execução das releases) não estiver automático, esta opção permite agendar a execução das releases.

 

O acompanhamento do deploy das releases está disponível na aba Logs. O status de cada etapa e em qual ambiente está sendo executado pode ser visto no lado esquerdo da tela.release-log

As aprovações podem ser gerenciadas na guia Summary da conta do aprovador. Ao clicar em Approve or Reject, será aberta a janela para realizar a aprovação.

release-approval

Kanban, produção empurrada e puxada em sistemas de TI

Produção Empurrada, Produção Puxada e Sistema Misto

Os conceitos de produção empurradaprodução puxada surgiram nas década de 50 e 60, com a necessidade de atender a demanda de clientes na indústria. A evolução do modelo ocorreu principalmente com o Sistema Toyota de Produção, modelo para suportar o JIT (Just In Timee Kanban, método visual para controle de produção e prever gargalos no processo.

toyota-kanbanImagem: Blog Toyota


Produção empurrada (push system)
A empresa trabalha com produção em grandes lotes, mais voltada para estoque. O planejamento é baseado em estudo de mercado (atender sazonalidades) e histórico de vendas. A divulgação dos produtos é outra forma para obtenção de caixa e justificar a produção em escala.

push-pull-system

Produção puxada (pull system)
Baseia-se na demanda e estoque reduzido, sendo a produção iniciada a partir da demanda do cliente. Para isso, deve ter um sistema eficiente de produção, sem gargalos e com prontidão no atendimento. O JIT (Just in Time) é um sistema muito conhecido e utilizado neste contexto. Visa a redução de custos, eliminação de desperdícios e estoque de produtos.

Sistema misto
Ocorre quando os dois conceitos (empurrada e puxada) são utilizados juntos pela empresa no fluxo de valor completo ou uma parte do processo.

Aplicando os conceitos em TI: Kanban Agile

Trazendo os conceitos industriais a TI, a principal aplicabilidade do Kanban é na área de  desenvolvimento de sistemas. As tarefas que estão no backlog do time devem ter uma esteira de publicação contínua e sem gargalos. Só assim, conseguimos atender as demandas do mercado, como campanhas publicitárias e mudanças de requisitos.

Quando aplicado o Sistema Kanban, devemos considerar:

  • Geração de valor das entregas
  • Visualização das tarefas e o limite de WIP (work in progress)
  • Sistema puxado
  • Tornar os problemas explícitos e engajar as pessoas na mudança

O widget de Flow do VSTS (Visual Studio Team Services) da Microsoft projeta a visualização das tarefas: backlog (proposed) x WIP (active / resolved) x concluído (closed):flow-vsts

Também considere as seguintes métricas:

  • Lead Time: tempo entre a criação da tarefa até a conclusão (estado final)
  • Cycle Time: considera o tempo entre a tarefa “em progresso” até a conclusão
  • Throughput: capacidade de vazão das tarefas
    throughput

E as estimativas das tarefas? No Kanban, a previsibilidade é obtida pelo comportamento observado do sistema. Se o Lead Time, por exemplo, tiver em média 3 horas, este é o tempo em que a tarefa deverá estar em produção. Em geral, a variação do Lead Time está associado ao WIP não limitado, bloqueios e o tipo de demanda.

O controle visual do processo pode ser configurado utilizando o VSTS. No board visualizamos as atividades que estão a FAZER (Proposed), EM PROGRESSO (Active / Resolved) e FEITO (Closed). O template utilizado do VSTS foi o CMMI, por isso fizemos uma relação dos status das atividades com o Kanban convencional.

vsts-kanban

 

Integração SonarQube com VSTS

Continuando o processo de CI (Continuous Integration) e CD (Continuous Delivery), o SonarQube é uma excelente ferramenta open source de análise de qualidade do código-fonte. Os times de desenvolvimento utilizam no processo de DevOps pipelines de integração contínua para inspecionar regularmente a qualidade dos Builds, entre eles, bugs, vulnerabilidades, code smellscode coverage.

A extensão do SonarQube pode ser instalada, acessando o Marketplace da Microsoft:

sonarqube-marketplace

Agora no VSTS, o primeiro passo é configurar o servidor SonarQube como um serviço endpoint do seu projeto. Acesse o Services no VSTS e escolha a opção + New Service Endpoint. Defina o nome da conexão e servidor de URL no SonarQube Server e o Authentication Token.

sonarqube-endpoint

A seguir devemos configurar a tarefa Prepare Analysis Configuration nas Definições de Build do VSTS. O nome do projeto, source e o servidor de endpoint do SonarQube são parametrizados nesta etapa.

sonarqube-vsts

E a análise do código pode ser acompanhada no servidor do SonarQube ou configurando o SonarCloud.

sonarqube

 

 

 

Definições de Build – Continuous Integration (DevOps)

Por aqui vamos demonstrar o passo-a-passo das definições de Build, utilizando o VSTS da Microsoft para criar o workflow com as tarefas de Integração Contínua (Continuous Integrationno time de desenvolvimento.

Acesse o VSTS no Projeto que será feita a configuração de Build, utilizando o caminho Build and Release > Builds. O botão + New cria um novo workflow para configurar as definições de Build.

Get sources
O primeiro passo é configurar o versionador de código (TFVS | GitHub | Subversion | etc.) e Workspace Mappings (Map | Cloak) com o caminho de execução dos Builds do projeto.

Build-definition-I

NuGet
O NuGet é um package management compatível com plataforma Microsoft e contém o código compilado (DLLs),  trabalhando com bibliotecas e ferramentas do Visual Studio. Os pacotes podem ser publicados em host público ou privado. Nesta fase, somente indicar o local (path) da Solution do projeto, conforme abaixo:

Build-definition-II

Visual Studio Build
A configuração do Build é simples, basta indicar o path da Solution do projeto.

Build-definition-III

Visual Studio Test
Esta tarefa é sensacional para o CI. O Visual Studio Test permite executar testes unitários, code coverage, entre outros. Neste link há mais detalhes sobre esta task.

Neste exemplo, selecionamos o Test Assemblies, relacionando as DLLs e o caminho do projeto de teste da solução. Também habilitamos o Code Coverage Enabled para analisar a proporção de código que está sendo coberto por testes, como testes unitários.

Build-definition-IV

Index Sources & Publish Symbols
O Symbol Servers habilita os debuggers para retornar automaticamente o correto symbol files sem conhecimento do nome do produto, número do build ou nome do pacote. Veja mais em Publish Symbols for debugging.

Build-definition-V

Code Analysis
O VSTS analisa o código gerenciado de duas maneiras:

  • Static Analysis of Managed Assemblies – FxCop: fornece informações para corrigir problemas com violações de programação e regras de design.
  • . Net Compiler Platform Analyzers – Roslyn: analisa qualidade, estilo, facilidade de manutenção, design e outros problemas de código. Muitas regras da análise de código estático já foram reescritas na análise Roslyn e podem substituir a análise estática para código gerenciado.

Em nosso exemplo, definimos a regra de Minimum Recommended Rules que atua nos problemas mais críticos do código. A descrição de todas as regras podem ser encontradas na documentação da Microsoft.

Build-definition-VI

O check-in do código pode ser configurado com política para prevenir que o desenvolvedor faça check-in sem ter executado a análise do código. O SonarQube também é uma ótima ferramenta de análise do código e pode ser integrada com o VSTS.


Publish Build Artifacts
E na última etapa somente a configuração do local onde será publicado o artefato.

Build-definition-VII

 

Referências
Get Sources – Cloak
Nuget with VSTS
Visual Studio Test
Code Analysis – Microsoft
Publish Symbols for debugging
Publish Build Artifacts – Microsoft

Backlog de Branch e Merge utilizando o VSTS – CI

Nos POSTs de Gerenciamento de código-fonte e Continuous integration, delivery and deployment apresentamos o processo de criação das linhas de Main | Dev | Release no gerenciamento de fontes, essenciais para trabalhar com Continuous Integration.

Continuando a abordagem de Integração Contínua, uma boa prática é gerenciar as atividades de Branch Merge utilizando o board (Agile, Scrum ou CMMI) do VSTS. Assim, teremos o histórico e visibilidade das atividades que o o time de desenvolvimento realiza junto ao Configuration Manager.

Criando um novo projeto ou time no VSTS
Crie um novo projeto no VSTS, no exemplo abaixo utilizamos o nome DevOps, e escolha o template que irá trabalhar (Agile | Scrum | CMMI):

vsts-new-project* criamos um novo projeto, considerando que o Configuration Manager atende a todos os times do projeto na Sprint. Em cenários que o CM tenha apenas um time, o ideal é criar a um novo time no VSTS e assim distribuir as atividades de acordo com a alocação do CM no time de projeto.

Criando a estrutura de backlog
Em seguida, a nível da Requirement * (template CMMI), adicione duas novas: Solicitação de Merge e Solicitação de Branch para cadastrar as tarefas relacionadas.

vsts-pb-devops
* nível Product Backlog Item (em template Scrum) ou User Story (em template Agile)

Solicitando a Branch ou Merge
Com a estrutura criada, os desenvolvedores podem abrir uma nova tarefa (work item), solicitando a criação de Branch ou Merge.

branch-vsts

A solicitação (tarefa) deve conter as informações:

  • Nome do projeto que irá ser alterado (mesmo nome do repositório)
  • Tipo: Melhoria, Correção ou Emergencial
  • Encaminhada ao Configuration Manager
  • No campo “Iteration” deverá estar na Sprint corrente

work-item-branch-vsts

Pronto! Agora conseguimos gerenciar o backlog de Merge e Branch no VSTS, deixando o processo transparente para o time de desenvolvimento.

backlog-devops