Month: April 2018

Dashboards de Projetos Ágeis no VSTS utilizando Widgets

3 Comments

Debatemos em fóruns anteriores a importância das métricas no gerenciamento de projetos ágeis e no ciclo de vida da aplicação.

Além de identificar problemas no processo de desenvolvimento de sistemas, garante a transparência das Sprints, o backlog em execução e os bloqueios que devem ser removidos da equipe.

Mensurar é ponto essencial no processo de Integração Contínua. Não há um bom deployment pipeline sem avaliar a qualidade do código, cobertura dos testes, build, release, entre outros.

E como começar utilizando o VSTS?

1. Acesse o seu projeto no VSTS. Na guia Dashboards, clique no símbolo da engrenagem e manage dashboards (no canto direito) para criar um novo painel. Ou clique em Edit para adicionar os Widgets ao modelo padrão de Dashboard.

dashboard-vsts-criacao

2. Em seguida, escolha a opção de Add Widget para incluir os paineis no Dashboard.

widget-vsts

3. Defina as métricas mais importantes para o seu time. Algumas sugestões de widget para compor o Dashboard Agile:

  • Burndown: gráfico que pode ser mantido para visualizar o trabalho restante
  • Countdown Sprint: exibe os dias restantes para acabar a Sprint
  • Query Title Pro: permite buscar queries criadas no work do VSTS e trabalhar com médias e sumarizações. Assim, podemos calcular a velocidade do time, em story points ou em horas (dependendo do template adotado). Veja mais neste post.
  • Chart for Build History: gráfico de acompanhamento dos builds da aplicação
  • Query Title: indicadores como de Bloqueios e Riscos podem ser visualizados utilizando este widget, associando com as queries do VSTS. Mais detalhes.
  • Chart for work items: cria gráficos com base nas queries do VSTS. Mais detalhes.
  • Cumulative flow diagram: visualiza o fluxo de trabalho e se há gargalo no processo – veja mais.

dashboard-vsts

 

 

Utilizando 5 Porquês (5-Why) na análise da causa raiz de sistemas TI

2 Comments

Foco na causa e não nos sintomas…

  • E como está a gestão dos problemas no seu time?
  • Quando novos bugs ou retrabalhos são gerados, há um método para avaliar a causa e consequência, como espinha de peixe de Ishikawa?
  • O plano de ação tem dedicado esforços para resolver os problemas mais críticos? Como a matriz GUT (Gravidade, Urgência e Tendência)
  • O follow-up garante a transparência no processo? De fato as causas dos problemas estão sendo atacadas?
  • Já trabalha com Pareto na análise de distribuição das ocorrências? 20% dos problemas são responsáveis por 80% das ocorrências?

Hoje vamos falar sobre o 5 porquês (5-Why) e como utilizar para determinar a causa raiz do problema. Trata-se de uma uma técnica criada por Taiichi Ono, um dos responsáveis pela criação do sistema Toyota de produção, funcionando muito bem para problemas simples.

Embora tenha surgido como ferramenta de gestão da qualidade total e melhoria contínua na indústria, também é muito aplicável no contexto de serviços, como de desenvolvimento de sistemas na área de TI. Reunindo a equipe, deixe a comunicação aberta para participação de todos os envolvidos no processo.

Problema: cadastro de novos produtos não está funcionando
(aberto um bug no VSTS de problema no módulo de produtos)

bug-vsts

Ao analisar a causa raiz do problema, percebemos que o erro encontrado no sistema era referente a um procedimento que deveria ser realizado, e que um treinamento ou informativo poderiam ter ajudado a evitar o problema.

5-porques

Concluindo o post, vale lembrar que o 5 porquês possui limitações e deve ser utilizada com outra ferramenta, por exemplo espinha de peixe – Ishikawa, para análise detalhada de problemas de maior complexidade.

Mais detalhes: https://leonardo-matsumota.com/2018/12/13/analise-de-causa-e-efeito-em-projetos-ageis-com-fishbone-ishikawa-e-azure-devops/

fishbone

Analytic Hierarchy Process (AHP) – método de apoio a decisões complexas

Analytic Hierarchy Process (AHP)
É um método de apoio a tomada de decisões complexas, baseado em procedimento abrangente e racional na estruturação do problema. Foi desenvolvido por Thomas L. Saaty em 1972, na Escola Wharton de Administração de Empresas da Universidade da Pensilvânia.

A essência AHP considera os julgamentos humanos e as informações numéricas, pois converte os julgamentos em valores numéricos. Isso permite o processamento e comparação de toda a extensão do problema.

Geralmente, utilizamos modelos de software como Expert Choice, Decision Lens, Make It Rational e Web-HIPRE para trabalhar com os dados e síntese dos resultados. Ou também o software desenvolvido pela Universidade Federal de Alfenas.

AHP

E como funciona?

  • Hierarquia: decompor o problema em subproblemas. Facilita a compreensão e permite análises independentes.
  • Elementos da hierarquia: tangível ou intangível, relaciona-se com os aspectos do problema de decisão.
  • Avaliação: avaliar as decisões sistematicamente, considerando seus elementos e comparando-os um ao outro. Os dados podem ser concretos ou com base no julgamento sobre a importância dos elementos. Um peso ou prioridade é derivado para cada elemento da hierarquia.

AHP-subcriterios.png


Aplicabilidade
Embora possa ser utilizado por indivíduos lidando com decisões simples, o AHP é mais útil quando equipes estão envolvidas em

  • Problemas complexos que necessitam de percepção humana
  • Resolução terá repercussão de longo-prazo
  • Dificuldade de quantificar ou comparar elementos da decisão
  • Problema de comunicação entre os elementos – especialidades, terminologias e perspectivas diferentes


Utilizando AHP

  • Objetivo: Comprar um carro
  • Critérios: Estilo, Confiabilidade e Consumo
  • Alternativas: Focus, Corolla, Civic, Fluence

AHP-criterios

Os dados são sintetizados de modo a determinar rankings relativos de cada alternativa. Podem ser usados métodos quantitativos e qualitativos para comparar os critérios e definir os pesos e prioridades. E baseado no julgamento humano, determinamos os critérios mais importantes:

  1. A confiabilidade é 2 x mais importante que o estilo
  2. O estilo é 3 x mais importante que o confiabilidade
  3. Confiabilidade é 4 x mais importante que o consumo

A Pairwise Comparation (comparação paritária) relaciona os pesos atribuídos aos critérios, expressando a importância de um critério relativo em relação ao outro:

pairwise

Passo 1
Converter a matriz de frações em decimais
pairwise-II

Passo 2 – Multiplicar as matrizes
Passo 3 – Somar as linhas e depois colunas. Depois normalizar, dividindo o valor de cada linha pelo o total da coluna
Passo 4 – Recomeça-se o processo. Compara-se o resultado anterior com o novo encontrado, até que uma nova interação não demonstra muita diferença

Claro, que este cálculo deve ser feito utilizando um software recomendado. O resultado então ficou:AHP-resultado

Pode-se calcular alternativas também, realizando para cada critério o mesmo processo. A medida de inconsistência entre a pairwise comparision da matriz pode ser expressa por: C.I. = λmáx – n
               n – 1

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

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

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

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

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

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

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

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)

2 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

Jornada DevOps

4 Comments

DevOps
Tudo começou em uma Palestra no Velocity 2009 – San Jose – CA – sobre 10+ Deploys per day. John Allspaw & Paul Hammond apresentaram os dilemas do modelo tradicional de desenvolvimento: “Dev’s job is to add new features; Ops’ job it to keep the site stable and fast” e como habilitar o modelo operacional para atender as mudanças nos negócios.

As falhas de aplicação, erros operacionais e downtime estão entre os principais motivadores para a evolução do processo entre desenvolvimento e operações. Algumas práticas como infraestrutura automatizada, controle de versionamento, métricas, respeito e confiança foram recomendadas para aproximar as áreas de Business, Dev e Ops.

devops-velocity.png

Já nos dias atuais, o conceito de DevOps evoluiu, assim como as ferramentas que utilizamos. Não há uma entidade ou comitê responsável pelo tema, por isso compartilho as duas definições que entendo como as mais interessantes:

By Microsoft: “DevOps é a união de pessoas, processo e produtos para habilitar a entrega contínua do valor para nossos usuários finais. A contração de “Dev” e “Ops” faz referência à substituição da estrutura fechada de Desenvolvimento e Operações para criar equipes multidisciplinares que agora trabalham juntas com práticas e ferramentas compartilhadas e eficientes. As práticas essenciais de DevOps incluem planejamento ágil, integração contínua, entrega contínua e monitoramento de aplicativos”.devops-microsoft.png

By Amazon: “O DevOps é a combinação de filosofias culturais, práticas e ferramentas que aumentam a capacidade de uma empresa de distribuir aplicativos e serviços em alta velocidade: otimizando e aperfeiçoando produtos em um ritmo mais rápido do que o das empresas que usam processos tradicionais de desenvolvimento de software e gerenciamento de infraestrutura. Essa velocidade permite que as empresas atendam melhor aos seus clientes e compitam de modo mais eficaz no mercado”.

DevOps-AWS

E para iniciar a Jornada DevOps na sua organização, será necessário conhecer e evoluir algumas áreas de conhecimento do ciclo de vida da aplicação, transformando o mindset da equipe na adoção de:

  • Práticas: Integração Contínua (CI), Entrega Contínua (CD) e Implantação Contínua (CD) para colocar releases em produção continuamente. A esteira rápida propicia a aprendizagem validada e correções de bugs rapidamente
  • Controle de versão: GIT ou TFVC são ferramentas no processo de gestão de fontes que garantem a rastreabilidade e versão correta de implementações e correções
  • Gestão de projetos ágeis: o SCRUM, por exemplo, possui template no VSTS e permite criar o backlog da sprint na ferramenta. O método ágil também habilita o time de desenvolvimento a ter rápida adaptação a mudanças
  • Monitoramento: acompanhar as releases em produção e funcionamento do sistema mediante períodos sazonais ou larga escala. Lembre-se que o ciclo de vida da aplicação não termina ao colocar o sistema em produção

devops-cycle

  • Cloud: ótimo enabler ao Load Balance e Auto Scaling. As aplicações precisam crescer sob demanda. O modelo de validação de negócio do Lean Startup propõe a contínua validação do mercado para justificar um aumento de infra
  • Infraestrutura como código: gestão de ambientes com agilidade para atender o negócio e o time de desenvolvimento
  • Container: evoluindo das máquinas virtuais, tornando a gestão de SO mais leve e fácil
  • Arquitetura: escalabilidade e eficiência para não manter os sistemas acoplados


Benefícios

  • Velocidade: entrega contínua de novas funcionalidades (time-to-market) e resolução rápida de problemas
  • Confiabilidade: baixa taxa de falhas; monitoramento e log das implementações
  • Escalabilidade: a automação de processos (deploys etc.) e a infra as code possibilitam escalar as aplicações conforme demanda
  • Melhoria na qualidade do código-fonte: não permite subir código ruim para produção
  • Redução de Lead time
  • Mais tempo para inovação (ao invés de corrigir e manutenção)
  • Ambientes operacionais estáveis
  • Integração entre as áreas de desenvolvimento e infraestrutura

Desafios e questionamentos
… mudança cultural e de mentalidade (equipes tradicionalmente separadas em silos)
… simplificação e automação de processos
… já existe o papel do Configuration Manager na equipe?
… sua equipe de infraestrutura tem maturidade com scripts e códigos?
… trabalhamos com métodos ágeis e ferramentas de apoio?
… e as questões de compliance?
… a segurança da informação será melhorada?
… quais as métricas de desempenho?
… preferencialmente realizar um projeto piloto

Referências

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