E ai pessoal, tudo bem?

Hoje em dia, temos equipes cada vez maiores ou mesmo distantes trabalhando no desenvolvimento de aplicações, e precisamos de processos para garantir a qualidade de nosso software.

Geralmente, quando utilizamos o armazenamento com git, adotamos uma proteção na branch master, para controlar o que está sendo transferido de outras branches para ela, através de Pull Requests. Isto é o processo mais básico e mais utilizado na maioria dos ambientes. O VSTS também suporta o formato TFVC, mas aí já é uma questão de escolha do qual vai ser utilizado. Eu particularmente utilizo o git em 100% de meus projetos pessoais.

O Visual Studio Team Services, ou mesmo o Team Foundation Server, para quem utiliza no formato OnPremisses, possibilita alguns controles, de modo a garantir que um processo de qualidade seja seguido. Vamos ver neste artigo quais são estas funcionalidades e como elas podem ajudar a garantir que nosso software seja desenvolvido e entregue com qualidade.

Caso não tenha uma conta no VSTS ou um servidor do TFS disponível, basta acessar o site http://www.visualstudio.com, e se cadastrar na versão Community. Ela lhe dá acesso ao VSTS com uma cota gratuita de tempo para build, testes de carga e projetos ilimitados, com limite de 5 usuários por conta no VSTS.

Estou considerando neste artigo um fluxo básico com o Git, onde o código que será utilizado nos pacotes é obtido da branch master e novos desenvolvimentos ou fixes, são feitos em branches geradas a partir da master. Após o desenvolvimento, um Pull Request da branch de desenvolvimento é aberto, solicitando que as alterações seja aplicadas na master. Existem outros fluxos como feature, git-flow, etc. que serão abordados em outro artigo. A intenção neste artigo é fornecer alguns mecanismos básicos para garantir a qualidade do código que se adequem a maioria dos processos utilizados nas empresas, por mínimos que sejam.

Fluxo básico, onde crio uma branch a partir da master, desenvolvo nesta branch e solicito o review para aprovação do merge desta branch novamente para a master.

Acessando a seção de Policies da branch Master

Vamos criar um novo projeto, chamado BoasPraticasPR, com repositório em formato git, caso ainda não tenha um para realizar os testes. Caso já tenha um repositório para realizar os procedimentos do artigo, pode utilizá-lo sem problemas.

Após criar e acessar o projeto no VSTS, vamos clicar no menu Code, e em sequência, localizar a seção para inicializar nosso repositório com um arquivo README, como na imagem a seguir. Caso não esteja na aba Branches, por ser um projeto seu com código já existente, clique nela.

md

Após isto, teremos noss repositório inicializado. Vamos localizar a branch master na tela, e acessar seu menu de contexto, no botão “…”, e navegar através da opção Branch policies, como na imagem a seguir.

.

Nesta nova tela, teremos todas as policiesdisponíveis para controle dos Pull Requests que terão suas alterações aplicadas na master. Vamos ver uma a uma no detalhe.

master

Require a minimum number o reviewers

Require a minimum number of reviewers e suas opções

Nesta policy, definimos uma quantidade mínima de usuários que devem aprovar nosso PR, antes que o mesmo possa ser completado e ter suas alterações aplicadas na branch master. Isso é algo interessante, pois podemos alterar essa quantidade, dependendo da quantidade de membros no time responsável pelo projeto.

Temos ainda algumas opções como:

  • Allow users to approve their own changes: Esta configuração permite que o próprio solicitante do PR posso ser um aprovador. Não costumo utilizar, pois o interessante em um PR é que os demais usuários, mesmo de outros times façam uma avaliação do código proposto, pois o desenvolvedor solicitante já tem uma opnião “viciada” sobre seu código.
  • Allow completion even if some reviewers vote “Waiting” or “Reject”: Esta configuração permite que um PR seja completado e aplicado na branch master mesmo que alguns reviewers solicitem alterações ou rejeitem seu PR. Pode ser utilizada com muito cuidado, pois permite que um código rejeitado, seja aplicado sem ser devidamente corrigido, podendo gerar problemas sérios no release do sistema.
  • Reset code reviewer votes when there are new changes: Esta opção é bem interessante e recomendo fortemente seu uso, pois ela faz com que, caso um PR já tenha as alterações necessárias e o solicitante faça mais alterações após isto, force os reviewers s revisarem e votarem novamente sobre as alterações propostas, caso contrário, o solicitante poderia completar o PR adicionando código extra que não passou por revisão.

Check for linked work items

Check for lined work items e suas opções

Nesta policy, definimos se desejamos que nossos PRs tenham um ou mais Work Items associados ao mesmo, até para melhor identificação dos reviewers sobre qual era a funcionalidade ou correção solicitada e o código proposto para atender a esta solicitação.

Temos duas opções:

  • Required: Onde um PR deve obrigatóriamente ter um ou mais Work Items associados a ele, caso contrário, o mesmo não poderá ser completado.
  • Optional: Nesta opção, caso não tenhamos um Work Item associado, o VSTS não impedirá o PR de ser completado, mas um alerta será apresentado ao abrir o mesmo, informando que é importante o procedimento.

Check for comment resolution

Check for comment resolution e suas opções

Nesta policy, configuramos se o VSTS deverá validar os comentários, ou seja, solicitações de melhoria no código proposto ou dúvidas, sejam marcados como completados.

Temos duas opções:

  • Required: Onde o VSTS irá impedir que o PR seja completado até que todos os comentários sejam marcados como completos. Caso algum ainda esteja ativo (pendente de ação), o PR não poderá ser aplicado na branch master.
  • Optional: O VSTS não irá bloquear o PR caso ainda existam comentários ativos, mas um alerta será exibido no mesmo.

Enforce a merge strategy

Enforce a merge strategy e suas opções

Esta policy é bem interessante se queremos preservar o histórico de alterações da branch utilizada no PR quando o mesmo for aplicado na master, ou se queremos gerar apenas um item de histórico na master, relacionado ao PR.

Temos duas opções:

  • No-fast-forward merge: Esta opção força que, quando o PR for concluído e aplicado na master, todo seu histórico de commits seja transportado para a master. Exemplo: Se a branch dev_feature_01 teve 30 commits, ao completar o PR, a master terá essses mesmos 30 commits no histório mais o commit do merge do PR em si. Isto é interessante para poder validar, olhando diretamente para a master, o que tivemos de alterações no detalhe.
  • Squash merge: Com esta opção, ao completar o PR, apenas um commit será aplicado na master, mais o commit do merge em si. Para poder validar o histórico de como as alterações foram sendo aplicadas passo a passo, teríamos que navegar até o PR para ver no detalhe.

Build validation

Build validation

Nesta policy, podemos fazer com que a execução com sucesso do build seja um pré-requisito para que o PR possa ser completado. Com isso, estaremos criando um processo de CI, onde sempre que um PR for aberto, a execução do processo de build, com testes, validação de cobertura, etc. seja realizada com sucesso, impedindo que código “quebrado” seja aplicado na branch master.

Para configurar esta opção, clicamos no botão Add build policy, onde uma aba / janela será aberta com as opções.

Tela de configuração da Build policy

Nesta tela, temos algumas opções de configuração.

  • Build definition: Escolhemos qual a definição de build que será executada para validação do PR. Como um projeto no VSTS por ter mais de uma build, escolhemos nesta opção.
  • Path filter: Nesta opção, inlcuímos filtros dos arquivos modificados. A política de build será executada quando algum arquivo que faça match com esse filtro tiver sido alterado e incluído no PR. Caso o campo fique em branco, qualquer arquivo alterado é considerado para execução da policy.
  • Trigger: Nesta opção configuramos se a execução do build é manual, ou seja, um usuário solicite durante o review que o build seja executado, ou se o mesmo será executado de forma automática, onde caso qualquer nova alteração seja feita na branch, o build será novamente executado para validação.
  • Policy requirement: Nesta opção configuramos se a execução com sucesso do build será obrigatória ou não para permitir que o PR seja completado. Caso configurada como Optional e o build falhe, por exemplo, o solicitante poderá completar o PR e enviar código “quebrado” para a master.
  • Build expiration: Nesta opção, configuramos se o PR pode ser completado, se casado com a opção required em Policy requirement, a partir de quando a execução do build ocorreu. Podemos considerar um build expirado em 3 situações:
  1. Immediately when master is updated: Caso algum outro usuário complete um PR aplicando as alterações na master, sua branch estará desatualizada em relação a master, e consequentemente seu build. Um merge da master deverá ser feito para sua branch e o build ser executado novamente. Esta opção é bastante utilizada, pois evita conflitos no merge do PR.
  2. After X hours if master has been updated: Segue o mesmo caso da primeira opção, mas com um delay de X horas após a atualização da master. Esta opção, na minha opnião, é menos interessante que a primeira, pois mesmo que não existam conflitos no merge de sua branch, o build não contempla suas alterações com as últimas alterações da master, deixando uma “brecha” para erros.
  3. Never: Esta opção faz com que seu build nunca expire, mesmo que a master receba modificações feitas através de outros PRs. Não utilizo esta opção em meus projetos, pois não força uma real validação de minhas alterações e seus impactos no código já existente da master, que deveria estar sincronizado em minha branch.
  • Display name: Nome de exibição desta policy que será utilizado nos PRs.

Podemos ter mais de uma policy de build aplicada nos PRs, podendo validar cenários diferentes, builds em versões diferentes do ASP.NET, por exemplo, sendo alguns obrigatórios e outros não. Podemos utilizar isto para validar cenários diferentes e garantir comatibilidade de nossa aplicação.


Automatically include code reviewers

Automatically include code reviewers

Esta policy ébem interessante para incluir membros chave de uma equipe, como Líderes técnicos, Arquitetos e Product Owners. Com isso, ao abrir um novo PR, automaticamente estes usuários chave serão incluídos para revisar as alterações propostas. Podemos inclusive configurar se alguns devem obrigatóriamente validar o PR para que ele possa ser completado, ou não, e outras opções, que são estas:

Tela com opções da policy de Automatically include code reviewers
  • Reviewers: Neste campo, selecionamos quais usuários queremos adicionar como reviewers do PR assim que ele for aberto.
  • Path filter: Neste campo, podemos colocar um filtro, para que esta policy seja executada apenas quando determinados arquivos forem alterados.
  • Policy requirement: Configuramos se o PR deve obrigatóriamente ter aprovações dos reviewers selecionados nesta policy para que o mesmo possa ser completado.
  • Custom message: Podemos customizar a mensagem a ser exibida no PR, relacionada a aprovação destes usuários em cima do código proposto.

Podemos criar mais de uma policy, onde podemos “brincar” com as opções. Por exemplo, podemos definir que todo PR aberto deve automaticamente selecionar os desenvolvedores do time como opcionais e uma outra onde o Líder técnico e PO são obrigatórios.

Podemos ainda adicionar uma policy onde, se arquivos de um pacote Core ou algo mais sensível na aplicação seja alterado, que os Arquitetos do time sejam adicionados e tenham seus reviews como obrigatórios para que o PR possa ser completado.

Isto torna esta opção, assim como a de Build, bem flexíveis com a maioria dos processos existentes nas empresas hoje.


Revisando

Vimos neste artigo, diversas opções para garantir que um processo de validação seja aplicado nos Pull Requests de nossos projetos, garantindo assim uma maior qualidade em nossas entregas.

Um detalhe ao aplicar qualquer uma destas policies, no caso de nosso artigo na branch master, é que a branch fica protegida, ou seja, nada pode ser enviado diretamente para ela através de commits. Apenas podemos alterar a branch protegida através de Pull Requests que atendam a todas as policies configuradas.

Podemos configurar nas opções de segurança da branch, se determinados usuários tem permissão de override na branch. Esta é uma configuração que deve ser utilizada com parcimônia, aplicando apenas a usuários de alta confiança ou responsabilidade, como um Arquiteto líder ou pessoas de administração da segurança da empresa, pois permite que commits sejam enviados diretamente para a branch protegida em caso de emergência. Esta configuração pode ser feita na tela abaixo, acessada no menu de contexto da branch, opção Branch security.

.

Nesta nova tela, localizamos o usuário ou grupo de usuários com permissão de alterar diretamente a branch protegida, e damos permissão no item Exempt from policy enforcement

Acessando a tela de configurações de segurança da branch, onde damos permissão a um usuário ou grupo de realizar um “override” das policies da branch.

Bom, espero ter ajudado a todos fornecendo algumas opções para organizar e garantir maior qualidade em seus projetos, utilizando como ferramenta o VSTS.

Em breve iremos discutir, em outro artigo, como utilizar estas opções com outros fluxos de desenvolvimento, como git-flow, por exemplo.

Não deixem de comentar caso tenham dúvidas ou feedbacks sobre o artigo.

Até a próxima!