Trabalhando com Git Tags no Azure DevOps

Azure Repos Azure Repos
Neste post vamos navegar no Azure Repos (do Azure DevOps) e compartilhar a aplicabilidade de Tags no histórico do seu repositório de código-fonte. Existem dois tipos de Tags:

  • Lightweight Tags: ponteiro para commits específicos.
  • Annotated Tags: possui informações adicionais como data, mensagem e tagger (marcador).

Entre os principais comandos de uso das Git Tags nas tarefas do Azure DevOps estão:  create tag / view tag / delete tag.

Criando Tags
Após a realização do commit de seu código, acesse a área Repos > Commits do Azure Devops. Procure o commit que você deseja criar a marcação e escolha Create tag. Defina o nome e descrição para a Tag.

This slideshow requires JavaScript.

* nesta área você pode criar somente annotated tags. Para lightweight tags, você deve enviar via push, utilizando linha de comando para aparecer no Azure DevOps.


Apagando Tags
Se você identificou o commit errado, ou por qualquer outro motivo, o recurso Delete Tag permite apagar a Tag do seu repositório. Para isso, você precisa da permissão de Force Push no nível do repositório.

Acesse Repos > Tags no Azure DevOps e escolha a tag que será apagada. Escolha a opção  Delete Tag.

delete-tag


Visualizando Tags
Em Repos > Tags você pode visualizar todas as Tags criadas. Utilize o filtro de busca para encontrar pelo nome. Em repositórios com um grande número de Tags, este recurso pode ser bem útil.

tag-repos

Criando branch a partir da Tag
Outro recurso interessante é a criação de uma nova branch a partir de uma Tag. Para isso, acesse Repos > Tags, clique em + New branch. Especifique o nome e work items a serem vinculados.

new-branch-tags

Veja que a branch foi criada no seu repositório, conforme as configurações realizadas.

branch-tags

 

Ágil em larga escala – Executando a PO Sync

Continuando os posts sobre Ágil em larga escala, vamos falar agora sobre a PO Sync, outra reunião super importante do Program Increment (PI). A Product Owner Sync é uma reunião similar a SoS com o propósito de prover visibilidade do ART (Agile Release Train) em relação aos objetivos do PI.

Fonte: https://www.scaledagileframework.com/program-increment/

É uma ótima oportunidade de avaliar ajustes de escopo e elencar problemas no desenvolvimento de features. Também é usada para preparar o conteúdo da próxima PI Planning e priorizar o backlog com WSJF (Weighted Shortest Job First).

Veja algumas boas práticas na execução da PO Sync:

Frequência: semanalmente ou com maior frequência (se necessário).
Duração: 30-60 minutos seguida da “meet after” em eventuais resoluções de problemas.
Participantes: POs (Product Owners) e PMs (Product Managers).
Facilitador da reunião: RTE (Release Train Engineer) ou PM (Product Manager)

PO-Sync

Em equipes que estão começando a trabalhar com algum framework de Ágil em larga escala, ainda vale a pena checar com cada PO:

  • Está claro o papel do PO no projeto?
  • Os eventos (daily – planning – review – retro) estão acontecendo com o time?
  • Quais atividades o time está trabalhando nesta Sprint?
  • Como está a preparação do conteúdo para as próximas iterações?
  • Existe algum ajuste de escopo?
  • Algum problema ou oportunidade endereçado pelo time?

Microsoft Teams – adicionando Dashboards ou Kanban board do Azure DevOps

Falamos anteriormente sobre tecnologias sociais e como utilizar a Wiki (do próprio Azure DevOps) ou a integração com o Slack para melhorar a comunicação no seu time. O acompanhamento dos projetos exige esta interação imediata entre as equipes, principalmente naquelas distribuídas com fusos e idiomas diferentes.

Além de manter o alinhamento com todos, tais como decisões técnicas e discussões, outra grande virtude é a distribuição rápida das informações e acesso imediato, por exemplo do gestor que precisa demonstrar o Kanban Board do projeto ou do Tester que precisa interagir com o desenvolvedor após a realização do Build.

Neste post vamos demonstrar a integração do Microsoft Teams com o Azure DevOps. Trata-se de um ótimo recurso para acessar os Dashboards ou Kanban Board (dos seus projetos no Azure DevOps) dentro do próprio Teams.

Acesse então o Microsoft Teams e adicione uma nova guia (+) em sua equipe.

teams-vsts-01

Escolha o aplicativo do VSTS e clique no botão Instalar. Faça a autenticação na sua conta do Azure DevOps (antigo VSTS) e conecte nela.

teams-vsts-02

Em seguida, faça a conexão com o Dashboard ou Kanban board do seu projeto e time.

teams-vsts-03

Pronto! O Kanban board * já está disponível dentro do Microsoft Teams. Agora você pode utilizar rapidamente quando precisar de alguma informação do Board do Azure DevOps daquele projeto.

teams-vsts-04

* no meu exemplo escolhi a opção Kanban board, mas há a opção Dashboard também.

 

 

Explorando o Analytics (Service e Views) no DevOps Azure

Abordamos o Azure DevOps em um dos últimos posts, e os principais recursos Boards (planejamento das atividades), Repos (gestão de fontes), Pipelines (CI/CD), Test Plans (suítes de teste) e Artifacts (artefatos organizados e pacotes protegidos).

E como está a análise dos dados? É possível gerenciar a sua equipe com indicadores? E as métricas de qualidade? Vejo como ponto fundamental coletar as informações de todo o ciclo de vida da aplicação e garantir a gestão dos principais processos – tarefas, sprints, builds/releases, bugs, qualidade do código, cobertura dos testes, etc.

Analytics é a solução do Azure DevOps para criar dashboards, relatórios, widgets e integração com Power BI para extrações mais detalhadas. Também possui acesso OData para extensibilidade. Há dois conceitos importantes sobre o Analytics:

  • Analytics Service: serviço que provém o modelo de dados para o Azure DevOps. É otimizado para acesso rápido de leitura e agregações no lado servidor. O Analytics extension é uma extensão utilizada neste contexto.
  • Analytics View: provém acesso imediato as informações, simplificando o uso de critérios e relatórios no Power BI. Algumas views já são automaticamente criadas após a instalação do Analytics extension.

Veja algumas views disponíveis no Analytics Views para serem utilizadas no Power BI. Você pode utilizar as views padrões ou criar utilizando o Power BI Data Connector ou no próprio Azure DevOps.

azure-devops-analytics

A área de Dashboards do Azure DevOps permite visualizar as principais métricas do ALM (Application Lifecycle Management) com o uso dos dados que explicamos anteriormente. Sugiro a leitura de 2 posts – Dashboard de projetos ágeis | Dashboard de projetos ágeis em larga escala para confirmar a aplicabilidade e uso em seu ambiente.

dashboard-vsts-agil-escala

O Power BI é a ferramenta mais completa para análise de informações. Se tiver necessidade de extrações mais avançada, veja como utilizar a conexão entre o Azure DevOps e Power BI:

E assim, criar os indicadores de acompanhamento do seu projeto. O destaque é com as múltiplas visões que podemos construir, por exemplo, a distribuição de tarefas em vários times, ou comparação de Sprints do projeto.

Expectativas e desafios – Programa de Trainee Laureate (Facebook)

Neste vídeo comento um pouco sobre as expectativas das áreas, principalmente de TI, em relação ao programa de Trainee da Laureate e como preparar os profissionais em desafios e projetos da empresa.

Como já fui Trainee em 2007 (em outra empresa), reconheço o valor do programa e o interesse das empresas em desenvolver e desafiar estes profissionais. Os processos de contratação são extremamente concorridos, etapa por etapa, exigindo habilidades intrapessoal/interpessoal, e também valiosos pelo fit de ótimos profissionais para as posições de liderança da empresa. É um investimento muito relevante.

E o que Trainee espera da empresa? Um bom resumo das expectativas seria em torno do desenvolvimento pessoal e profissional, com a participação em cursos e atividades relevantes na organização. Por exemplo, a participação em projetos internacionais, vivenciando as principais fases de planejamento e execução até o Go-Live do projeto coloca o profissional diante de situações reais de pressão, conflitos, priorização e resiliência.

Outra eventual oportunidade é participar de board meetings, apresentações executivas e do contato mais próximo dos gestores. Acredito que tudo isso colabora com a alavancagem profissional e absorção da experiência de profissionais mais seniores. Como os projetos envolvem diferentes áreas (TI, Finanças, Vendas, etc.), tem se também o conhecimento de processo, negócio e governança obtido com eles.

Gostou do cenário proposto? Veja no vídeo então o que esperamos dos Trainees:


https://pt-br.facebook.com/traineelaureate/

 

 

 

 

Ágil em larga escala – Scrum Of Scrums (SoS) meeting

Neste post vamos falar sobre a reunião Scrum of Scrums (SoS), evento que acontece em projetos ágeis em larga escala, e colabora com a comunicação, gestão de dependências entre ARTs (Agile Release Train), visibilidade do progresso em relação aos milestones, objetivos da PI  e impedimentos dos times.

sos-time

Algumas perguntas quanto ao formato? Veja algumas boas práticas:

Frequência: semanalmente ou com maior frequência (se necessário).
Duração: 30 minutos seguida da “meet after” em eventuais resoluções de problemas.
Participantes: RTE (Release Train Engineer), SMs (Scrum Masters) e outros (quando necessário).
Facilitador da reunião: RTE (Release Train Engineer)

Enquanto os eventos do Scrum continuam ocorrendo (planning, daily, review e retro) e os times executando o backlog das Sprints, a SoS reúne o SM (Scrum Master) de cada time com o RTE (Release Train Engineer), famoso líder servo e coach do ART, que facilita este evento e os processos, apoiando os times na entrega de valor.

Agenda recomendada pelo SAFe (Scaled Agile Framework):

SoS AgendaFonte: https://www.scaledagileframework.com/program-increment/

Executando a SoS
Jeff Sutherland tem a seguinte definição da SoS: “The Scrum of Scrums as I have used it is responsible for delivering the working software of all teams to the Definition of Done at the end of the Sprint, or for releases during the sprint.

As primeiras recomendações foram mencionadas acima (time box, frequência, agenda, participantes, etc.). A SoS deve ter ênfase nos times (objetivos da sprint) e resolver seus impedimentos. Não deve ser uma reunião de status report (do progresso do time de desenvolvimento aos gestores). Algumas questões que devem ser tratadas na SoS:

sos-perguntas

Finalizamos aqui! Espero ter contribuído com direcionamentos para a gestão ágil em larga escala na sua empresa. No próximo post vamos falar sobre a PO Sync e como alinhar a expectativa de produto com a execução das atividades.

Azure DevOps – executando testes automatizados a partir de plano de testes

Aprendemos como criar planos de testes no Azure DevOps e como associar aos work items (do board de desenvolvimento) para garantir a execução dos testes manuais – exploratório e casos de teste – com as atividades do projeto.

E podemos evoluir para a automação dos testes? Sim, para isso você precisa vincular o teste automatizado ao seu plano de teste e executá-los no Azure Test Plans (Azure DevOps) ou no Test Hub do TFS. Por exemplo, no deploy da aplicação, executando os testes sob demanda no fluxo de build e release.

Azure DevOps
O primeiro passo é acessar as configurações do plano de teste. No Azure DevOps, clique em Test Plans e selecione Test Plan Settings do plano de teste que irá utilizar.

test-plan-01

Em seguida, selecione o Build Pipeline responsável pela geração dos builds que possuem os binários de teste. Escolha o número do Build ou a opção do sistema automaticamente trabalhar com o último Build.

O próximo passo é criar a Release pipeline onde os testes serão executados. Se você já possui, escolha a sua release na lista de valores. Para criar uma nova, clique em new release pipeline contendo single stage com a tarefa Visual Studio Test já adicionada – visual-studio-test

test-plan-02

Lembre-se que é necessário ter o Visual Studio Test Platform Installer task instalado no agent computer. Veja que a Visual Studio Test task foi adicionada a Release Pipeline:

  • Selecione a versão 2.*
  • Escolha a opção de teste assembly, plan ou run.comparing-tests-vsts comparing-tests-vsts
  • As demais opções englobam a versão do Visual Studio Test para uso (Test Platform version), testes UI, input parametersSettings Files (caminho do arquivo runsettings ou testsettings usado com os testes). Veja mais sobre Visual Studio Test Task.

test-run-vsts

Suba para o nível do Agente (Run on agent) e verifique se o Agent Job está configurado com as máquinas necessárias para execução dos testes. Adicione em demands quando os testes exigirem máquinas especiais do agent pool. A opção Parallelism permite distribuir os testes entre múltiplos agentes.

test-run-vsts-pipelines

Verifique se o Build Pipeline com os binários de teste estão associados com a Release Pipeline.

pipeline-test

Por fim, acesse o Test Plans do Azure DevOps e escolha a suite de testes com os testes automatizados. Execute o teste (run test). O sistema checará os testes automatizados, validando configurações (do Visual Studio Test), permissões do usuário para criação da release, executa o teste e dispara a criação da release para o estágio selecionado.

run-test-vsts

E confira o resultado da execução:

automated-test-run

A análise das execuções ficam na área Runs do Test Plans. Veja o gráfico com o resumo da execução e os resultados do teste (em Test results).

automated-test-graph