Por que as políticas de check-in não são obrigatórias?
Mais uma da série “dúvidas comuns que respondemos infinitas vezes”: Por que as políticas de check-in não são obrigatórias? O recurso de check-in policy (política de check-in) é percebido pelos usuários do TFS como uma grande vantagem. Com ele, é possivel definir algumas premissas para a aceitação do código-fonte:
- Você testou seu código antes de fazer check-in?
- Você analisou o seu código para garantir que ele atende aos padrões da empresa?
- Você lembrou de associar suas alterações no código à atividade/demanda que originou essas alterações?
As políticas de check-in são definidas em nível de projeto (Team Project) e se aplicam a todos os desenvolvedores que atuam no tal projeto. Toda vez que eles tentam efetuar um check-in, as políticas são validadas e o usuário é alertado caso elas não sejam atendidas.
O ponto mais polêmico em relação às políticas de check-in é que elas podem ser ignoradas pelo usuário!
Por quê isso? Já ouvi pessoas falando que a Microsoft fez o serviço “pela metade”, deixando de fora a possibilidade de barrar o check-in. Bom, temos algumas explicações para isso. A primeira delas vem de um blog de FAQ do Team System:
Can we disable the “Override CheckIn Policy Failure” checkbox? Can that be customized based on User Login, Policy Type or File type? No. We get a lot of requests for this but our contention is that the person defining the policy can’t envision the situations that will arise where policy will need to be overridden. Thus, we designed it to be fully auditable by including policy compliance data in the changeset details and in the checkin mail that is delivered, but left it up to the developer to determine whether they have a good reason for overriding.
A razão é simples: se o desenvolvedor optou por ignorar a política de check-in, ele deve ter um bom motivo. Trabalho em equipe presume confiança entre seus membros, logo não faz sentido partir da premissa que todos são imaturos e irresponsáveis. Entretanto, como auditoria é fundamental em qualquer projeto (mesmo nos “ágeis”), o TFS registra no evento de check-in sempre que alguém optou por desconsiderar políticas de check-in que não estavam sendo atendidas. Dica: Na edição de Julho/2008 do Team Foundation Server Power Tools há uma nova ferramenta, o Alert Editor, que simplifica bastante o processo de auditoria das políticas de check-in. Adicione um alerta para ser notificado sempre que alguém optar por ignorar uma política definida num team project:
Entendendo políticas de check-in - com sorte, de uma vez por todas :-)
Há uma triste verdade a respeito das políticas de check-in, uma ainda pior que o fato de podermos usar o famigerado “override”: políticas de check-in não são universais. Ou seja, elas não são executadas e garantidas pelo servidor. Cada aplicativo-cliente é responsável por executar as políticas de check-in que lhe convierem. Do ponto de vista técnico, check-in policies nada mais são que assemblies .NET instalados em cada computador onde serão executados. Esses assemblies contêm algumas classes que implementam interfaces específicas definidas no SDK do Visual Studio. Quando instalamos o Team Explorer (cliente do TFS), recebemos “de brinde” as quatro políticas de check-in originais. No ato do check-in, o programa que o desenvolvedor estiver usando (por exemplo, o Visual Studio 2008) contata o servidor e obtém uma lista com os nomes das políticas de check-in que deveriam ser executadas, junto com suas respectivas configurações (que também foram definidas no servidor). Em seguida, verifica se essas políticas estão disponíveis no computador local e procede à sua execução. Com isso, podemos entender a afirmação de que “cada aplicativo-cliente é responsável por executar as políticas de check-in que lhe convierem”. O Visual Studio (2005/2008) é o cliente “premium” para o TFS. Como tal, é o único que garante executar todas as políticas de check-in que estiverem devidamente registradas no servidor e instaladas no computador do desenvolvedor. Isso traz uma variável adicional ao já conturbado universo das check-in policies. Ainda que possamos criar nossas próprias políticas de check-in (acrescentando novas opções às quatro originais), não há nada que garanta que elas serão executadas. Isso me faz lembrar de um velho problema que aflite desenvolvedores Web há muito tempo: Validação no Cliente vs. Validação no Servidor.
Validação no Cliente vs. Validação no Servidor
No universo da Web, aplicativos feitos em qualquer tecnologia (ASP.NET, PHP, Ruby, Java etc…) certamente se vêem às voltas com a necessidade de solicitar dados ao usuário. Formulários são usados para as mais diferentes entradas de dados. Porém, o HTML não é exatamente a melhor tecnologia para a criação de formulários de dados. Ele não tem praticamente nenhum recurso padrão de validação de conteúdo que os browsers possam usar para conferir o que o usuário nos levou. Isso geralmente leva a duas opções: <table cellpadding="2" width="697" align="center" cellspacing="0" border="1" > <tbody > <tr >
</tr> <tr >
</tr> <tr >
</tr> </tbody> </table> As boas práticas do desenvolvimento para a Web nos dizem que devemos, sempre que possível, oferecer as duas opções ao mesmo tempo. A conveniência da validação no cliente aliada à segurança da validação no servidor. Repare que a validação no cliente tem apenas o papel da conveniência, nunca podendo substituir a validação no servidor. Se tiver que optar por apenas uma delas, não há dúvidas: fique com o servidor. Bom, você deve estar se perguntando, mas o que isso tem a ver com o assunto em pauta? Tudo! Encare as políticas de check-in do TFS como client-side validation: rápidas, porém inseguras. Se eu realmente quiser garantir que o check-in é seguro e atende às definições do meu processo de desenvolvimento, preciso ter o equivalente TFS da server-side validation. As alternativas são:
- Team Build + Integração Continua (CI, Continuous Integration): Com o TFS 2008 é possível disparar o processo de build automatizado do Team Build simplesmente fazendo um check-in. Com isso, podemos verificar se as alterações que acabaram de ser produzidas se integram adequadamente ao restante do código já existente no repositório. Efetuar o build a cada check-in visa a validar continuamente a integração entre os diversos trechos de código produzidos todo o tempo pela equipe de desenvolvimento. Daí vem o termo integração contínua. Como o processo de build é disparado automaticamente pelo ato de check-in, e como ele ocorre no agente de build (e não na máquina do desenvolvedor), ele acaba sendo o equivalente da validação de servidor das aplicações Web. Podemos rodar a análise estática de código, podemos rodar testes unitários, podemos auditar o código. Se houver algum problema, o build é marcado como falho (“quebrado”). O changeset (as alterações feitas pelo desenvolvedor) que deu origem ao build pode, então, ser desfeito (usando, por exemplo, o comando tfpt rollback).
- Gated check-in: O problema da solução apresentada acima, baseada apenas no servidor de build, é que o check-in precisa ser feito antes de ser validado. Ou seja, em caso de problemas eu necessariamente terei que desfazer manualmente as alterações que quebraram o build. O ideal seria que eu pudesse disparar o buid antes do check-in, só efetivando a alteração no controle de versão se tudo corresse bem. É justamente disso que trata o conceito de gated check-in: As operações de check-in são interceptadas (geralmente usando shelvesets) e redirecionadas para um servidor de build especial. Esse servidor combina o código-fonte que já existe no TFS com as alterações que acabaram de vir do desenvolvedor. Se tudo correr bem, só então é que o check-in será consumado. O TFS “Rosario” terá suporte nativo a gated check-in. Por enquanto, você pode usar o OpenGauntlet para ter esse recurso à disposição no TFS 2008.
Resumo da ópera
Politícas de check-in são um recurso bastante poderoso e conveniente. Devido ao fato de poderem ser facilmente burlados, devem ser usados apenas como lembrete para os desenvolvedores. Dessa forma, eles serão lembrados de testar seu código, associar work items etc. Para garantir que o código produzido por sua equipe atenda aos critérios definidos em sua empresa, utilize alguma técnica de gated check-in.
06/08/2008 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 8 mins.
