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.