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.

Improvements to Release process – VSTS

A Microsoft disponibilizou uma nova versão da página inicial de Release no VSTS, com melhorias significativas e vale a pena compartilhar. Se a página abaixo não aparecer, ao acessar a guia Release, clique em Help no canto direito superior.

vsts-news

Release details | Environments
A área de Release exibe informações de triggers, artefatos e do solicitante. Em environments, você pode visualizar o status, progresso e resultado. E os logs também estão disponíveis em um clique.

pipeline-new

Pre and post-deployment approvals and gates
Visualize as aprovações antes e após o deploy em algum ambiente. Clique no ícone de approvals para e veja os detalhes. Se há alguma aprovação pendente, o tempo de espera é indicado. Em logs, temos os detalhes das aprovações, com data e horário do evento.

pre-deployment-vsts

Commits e work items
Ao clicar no ambiente, veja as informações de commits work items ocorridos no deploy da nova release. Ótima oportunidade de rastrear as tarefas realizadas na release.

commit-work-item

In-progress environments
O pipeline também disponibiliza o andamento de deploys e integration test. Em detalhes, podemos ver o log do agent phase, entre outros. Utilize a guia Test para ver o resultado dos testes em cada ambiente e outras extensões que contribuem para o processo.

in-progress-deployments

 

DevOps Day São Paulo SP – Resumo do evento

Aconteceu o DevOps Day em São Paulo/SP (06/07 e 07/07) e o evento foi muito glorioso na troca de conhecimento e aprendizado de como as empresas (pequenas e grandes) estão lidando com os desafios em DevOps, focando em construir o produto certo, com o tempo de resposta que o mercado precisa, gerando o ROI esperado.

06/06

[13h30] Automação de ACL através de Redes Definidas por Software

  • Redes definidas por software – SDN
  • Plano de dados e controle; Topologia Fat Tree; PoD (point of delivery); spine leaf
  • ACL (Access control list) e NaaS (Network as a service)

[14h] Die Hard – A tale of an always on app – K8s VS Chaos

  • Chaos Engineering – experimentação em sistemas distribuídos para capacitar ambiente de produção
    • Definir o estado estável da aplicação
    • Hipótese de permanência
    • Inserir variáveis para simular processos
    • Coletar dados, ajustar e começar de novo

[14h30] 7 Passos para DataOps

  • Cultura, segurança e governança
  • Áreas: Infra, Engenharia de dados, Cientista de dados e Analista de dados
  • Como: catálogo de dados, linhagem (cruzar informações) e semântica significativa
  • Quando: quando surgirem as perguntas; NOSQL serve para estrutura quando se tem as respostas apropriadas

formula-evolucao

[15h30] Mapeando 1 milhão de recursos em uma Cloud

  • IaaS – PaaS – EaaS


[15h45] DevOps não é sobre velocidade, é sobre qualidade!
Nível de maturidade: 1) Git Flow – code review; Testes – TDD; Deploy automatizado 2) Qualidade de código – SonarQube, Codacy, etc.; Monitoramento (New Relic); Logs (Graylog Splunk) 3) Entrega continua; Docker; Microserviços etc.


[16h] Entrega Contínua e aplicações em Produção: por que não é só a implantação?
Jez Humble

  • Integração Contínua: trunk based development; ferramentas
  • Qualidade Contínua: práticas (TDD, etc.); ferramentas de teste
  • Configuration Management: versionamento, infra as code e features toggles

Susan Fowler: 8 princípios | Production readiness | Case Uber (microserviços com foco no desempenho)

Uptime: Spotify 99,98% (1h45m por ano); Gitlab 99,99% (52m por ano); Facebook / Linkedin / Twitter / NY Times 100%

[17h] Kanban para equipes de infraestrutura com STATIK

  • Gestão de mudança
  • Times multifuncionais – funciona? Operação 24 x 7; backlog iteração; valor; mistura de prioridades
  • Manifesto da Infra | estabilidade e segurança
  • Kanban: comece com o que faz hoje; cadeia de valor do cliente; conheça seu cliente
  • STATIK (Systems Thinking Approach to Implementing)
  • Demanda x Capacidade: 4 Qs

 

07/06

[14h] A “Especificação por Exemplo” trabalhando pro time

  • Ágil precisa: documentação precisa e testável | fácil de manter | escrita JIT
  • Livro Gojko Adzic – Specification by Example (SBE)
  • Especificação – BDD – System (resultado)
  • SBE não é testes; não é automação; imutável
  • SBE é focada no negócio; pode ser automatizada
    • Exemplificar os casos descritos nas estórias
    • Validar frequentemente
    • Fazer conjuntamente com o time
  • Focar em construir o produto certo


[16h] Promovendo Continuous Code Quality com Gamificação

  • Continuous Integration: commit diário – teste automatizado – recuperação em até 10 minutos
  • Code Quality: menos bug e vulnerabilidade
  • Gamificação: dopamina – produtividade prazerosa do jogo; desafios, recompensas, regras construídas de maneira colaborativa, etc.
  • Indicadores do engajamento: code smell, code review, bugs e vulnerabilidades

 

Azure DevOps Project – Criação de CI e CD das aplicações com este serviço

A Microsoft lançou uma preview do serviço Azure DevOps Project que vem para facilitar o uso de Continuous Integration (CI) e Continuous Delivery (CD). Configure em poucos passos de forma visual o desenvolvimento, deploy e monitoramento da aplicação. As principais características do DevOps Project são:

  • Provisão de recursos Azure com repositório Git
  • Integração automática com pipeline de CI/CD
  • Dashboard de commitbuildsdeployments
  • Pipeline de Continuous Delivery para deploys
  • Monitoramento com Application Insights

 

Que tal iniciar na ferramenta? Digite DevOps Project na caixa de busca que o serviço ficará disponível para escolha.

1. Runtime: escolha o tipo da aplicação
Entre as opções disponíveis, um conjunto de aplicativos em .Net, Java, Node.js, PHP, Python ou trazer seu próprio código.

azure-devops

2. Framework: defina o framework da aplicação
Como escolhemos trabalhar com .Net anteriormente, aqui temos a opção ASP .NET e ASP .NET Core, também adicionar a base de dados SQL Server.

azure-devops-project

3. Service: deploy the application
E então se o deploy será feito em máquina virtual ou plataforma Web App (Windows ou Linux). Também há previsão de liberação para Web App for Containers.

azure-devops-project-deploy

4. Create
O último passo é a criação do projeto, podendo também utilizar a conta existente do VSTS. As demais configurações são referentes ao vínculo com a assinatura, região e nome do serviço.

azure-devops-project-create

Neste momento o serviço cria o repositório, build definition, release e web app. Também executa o build e deploy da aplicação para o Azure.

Painel DevOps
Após a criação, o painel (abaixo) fica disponível para visualizar informações sobre:

  • CI/CD Pipeline – branch, commit, definição do build e deploy
  • Repositório
  • Recursos do Azure – Endpoint da aplicação, serviço da aplicação e application insights

devops-painel

E por fim, você pode acompanhar os detalhes da aplicação, clicando em qualquer link da área de CI/CD Pipeline. Com isso, você será direcionado para o VSTS e analisar tudo que foi criado, log da execução e customizar o que tiver necessidade.

This slideshow requires JavaScript.