Testes exploratórios com Request Feedback no VSTS

May 3, 2018August 4, 20191 Comment

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

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

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

April 19, 2018August 4, 2019

O 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.

A 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 e 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

April 17, 2018August 4, 20191 Comment

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. O 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.

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).

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

April 15, 2018April 15, 20182 Comments

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

Os conceitos de produção empurrada e produçã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 Time) e Kanban, método visual para controle de produção e prever gargalos no processo.

Imagem: 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.

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):

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

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.

Integração SonarQube com VSTS

April 13, 2018August 4, 20191 Comment

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 smells e code coverage.

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

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.

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.

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

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

April 12, 2018August 4, 20192 Comments

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 Integration) no 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

April 7, 2018August 4, 2019

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 e 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

Integração VSTS e Slack – Tecnologias Sociais

April 6, 2018August 4, 20194 Comments

Aos times de desenvolvimento de sistemas que precisam propagar informações e decisões rapidamente, o Slack é uma ótima ferramenta para criar canais de discussões em projetos. Também em Squads específicas para a resolução de um problema ou criação de um novo produto.

Veja o passo-a-passo de como criar sua conta no Slack e integrar com o VSTS:

1. Criar a conta no Slack

Acesse o site do Slack e crie uma nova conta, utilizando “Start with a workspace” > “Create a new workspace”

slack

Após a criação da conta, algumas configurações simples são solicitadas como nome do grupo, quantidade de usuários e propósito da criação. O principal é o nome do seu workplace, que definirá inclusive a URL http://nome-do-seu-workplace.slack.com

2. Adicionando a App Visual Studio Team Services

Na tela inicial (canto esquerdo) há a opção de Apps (destacado em vermelho), que possibilita a instalação de Apps. Digite “Visual Studio Team Services” e clique em Install.

slack

Durante a instalação será solicitado “Post to Channel” que definirá em qual canal as mensagens vindas do VSTS serão postadas. Pode escolher o #general como padrão ou criar algum canal específico para o seu time.

Feito isso, a próxima tela será de Setup Instructions com todas as instruções para configurar o VSTS. O mais importante nesta página é você salvar o seu Webhook URL que será utilizado na configuração com o VSTS.

slack-save-integration

3. Configurando o VSTS

Agora no VSTS, acesse o Service Hooks do seu projeto. Isso permitirá configurar Triggers que serão disparadas assim que algum evento acontecer no VSTS (os eventos são configuráveis) para escrever mensagens no Slack. Clique no botão + para criar um novo serviço:

service-hooks
As três próximas telas serão para: 1) escolher o app do Slack 2) definir qual evento será gravado no Slack. No exemplo, o Work Item updated é um trigger que gravará no Slack a cada modificação ocorrida no Work Item do VSTS do projeto. Também podem ser configurados outros eventos de gravação ou campos específicos; 3) e então digitar o Webhook URL na caixa de texto.

service-hooks-1

E então qualquer modificação em Work Item, configurado anteriormente, refletirá no canal que foi escolhido para o Webhook.

update-slack

VSTS – Build e Release – DevOps

February 8, 2018August 4, 20191 Comment

Objetivo: descrever a importância do Build e Release no processo de DevOps

Contexto: colocar um novo sistema em produção (ou incremento) é uma demanda frequente nas organizações que trabalham com desenvolvimento de sistemas. Não pode haver bottlenecks! Há um constante monitoramento para checar se os usuários estão realmente utilizando as releases e o que podemos fazer para melhorar a experiência do usuário.

Tudo isso exige um processo de Continuous Integration / Delivery / Deployment. As práticas de DevOps, incluindo a configuração de Build e Release, são essenciais para melhorar a qualidade, controle e integração dos sistemas a serem publicados. Evitar versões erradas em produção e a famosa frase do desenvolvedor “na minha máquina funciona” são dilemas que as empresas mitigam com um bom modelo de versionamento e gestão de fila da implementação.

E assim, desde a criação de máquinas de Build até a transição nos servidores de DEV, QA, Homologação, Pré-produção e Produção, compartilho no post abaixo uma orientação de configuração de Build e gestão dos artefatos no ambiente VSTS.

Build e Release

O processo de Build envolve funções de integração, construção, versionamento, qualidade e compilação do código-fonte produzido. As ferramentas VSTS, Maven e GitHub são utilizadas para auxiliar na integração e monitoramento dos artefatos. Quando há quebra no Build devido a problema neste processo, os desenvolvedores precisam corrigir e fazer o check-in novamente. O processo de integração contínua e o apoio da infraestrutura são necessários para manter a esteira de publicação rápida, principalmente para organizações que trabalham em larga escala.

Posteriormente, o Release é a liberação da nova versão do sistema em produção. Considera-se que no Build já tenha sido avaliado e testado a qualidade para garantir que não haja erros. Este processo consome recurso de servidores, que dependendo da complexidade, exige escalabilidade para realizar o deploy do código.

Para automatizar as etapas do processo de Build e Release e envio dos scripts ao repositório, os times geralmente utilizam ferramentas como Jenkins. Outros aspectos a serem considerados:

Criar servidor(es) para execução de Builds
Automatizar etapa de compilação e deploy
Ambientes (Dev | QA | Homologação | Produção)
Processo de qualidade para validação do negócio
Testes automatizados
Padrnoização de regras para arquitetura
Utilização de teste unitário, Sonarqube (qualidade do código) e práticas como BDD ou TDD

Utilizando VSTS

Build
Acesse o VSTS > Build and Release > Builds para configurar as definições de Build:

Todas as opções abaixo estão disponíveis para configuração:

Tasks – Build Name / Agent Queue / Path to solution / Artifact Name
Variables
Triggers – Continuous Integration (Build every change to matching branches: Disabled) | Gated Check-in (Accept check-ins only if the submitted changes merge and build successfully: Enabled) | Scheduled (Build matching branches for each schedule: Disabled)
Options – Build properties (Description / Build number format) / New build request processing: Enable / Automatically link new work in this build… / Create work item on failure / Allow scripts to access OAuth token / Build job / Define build job authorization and timeout settings / Build job authorization scope / Build job timeout in minutes / Build job cancel timeout in minutes / Demands / Specify which capabilities the agent must have to run this process
Retetion – Days to Keep / Minimum keep / When cleaning up builds… / History

Release
Também no VSTS > Build and Release > Release para criar as definições de Release:

E assim será criado o Pipeline para publicação dos binários, com a escolha do Template, nome do ambiente (que será realizado deploy) e owners do ambiente.

Artefatos de Build
Também podemos criar artefatos de Build, selecionando o Build (na Source Type) que será promovido na Pipeline de Release. Escolha também o projeto e a última versão desenvolvida.

Há outras configurações como tarefas, variáveis e opções que estão disponíveis no VSTS. Como o propósito foi introduzir o tema, sugiro acessar o Docs da Microsoft para ter mais detalhes sobre as configurações de Build e Release.

VSTS – Work Item – Criando Spikes e Acceptance Criteria

February 2, 2018August 4, 2019

Pré-requisito
No último post sobre VSTS Process Templates, explico as principais diferenças entre os templates Agile / Scrum / CMMI no VSTS (Visual Studio Team Services). Certifique-se de que compreendeu bem estes conceitos para dar continuidade ao post abaixo.

Contexto
Ao trabalhar com times de desenvolvimento ágil, utilizando o VSTS, podemos criar o backlog associado a projetos e alocação de times, configurando time box para as Sprints deste projeto, conforme a cadência planejada na sua empresa.

Além de versionar o código-fonte e permitir associar check-in do seu time com os Work Items, o VSTS é uma solução para gerenciar outras etapas do ciclo de vida da aplicação. Neste contexto, a criação e customização de Work Items é necessária para trabalhar em Epics > Features > User Stories e entregar valor ao produto.

Veja que na área de PROCESS (PROCESSO), existem os processos e fields (campos), que são utilizados em níveis de Work Item / Backlog / Projetos.

Spike
A primeira customização que iremos demonstrar é a criação de Spikes – tempo consumido para explorar melhor as definições de tópicos que apresentam risco para o projeto – e como alocar as horas para tratar estas indefinições, sem impactar nas estimativas do projeto.

Escolha o process template que está trabalhando, no meu caso utilizei o CMMI. Abaixo, veja que há Levels (níveis) de otimizações para incluir campos. Como as Spikes fazem parte do projeto, recomendo criar no nível de Iteration para ser visualizadas no Board junto com as Tasks (destacado em vermelho na figura abaixo – utilize a opção … Editar).

E na tela seguinte, você pode criar “New Work Item Type”, neste caso a Spike.

Veja que na sequência o Work Item do tipo Spike já aparece no Board do VSTS para criação e acompanhamento.

Acceptance Criteria
Outra opção é criar novos campos, ou utilizar campos existentes de outros templates. Por exemplo, no template do CMMI não existe o campo de critério de aceitação da tarefa, mas consegui incluir por já existir em outros templates. Também pode ser incluído qualquer outro campo novo, independente de existir em outros templates.

Para criar um novo campo, acesse na página inicial do Work Item Types, clicando no tipo TASK, conforme abaixo.

Acesse New Field e abrirá uma nova janela para adicionar um campo existente (de outro template) ou simplesmente criar um novo campo. Neste caso, escolhi a opção de criar um campo existente ao Work Item.

Logo após adicionar o campo, você já poderá visualizar dentro da TASK, conforme abaixo.

Digital Strategy and IT Innovation

TI, Inovação, Agilidade, DevOps, ALM, Governança e Cloud Strategy

Tag: VSTS