Política de Check-in no TFS [v1.1]
Imprimir
Modificado em: Seg, 29 Mai, 2017 na (o) 9:59 AM
1.0 - Check-ins Pequenos
Os check-ins tem que ser o mais pequeno possível. Assim fica mais fácil de rastrear o que foi realmente feito naquele check-in. Quando faz-se um check-in colossal, fica difícil de desfazer pequenas partes em caso de necessidade. Por isto, organize-se e tente trabalhar com o menor escopo possível para que seja possível fazer pequenos check-ins.
1.1 - Check-ins com Responsabilidade Única
É importante separar os assuntos durante o check-in. Um exemplo claro são evoluções de código que também demandam refatoração. Neste caso, é obrigatório fazer um check-in para guardar a refatoração e outro para finalmente evoluir o código. Isto é importante para que possamos separar a evolução da refatoração, assim, poderemos desfazer partes sem afetar tudo, e principalmente facilitar o review do código.
1.2 - Check-ins de Banco de Dados
Os check-ins que envolvem procedures e ErWin devem obrigatoriamente ser feitos separadamente do que foi feito no Cbanet. Assim poderemos acompanhar melhor as evoluções das procedures e saber o que realmente qual alteração foi feita nas procedures ou no ErWin em um determinado check-in.
1.3 - Esteja sempre com a última versão antes do check-in
Preocupe-se em buscar a última versão da Branch na qual você está trabalhando antes de fazer um check-in! Isto é importante para que seu nome não fique exposto num build quebrado no monitor. Alem deste motivo, tem o fato de outras pessoas também estarem utilizando a mesma branch, logo, se você fizer um check-in que quebre algo, mesmo que sem querer, poderá atrapalhar o andamento de outras pessoas.
1.4 - Check-in somente no verde
Jamais faça um check-in se o código não está compilando ou que contenham testes que não passam! Para este cenário utilize Shelveset.
1.5 - Check-in bem documentado
É extremamente importante você dizer tudo o que foi alterado nos arquivos que serão enviados durante o check-in. Para isto, não faça check-ins com a descrição "Refatoração" ou "Evolução", por exemplo. Se você seguir à risca as outras políticas, não terá problemas para seguir esta regra.
1.6 - Checkpoint
Uma dica legal para que todas as regras acimais sejam de fácil utilização, é trabalhar com o conceito de checkpoint (ponto de controle). Sempre fazemos pequenas alterações e testamos, logo, quando atingir um ponto minimamente estável, onde uma parte de toda a alteração prevista já esteja funcionando, faça um check-in.
1.7 - Notas
Caso esteja em desacordo com alguma regra prevista neste documento, por favor, dê sua opinião junto ao time. Estamos sempre abertos a alterar aquilo que nos afeta negativamente afim de garantir um ambiente fluído e confiável.
Isso foi útil para você?
Sim
Não
Enviar feedback Desculpe-nos por não podermos ajudar. Ajude-nos a melhorar este artigo com seu feedback.