Gestão de backlog – Epic Roadmap, WI relationships e personas no Azure DevOps

Já discutimos sobre o uso do Azure DevOps como plataforma de ciclo de vida do desenvolvimento e a estruturação do backlog na ferramenta (Epic – Feature – User Story – Tasks) de acordo com o seu process template.

Na área de Boards do Azure DevOps, temos alguns novos recursos no Marketplace para apoiar a visualização e gestão das atividades dos times. Selecionei três deles que são bem interessantes:

Crie então a estrutura do seu Time de Projeto no Azure DevOps (Boards > Backlogs). Veja na imagem abaixo que a relação entre Epic – Feature (Requirement) – User Story é de Parent. 

azure-devops-backlog

Feature timeline and Epic Roadmap

Após a estruturação do backlog, ainda em Boards > Backlogs, veja que as guias de “Feature Timeline” e “Epic Roadmap” foram criadas (após a instalação da extensão do Marketplace). A visão é das User Stories em relação a Sprints que serão desenvolvidas. Este roadmap ajuda o time a visualizar a entrega das funcionalidades do projeto.

epic-roadmap

Visualize work item relationships

Após a instalação da extensão no Marketpace, acesse as opções do Work Item (conforme imagem abaixo) e utilize Visualize. Em seguida, veja que será exibido a estruturação do seu backlog, bem semelhante ao FBS (Feature Breakdown Structure), muito utilizado para ajudar o time a melhorar a compreensão do produto e requisitos.

wi-visualization

work-item-visualization

Personas

Por fim, a criação de Personas ajuda a representar o usuário no sistema, descrevendo seu papel e necessidades. Instale a extensão do Marketplace (conforme link no início do artigo) e acesse o novo recurso “Personas” que será exibido, conforme abaixo.

Clique em + Add para adicionar uma nova Persona. Preencha o Nome, Tag, Descrição e Foto conforme necessidade do projeto.

create-persona-azure-devops

Após ter criado a Persona, você consegue utilizar e vincular em qualquer Work Item. No exemplo abaixo, estamos associando quais Personas são afetadas pela aquela atividade.

wi-personas

TDC SP 2019 – DevOps em grandes organizações regidas por compliance

Olá,

Segue um resumo da minha palestra na Trilha DevOps (18/07) no TDC (The Developer’s Conference) em São Paulo. O tema abordado foi Habilitando o Continuous Deployment em empresas regidas por compliance. O material apresentado está disponível neste TDC2019PDF.

tdc-2019-leo.png

  • Introdução
  • Livro Jornada DevOps
  • O problema a ser resolvido
    • Estratégicos e operacionais
    • As recomendações são mesmo aplicáveis ao seu ambiente?
    • Existe silo entre Dev e Ops?
    • Verifique seus dados – Machine Learning, Service Desk, opinião de especialistas, etc.
    • Throughput e Stability
    • Alavancagem estratégica (MVPs, Build-Measure-Learn-Loop, Time to market, testes A/B)
    • Assessment (process | technology | culture | measurement | outcomes)
    • Case real com problema no processo de Change Management
  • SOX e desafios em organizações regidas por compliance
  • Os pilares da mudança: processos, pessoas e ferramentas
  • Gestão Ágil e DevOps
  • ALM (Ciclo de vida da aplicação) com Microsoft Azure DevOps
    • Boards: estruturação de times e template do processo; cadência do projeto e definição de backlog
    • Repos: estratégia de fontes e gestão da configuração
    • Pipeline: definições de build e release
    • Gerenciamento de configuração e orquestração
    • Testes: plano de testes, Agile Testing Quadrants, modelo tradicional x ágil
    • Change Management: Azure DevOps x Service Now; processo de change management com práticas DevOps
    • Ferramentas: as ferramentas utilizadas no ciclo de desenvolvimento
    • Monitoramento: da sprint, aplicação, serviços, componentes e processo CI/CD
  • Leituras recomendadas

inscricao-jornada-devops

Azure DevOps add-in para Excel

O Azure DevOps nativamente oferece recursos para gerenciar work items – tais como criar um novo (bug, feature, epic, etc.), atribuir, status, entre outros. O board permite a visualização destes itens em Sprints e por time de projeto. A área de Queries permite a extração da informação e a área Dashboards para criar gráficos de acompanhamento.

Mesmo com todos estes recursos, sabemos que o Excel é a ferramenta utilizada por muitas pessoas para ajudar na análise e consolidação das informações. E o Azure DevOps possui integração com o Excel. Se você não tiver Visual Studio instalado na sua máquina, o primeiro passo é ir ao Visual Studio downloads page e baixar a Integração do Office para Team Foundation Server 2017 em “Outras Ferramentas e Estruturas”.

integracao-office-tfs

Nas opções do Excel > Suplementos, marque o “Team Foundation Add-in” em Suplementos de COM. Isso irá criar a aba “Equipe” no Excel que é onde iremos trabalhar na integração com o Azure DevOps.

excel-com

Na aba “Equipe’, crie uma nova lista, adicionando a URL da sua instância no TFS ou Azure DevOps.

excel-tfs

Escolha o projeto de equipe e conectar. Em seguida, na lista de consultas, utilize a query desejada para extrair os dados.

tfs-excel-query

Pronto! Os work items serão relacionados. Utilize as seguintes opções:

  • Escolher colunas: para adicionar ou remover colunas no relatório.
  • Links e anexos: permite vincular um work item a outro, ou incluir anexo.
  • Editar áreas e iterações: direciona para o Azure Devops.
  • Configurar (lista | servidor): definição do servidor que está publicado a sua organização.
  • Publicar: em caso de alteração, você consegue carregar de volta no Azure DevOps, utilizando esta opção.

work-item-excel

Estratégia de backup e recovery no Azure DevOps

Em posts anteriores, apresentamos o Azure DevOps e seus principais serviços: Azure Pipelines, Boards, Artifacts, Repos e Test Plans. Vimos também os principais benefícios da solução e como gerenciar o ciclo de vida do desenvolvimento. Ao começar o uso intensivo em sua organização, criando times e projetos, seguramente uma pergunta que virá: como funciona o backup e restore das informações?

Bom, oficialmente a Microsoft não possui um serviço (como Backup do Azure ou Armazenamento de Blobs) no Portal Azure para fazer o backup da estrutura e dados do Azure DevOps em nível de organização ou projeto.

portal-azure

* para saber como funciona no Azure DevOps Server 2019 e TFS (2018 à 2013), acesse este link de Backup and Restore.

O que pode ser feito então se alguma estrutura de projeto, arquivo de repositório ou tarefas do board forem apagadas indevidamente? Claro, que a primeira recomendação é segregar muito bem os acessos no time para evitar modificações inapropriadas. Com os acessos bem controlados, algumas recomendações que ajudam a gerenciar estes problemas são:

Board
A primeira dica é com um processo bem manual. Para salvar os work items da área board, utilize o recurso de Query e ajuste a consulta (colunas e filtros) para retornar os itens que você precisa. Em seguida, utilize “open in excel” e mantenha uma rotina de atualização. Assim, quando precisar, bastar utilizar o serviço de conexão (Excel – Azure DevOps) e carregar os work items novamente.

azure-devops-query

* as configurações relacionadas aos projetos e times de projetos são carregadas nesta query, mas caso a estrutura (teams, iterations, templates, etc.) seja perdida no Azure DevOps, ela precisará ser recriada manualmente.

 

Repos
Ao deletar um projeto, você não pode recuperá-lo. Por isso, mantenha sempre um backup do projeto. Há um procedimento para salvar o código fonte e os dados do build (View build results). Acesse a área de repositório e clique com o botão direito no nível desejado (pode ser um arquivo específico ou pasta inteira) para o download dos arquivos.

download-files-azure

* se você utiliza Git, clone seus repositórios para manter o histórico do projeto e todas as branches.

 

Pipelines
A estrutura de Build pode ser guardada com o comando Export. Acesse a área de Pipelines > Builds e com o botão direito Export. Este comando gera um JSON que pode ser utilizado para importar a estrutura de volta.

export-build

Veja que ao importar o arquivo JSON (em Pipelines > Import a pipeline), temos a estrutura criada a partir do Build que exportamos as configurações.

pipeline-build-import.png

As Releases podem ser feitas da mesma forma, exportando a estrutura em arquivo JSON e importando novamente quando necessário. Também recomendo a leitura deste artigo para implementar uma estratégia de rollback com release management.

Azure DevOps Server 2019

A Microsoft lançou inicialmente o Azure DevOps (antigo VSTS – Visual Studio Team Services) como solução completa de serviços de desenvolvimento na nuvem. Agora em 2019, está disponível o Azure DevOps Server 2019 (antigo TFS – Team Foundation Server), um conjunto de ferramentas colaborativas de desenvolvimento de software, hospedadas localmente.

Você pode instalar o Azure DevOps Server em seu próprio ambiente, integrando com seu IDE ou editor existente. As atualizações podem ser configuradas para acontecer conforme desejado. Os serviços do Azure Pipelines, Azure Boards, Azure Artifacts, Azure Repos e Azure Test Plans podem ser utilizados da mesma forma e independentes.

Clique para fazer o Download do Azure DevOps Server 2019. Os requisitos para instalação podem ser encontrados neste artigo da Microsoft.

azure-devops-server

A release notes descreve as principais mudanças em relação ao TFS 2018. Entre as principais estão:

azure-devops-server.png

Integração ServiceNow Change Management com Azure Pipelines – Parte II

Na parte I deste tópico, vimos como realizar a instalação das seguintes extensões:

  • ServiceNow Change Management (no Azure DevOps)
  • Criar uma nova instância no ServiceNow (no ServiceNow Developers)
  • Azure Pipelines (no ServiceNow)

A parte II será direcionada a configuração da integração entre o Azure DevOps e ServiceNow, desde a abertura de uma mudança no ServiceNow (a partir do pipeline no Azure DevOps) e também da atualização do status da mudança, por exemplo, colocar como concluída no ServiceNow, caso a release tenha sido publicada no Azure DevOps.

Azure DevOps
Após a instalação do ServiceNow Change Management (demonstrado na parte I), crie um novo Service Connection no Azure DevOps (Project Settings > Pipelines > Service connections). Defina as seguintes configurações:

  • Connection name: insira o nome desejado para a conexão com o ServiceNow
  • ServiceNow Url: é a URL da instância que será utilizada (também criada na parte I)
  • Username: usuário criado (ou configurado) na parte I com a permissão já definida
  • Password: a senha definida na configuração do usuário (no ServiceNow)

service-connection-vsts

Na Release Pipeline, adicione um pre-deployment gate, incluindo a conexão que acabamos de criar. É o campo ServiceNow connection. A documentação da Microsoft possui uma descrição para o preenchimento de todos os campos. Estas configurações permitem a abertura de uma mudança no ServiceNow. Entre os principais inputs:

  • Category:  a categoria da mudança (HardwareNetworkSoftware)
  • Priority: a prioridade da mudança
  • Risk: o risco da mudança
  • Impact: o impacto da mudança no negócio
  • Configuration Item: o item de configuração da mudança

gates-azure-devops

O Gates produz variáveis de output, como por exemplo:

  • CHANGE_REQUEST_NUMBER: número da mudança criada no ServiceNow
  • CHANGE_SYSTEM_ID: ID da mudança criada no ServiceNow

Esta variável de output pode ser acessada utilizando o prefixo PREDEPLOYGATE. Por exemplo, a variável gate-servicenow (definida no campo reference name) pode ser utilizada com a sintaxe $(PREDEPLOYGATE.gate-servicenow.CHANGE_REQUEST_NUMBER).

new-release-pipeline

Ao executar o deploy da release, uma nova mudança será criada no ServiceNow. Como o Success Criteria (tela anterior) está definido em “Implement”, a mudança será liberada quando for alterada para este status no ServiceNow.

ServiceNow
Então, por exemplo, quando o gestor da mudança acessar a ferramenta do ServiceNow, haverá uma nova mudança em sua fila. Ao colocar a mudança em “Implement”, a condição pre-deployment configurada no Gates será disparada, liberando a release.

service-management

Azure DevOps
Em seguida, adicione um novo Agentless job com a extensão Update ServiceNow Change Request ao final do seu release pipeline. Novamente, utilize a conexão criada anteriormente em ServiceNow connection e o status que deseja colocar a mudança após a implementação da release. No meu exemplo, coloquei o status como “Closed”.

agentless-job-azure-devops

Após a execução , o status do Deployment Gates fica disponível e se bem sucedida, a mudança será fechada automaticamente no ServiceNow.

pre-deployment-gates

Integração ServiceNow Change Management com Azure Pipelines – Parte I

Já abordamos em posts anteriores os temas – Habilitando o Continuous Deployment em empresas regidas por SOX e Change Management e DevSOXOps com Azure DevOps para discutir como as empresas regidas por compliance realizam frequentemente deploys de releases, em meio ao processo de change management.

Se por um lado, o Azure DevOps possui o Pipeline de Build e Release para criar as esteiras de implementação e gerenciar o ciclo de vida da aplicação, o ServiceNow é uma solução completa de IT Service Management, possuindo entre outros, o Incident Management, Problem Management, Change and Release Management, Request Management, etc.

Resultado de imagem para the visible ops

O livro The Visible OPS publica a implementação do ITIL em quatro passos práticos e auditáveis: 1) Core do ITIL 2) Processo de controle bem definido, mas que pode ser leve e ágil 3) O objetivo do processo e intersecções com DevOps 4) Buscar caminhos alternativos para atingir o objetivo esperado.

A Microsoft lançou a integração do Azure DevOps com o ServiceNow, incluindo a extensão do ServiceNow no pipeline de release. A ideia é reduzir os riscos associados ao processo de gestão da mudança, incorporando os benefícios de práticas DevOps como redução do tempo de deploy, intervenções manuais etc com os controles de gestão de serviços.

E assim, podemos por exemplo, criar uma nova requisição ou atualizar o status de uma change, utilizando o recurso de Gates do Azure DevOps. Vamos começar pelas instalações! Os primeiros passos são:

1. Instalação da extensão do ServiceNow no Azure DevOps

service-now-change-mgt-extension

2. Solicitar uma nova instância no ServiceNow Developers no ServiceNow. Esta instância deve ser non-developer.

service-now-developers

3. Instalação do App Azure Pipelines no ServiceNow. Necessita de HI credentials (algum administrador da conta no ServiceNow pode conceder esta permissão) ou ser Technology Partner Program.

service-now-store

E atribuir a permissão de x_mioms_azpipeline.pipelinesExecution ao usuário que será utilizado no Service Connection do Azure DevOps (para criar a conexão com o ServiceNow).

user-role-sn

E a Parte I encerra aqui… no próximo post vamos compartilhar as configurações necessárias no Azure DevOps e ServiceNow para concluir a integração.