Prepare Analysis Configuration – Definição de Build no VSTS

Hoje vamos falar sobre o uso do SonarQube no processo de Integração Contínua do VSTS. O primeiro passo é configurar a análise do código-fonte nas definições de Build. Isso está publicado em post anterior – Integração SonarQube com VSTS.

Feito isso, podemos acessar o SonarQube e analisar métricas dos projetos como bugs, vulnerabilidades, code smells e code coverage. Veja mais detalhes nas documentações do SonarQube.

A tela inicial exibe os projetos e a quantidade de Bugs (demonstra algo está errado no código e precisa ser corrigido), Vulnerabilidades (possível backdoor para invasores),  Code Smells (problema relacionado a manutenibilidade no código), Coverage (cobertura do código em relação a testes) e Duplications (partes do código que estão duplicadas).

sonarqube-inicial

A guia Issues demonstra os problemas encontrados no código-fonte e clicando em cima, podemos ver o detalhe exato da parte do código que precisa ser corrigido.

sonarqube-issues.png

Em Rules, podemos ver as regras utilizadas na análise do código-fonte. Além de exibir os detalhes, a ferramenta associa as regras ao linguagem do código. No exemplo abaixo, a análise percorre códigos em Java, C#, Javascript, etc.

sonarqube-rules

Quality Profiles é o serviço central do SonarQube, onde definimos requisitos e o conjunto de regras. Cada language plugin já vem com o built-in profile para que consiga trabalhar rapidamente com análises no SonarQube.

sonarqube-quality-profiles

 

 

Análise de Builds no VSTS – history | test analytics | code coverage | logs

Já explicamos em outros fóruns como criar as definições de Builds, automatizar e trabalhar com pipelines. Neste post vamos demonstrar como gerenciar os Builds no VSTS, após a execução.

1. A página inicial traz um resumo de informações (Summary) sobre o repositório (código-fonte), últimos Builds executados e Analytics (qtde de Builds e taxa de sucesso).

build-inicial

2. A guia seguinte de Test Analytics exibe o resultado dos testes realizados na execução dos Builds, quantificando as taxas de sucesso e falha dos testes durante um período específico.

test-analytics

3. A guia de Histórico demonstra as últimas execuções e clicando em cima do nome, será redirecionado a página de detalhes.

build-history

4. A página de detalhes contém:

  • Logs: exibe todas as tarefas executadas na definição do Build.
  • Timeline: é a página principal do Build executado. Contém informações de progresso, work items que estão relacionados, Code Coverage (exibe a cobertura de código realizada daquele Build) e Deployments (ambientes que tiveram deploy deste Build).
  • Code Coverage: detalha a cobertura do código em relação aos testes unitários
  • Tests: resultado dos testes aplicados (total | aprovados | falhas)
  • Whitesource Bolt: checa vulnerabilidades da aplicação

Qualquer outra extensão que seja instalada e adicionada nas definições do Build podem ser configuradas e assim obter detalhes desta tarefa após a execução do Build.

build-general

Resenha do livro O Andar do Bêbado (Leonard Mlodinow)

Fica a recomendação de mais um livro que li recentemente e achei bem interessante a visão do acaso na nossa vida (profissional, pessoal, etc.), citando pesquisas e contribuições de famosos matemáticos, físicos, economistas, sociólogos e psicólogos.

 O Andar do Bêbado está dividido em 10 capítulos:

  • Capítulo 1: introdução de conceitos sobre o acaso, padrão, sorte e aleatoriedade. A explicação para o sucesso é abordada, citando a probabilidade de que um filme ganhe milhões por mero acaso não é nada desprezível, e as implicações em outras áreas.

O exemplo de regressão à média, apresentado pelo psicólogo Daniel Kahneman, analisou um grupo de instrutores de voo em Israel, defendendo que eles deveriam ser elogiados em caso de resultados positivos. A plateia reagiu, pois entendia que o desempenho de alunos posteriores piorava quando isso acontecia.

Kahneman concluiu que os alunos naturalmente apresentavam desempenhos bons e ruins, mas a média se mantinha constante, e por isso, após um desempenho bom ou ruim, os próximos resultados não se igualavam.

  • Capítulo 2: sobre o princípio da probabilidade em que dois eventos ocorram nunca é maior do que a probabilidade de cada evento ocorra individualmente.
  • Capítulo 3: conceitos de espaço amostral de Girolano Cardano: “suponha que um processo aleatório tenha muitos resultados igualmente prováveis; alguns favoráveis (ou seja, ganhar) e outros desfavoráveis (ou seja, perder). A probabilidade de obtermos um resultado favorável é igual à proporção entre os resultados favoráveis e o total de resultados.“
  • Capítulo 4: o triângulo de Pascal é utilizado como base para conhecermos de quantas formas eventos consecutivos podem ocorrer.
  • Capítulo 5: sobre a  Lei de Benford (algarismos não aparecem na mesma frequência) e o caso de Joseph Jagger, que ganhou dinheiro no cassino, após algumas noites observando uma roleta viciada.
  • Capítulo 6: conta a história pessoal do autor, e a Teoria de Bayes para explicar o erro no exame de HIV apresentado. A probabilidade do exame dar positivo se o paciente não for HIV-positivo (que é muito baixa) e de ele não ser HIV-positivo mesmo se o exame der positivo (que não é tão baixa assim). Outras variáveis deveriam ter sido consideradas: como os hábitos de pessoas do mesmo grupo do autor e se tinham HIV.
  • Capítulo 7: estatística e noção de que toda medição tem erros. O exemplo da curva de desempenho de estudantes é impressionante pela semelhança: quando comparado o gabarito dos tidos melhores alunos com aqueles que chutaram as questões.

Nos últimos capítulos são aplicados conceitos à vida real. Um exemplo de como as avaliações humanas são baseadas nos resultados (e não nas habilidades), cita o provável resultado de 2/3 dos Diretores de empresa guiado mais pelo acaso que pelas habilidades.

E como podemos resistir a formação de julgamentos com base em nosso arcabouço determinístico automático, por exemplo, quando um professor acredita inicialmente que um de seus alunos é mais inteligente que outro, ele se concentra seletivamente em indícios que tendam a confirmar essa hipótese. No caso da entrevista de emprego, o empregador tende a formar uma rápida primeira impressão do candidato e passa o resto da entrevista buscando informações que a corroborem.

Também a busca humana por padrões e como nossa habilidade para reconhecer padrões pode nos levar a erros, considerando ilusões ópticas, vieses e heurísticas. E, por não considerar o papel do acaso em nossas vidas. A Falácia da Boa Fase experimentada em atletas e o Viés da confirmação quando estamos diante de uma ilusão (ou uma nova ideia), em vez de tentarmos provar que nossas ideias estão erradas, geralmente tentamos provar que estão corretas.

 

 

DevSecOps – Integração Contínua no VSTS com WhiteSource Bolt

WhiteSource Bolt é um componente eficiente para execução de scan e verificação de vulnerabilidades na sua aplicação. A extensão do VSTS pode ser baixada no Marketplace do Visual Studio – WhiteSource Bolt.

Após a instalação do componente, podemos incluir no processo de Integração Contínua do VSTS, adicionando a extensão nas definições do Build. A tela abaixo demonstra a configuração da extensão, referenciando o diretório raiz.

vsts-build-definition

Entre os principais benefícios de utilizar do WhiteSource Bolt:

  •  Integração c/ Visual Studio Team Services (VSTS) ou Team Foundation Server (TFS)
  • Detecta todos os componentes open source da sua aplicação
  • Provém alertas em vulnerabilidades e componentes desatualizados
  • Relaciona dados obtidos com políticas pré-definidas da empresa
  • Geração de relatórios com os principais issues identificados

Após a execução do Build, podemos visualizar o relatório na aba do WhiteSource Bolt, relacionando todas as vulnerabilidades encontradas na aplicação, classificadas em Low | Med | High. Veja que há uma descrição detalhada dos componentes identificados e a sugestão de como tratar a vulnerabilidade (coluna Top Fix).

vsts-whitesource-bold

 

 

IT Change Management – solução de problema com Design Thinking

Contexto
Em organizações que possuem um processo burocrático na implantação de RDMs (Requisição de Mudanças), regidas por SOX e controles de auditoria, o lead time e a frequência de deployment podem ser prejudicados por conta da quantidade de aprovações e documentos que o Change Management exige para as mudanças serem publicadas em produção.

Entre os principais problemas:

  • Aprovações: análise árdua de documentos
  • Publicação: erros e delays nas publicações manuais de novas releases
  • Lead time: tempo alto entre a abertura do chamado e a publicação

O fluxo deste processo tende a ser algo desta forma:GMUD.png

Solução
Diminuir o lead time no processo de desenvolvimento de sistemas, utilizando o Design Thinking como base para criação de um novo processo de mudança e resolução do problema.

Após a definição do novo processo, recomenda-se utilizar métodos ágeis para execução das atividades definidas como backlog. O OKR foi escolhido para definir os objetivos e acompanhamento das metas.


Benefícios

  • Melhorar o time-to-market com implementações frequentes
  • Reduzir FTE e recursos envolvidos no processo de mudança, devido a automatização do processo de Build/Release e preenchimento dos documentos
  • Diminuir o lead time e bugs encontrados em sistemas, devido a erros de implementação

 

Double Diamond
A abordagem Double Diamond (no Design Thinking) auxilia a compreender o problema, utilizando dois diferentes tipos de pensamento:

  • Divergente: pensamento amplo, considerando qualquer ideia.
  • Convergente: pensamento estreito, identificando e focando em um ou dois dos principais problemas e soluções.

design-thinking.png

  1. Discover customer problems
  2. Define specific customer problems
  3. Develop potential solutions to these customer problems
  4. Deliver feasible and viable solutions to these customer problems

design-thinking-II.png

E na sequência priorizar as ideias, seguindo a matriz de impacto/dificuldade.

matrix-difficult-impact

A execução das atividades podem ser feitas utilizando o framework SCRUM, trabalhando com a cadência de reunião de planejamento (planning), e junto ao PO (Product Owner) maximizar o valor deste trabalho, alinhado com a solução combinada nas sessões de Design Thinking.

As reuniões diárias (dailys) para manter o f-up do projeto e melhorar a previsibilidade, sempre atuando nos bloqueios do projeto. Terminada a Sprint (em média 10 dias úteis), o time faz uma Review e Retrospectiva para identificar o que foi bem e o que precisa ser melhorado. Certamente são valiosos inputs para a próxima reunião de Planning.

Por fim, utilizamos o OKR para definição das metas e acompanhamento dos objetivos.

Objective: Melhorar o processo de mudança na área de sistemas (TI)
Key
Results:

  • Reduzir o lead time médio para 8 horas
  • Preenchimento automático de 80% dos campos da documentação da RDM
  • Deployment sem intervenção humana
  • Fluxo de aprovação (infra | dev | change) automática via ferramenta

 

Testes Unitários com IntelliTest no Visual Studio

E como está o nível de maturidade do seu time de desenvolvimento? No post de hoje vamos falar sobre os testes unitários e como alavancar o seu uso com a ferramenta IntelliTest, disponível no Visual Studio Enterprise (2015 e posteriores).

Saiba que um dos primeiros passos para trabalhar com Integração Contínua é a estruturação dos testes a serem realizados no sistema. Além de conceitos, veremos como aplicar os testes unitários sem precisar desenvolver classes e métodos no código-fonte. O foco então será na parte inferior da pirâmide de testes.

Triângulo dos testes, mostrando a razão ideal entre os diversos tipos de teste de software

Testes Unitários
Os testes unitários são escritos para validar pequenas partes do código (unidades individuais), com o intuito de verificar a corretude e comportamento esperado do código. Não são feitos para testar o sistema como um todo!

E este processo não aumenta o tempo de desenvolvimento? Inicialmente sim, mas trabalhe na automatização deles, ou utilize diretamente a ferramenta IntelliTest. Por outro lado, os principais benefícios são:

  • Problemas são descobertos mais cedo
  • Previne regressão (testes unitários automatizados com suite de casos de teste nos avisam se houve quebra ao introduzir novas funcionalidades)
  • Serve como documentação do sistema
  • Ajuda a melhorar o design do código


IntelliTest
IntelliTest dá suporte ao código C# e .NET framework para execução de testes unitários, gerando uma entrada de teste que executará a instrução no código. Visualize o resultado dos testes e em caso de falha, você pode adicionar código para corrigir. Veja que seus tipos devem ser públicos para gerar os testes unitários.

1. No Visual Studio, escolha a classe com o(s) método(s) que você deseja testar.
2. Já no método escolhido, escolha Run IntelliTest para gerar os testes unitários.

Clique com botão direito do mouse em seu método para gerar testes de unidade

3. A execução dos testes é apresentada em tabela com os dados de entrada e saída. Para executar em todos os métodos públicos, basta escolher a classe em vez de um método específico.

4. Salve os testes de unidade como um pacote de regressão.

Select tests; right-click and choose Save

5. Os testes unitários individuais estão no arquivo .g.cs do projeto; os testes unitários com parâmetros estão no arquivo .cs.

Open class file in test method to view unit test

 

Referências

Trabalhando com Agent Phase no VSTS – Build e Release

Agents
Os Agents funcionam como serviços conectados a um Pool no VSTS. No caso de execução das tarefas de builddeployment, por exemplo, o Agent utiliza a máquina e alguns comandos para obter o resultado esperado.

A configuração dos agents no VSTS utiliza jobs na execução das tarefas. Outro passo é a gestão da Infra, configurando a máquina de Build, Pool e Queue Default. Há dois tipos de agents:

  • Microsoft-hosted agentsagents estão hospedados com a Microsoft, responsável pela manutenção e atualizações. Facilita quando as definições de build release estão no VSTS.
  • Self-hosted agents: agents são configurados e gerenciados por conta própria. A execução do build deployment é baseado em self-hosted agent. Pode ser usado no VSTS ou TFS.


Agent Phase

É o local de execução, seja no agent ou no servidor, que permite que uma série de tarefas sejam agrupadas. Estas tarefas podem ser executadas em paralelo. Acesse o VSTS > Build and Release > Releases e adicione um novo Agent Phase.

agent-phases

Entre as principais configurações estão o Agent QueuePool information e o plano de execução. Feito isso, com o workflow criado (canto esquerdo), podemos adicionar tarefas  a serem executadas pelo Agent.

Enquanto o Agent é geralmente objeto no processo de Build, no processo de deployment, o objeto pode ser tanto o Agent, o Deployment Group ou o servidor.

Para mais detalhes nas configurações dos Agents, acesse o site da Microsoft.