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. Isso é o processo mais básico e mais utilizado na maioria dos ambientes. O VSTS também suporta o formato TFVC, mas 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 essas 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 cinco usuários por conta.

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 sejam 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 menores que sejam.

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.

Feito isso, teremos nosso 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.

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

Require a minimum number o reviewers

Nessa 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: Essa configuração permite que o próprio solicitante do PR possa 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 opinião “viciada” sobre seu código.
• Allow completion even if some reviewers vote “Waiting” or “Reject”: Essa 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: Essa 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 isso, force os reviewers a 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

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 obrigatoriamente 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

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

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

Temos duas opções:

• No-fast-forward merge: essa 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á esses mesmos 30 commits no histórico mais o commit do merge do PR em si. Isso é interessante para poder validar olhando diretamente para a master, o que tivemos de alterações no detalhe.
• Squash merge: com essa 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

Nessa 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 essa opção, clicamos no botão Addbuildpolicy, onde uma aba /janela será aberta com as opções.

Nessa 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 pode ter mais de uma build, escolhemos nesta opção.
• Path filter: incluí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: nessa opção, configuramos se a execução do build é manual, ou seja, um usuário solicita 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: 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: aqui, configuramos se o PR pode ser completado, se casado com a opção required em Policy requirement, a partir do momento em que a execução do build ocorreu. Podemos considerar um build expirado em três 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. Essa 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. Essa opção, na minha opiniã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 essa 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 isso para validar cenários diferentes e garantir compatibilidade de nossa aplicação.

Automatically include code reviewers

Essa 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 obrigatoriamente validar o PR para que ele possa ser completado, ou não, e outras opções, que são estas:

• 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 essa policy seja executada apenas quando determinados arquivos forem alterados.
• Policy requirement: Configuramos se o PR deve obrigatoriamente 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, quando arquivos de um pacote Core ou algo mais sensível na aplicação fossem alterados, os arquitetos do time seriam adicionados e teriam seus reviews como obrigatórios para que o PR pudesse ser completado.

Isto torna essa opção, assim como a de Build, bem flexível 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 dessas 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 têm permissão de override na branch. Essa é 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. Essa configuração pode ser feita na tela abaixo, acessada no menu de contexto da branch, opção “Branch security”.

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.

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 discutiremos, em outro artigo, como utilizar essas 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!