Confirmar / verificar código todos os dias é uma boa prática?

Eu tenho lido a nota de Martin Fowler sobre Integração Contínua e ele lista como obrigatório "Todo mundo se compromete com a linha principal todos os dias".

Não gosto de confirmar código, a menos que a seção em que estou trabalhando esteja completa e que, na prática, confirmo meu código a cada três dias: um dia para investigar / reproduzir a tarefa e fazer algumas alterações preliminares, um segundo dia para concluir as alterações. e um terceiro dia para escrever os testes e limpá-los ^ para envio. Eu não me sentiria confortável enviando o código mais cedo.

Agora, retiro as alterações do repositório e as integro localmente geralmente duas vezes por dia, mas não as submeto com frequência, a menos que consiga realizar um trabalho menor.

Pergunta: está cometendo todos os dias uma prática tão boa que devo alterar meu fluxo de trabalho para acomodá-lo ou isso não é aconselhável?

Edit: Eu acho que deveria ter esclarecido que eu quis dizer "commit" no significado do CVS (também conhecido como "push"), já que é provavelmente o que Fowler teria significado em 2006 quando ele escreveu isso.

A ordem é mais arbitrária e depende da tarefa. Meu objetivo era ilustrar o período e as atividades, e não a seqüência exata.

Não concordo com essa regra e concordo com o que Mason Wheeler disse. Eu gostaria de adicionar algumas idéias.

Eu tento confirmar cada vez que tenho uma alteração significativa a ser confirmada: isso pode ser várias vezes ao dia se eu corrigir vários bugs pequenos ou uma vez por semana se estiver trabalhando em um software maior que não pode ser usado pelo restante da atualização. o código de qualquer maneira significativa até atingir um estado consistente.

Além disso, interpreto o comprometimento como publicação de uma revisão significativa que contribui com novas funcionalidades para a base de código. Acho que se deve tentar limpar o código antes de se comprometer, para que outros desenvolvedores possam entender o significado e o objetivo da mudança quando analisarem o histórico de revisões. Quanto menos alterações os outros desenvolvedores veem na história, melhor: quando eu olhar para o histórico de revisões, quero ver incrementos que adicionam alguma funcionalidade significativa; Não estou interessado em todas as pequenas ideias que cada desenvolvedor teve e queria experimentar antes de chegar à solução.

Além disso, não acho que seja uma boa ideia usar o servidor SVN (ou qualquer outro sistema de controle de versão) como um recurso de backup no qual o instantâneo atual do código está comprometido (desde que seja compilado): você pode usar um pendrive ou uma unidade USB externa ou um disco de rede para espelhar seu código atual, para que não se perca se o computador quebrar. Controle de revisão e backup de dados são duas coisas diferentes. Publicar uma revisão não é o mesmo que salvar um instantâneo do seu código.

Finalmente, acho que não deve ser um problema comprometer-se de vez em quando (ou seja, apenas quando alguém estiver realmente satisfeito com o estado atual do código) e evitar conflitos de mesclagem não é uma boa justificativa para cometer (com muita freqüência). Muitos conflitos de mesclagem acontecem quando pessoas diferentes trabalham nos mesmos arquivos ao mesmo tempo, o que é uma má prática (veja, por exemplo, este artigo , ponto 7). Os conflitos de mesclagem devem ser reduzidos dividindo um projeto em módulos com interfaces claras e o menor número possível de dependências, e coordenando o trabalho dos desenvolvedores para que o código no qual eles trabalham se sobreponha o mínimo possível.

Apenas meus 2 centavos.

EDITAR

Outro motivo contra comprometimentos prematuros que me veio à cabeça é que uma versão (muito) de buggy não pode ser testada. Se você está comprometendo o tronco e sua equipe de teste está testando todos os dias, eles podem não ter uma versão testável por algumas horas (ou por um dia). Mesmo se você não tentar corrigir o bug e apenas reverter suas alterações, uma reconstrução poderá demorar algumas horas. Com, digamos, cinco testadores trabalhando em sua equipe, você perdeu 5 x 2 = 10 horas do tempo da equipe devido à inatividade. Isso aconteceu comigo uma vez, então eu realmente tento evitar confirmações prematuras em nome da confirmação o mais rápido possível .

Eu comprometo o código várias vezes ao dia . Sempre que chego a um ponto em que o código está completo o suficiente para compilar e não quebra outras coisas, ele entra.

Você deve analisar seu trabalho para poder fazer o check-in com segurança algumas vezes ao dia.

As razões para isso são duas:

1. Qualquer trabalho que não esteja registrado pode ser perdido - seu computador pode ter uma falha catastrófica. Nesse caso, quanto mais você espera, mais trabalho perde.
2. Quanto mais você trabalha sem fazer check-in, mais código os outros precisarão integrar quando você finalmente decidir que é necessário. Isso apresenta mais chances de conflitos e problemas de mesclagem.

Aderir de maneira servil a qualquer metodologia ou prática sem entender as razões por trás disso nunca é uma boa idéia. É daí que vem a programação do culto à carga.

Portanto, "eu deveria me comprometer todos os dias porque Martin Fowler disse isso" é simplesmente estúpido. E às vezes também é impraticável. Se você estiver trabalhando em um novo recurso complicado, poderá não chegar a um ponto em que valha a pena conferir até que você já trabalhe nele por alguns dias.

Isso não significa que você deve garantir que tudo esteja perfeito antes de fazer o check-in. Essa é uma boa maneira de perder o trabalho se algo der errado. A coisa correta a fazer é desenvolver e usar o bom senso sobre o assunto. As regras práticas podem apenas ajudá-lo muito.

Oded deu duas razões importantes para confirmar o código com a maior frequência possível. Vou adicionar mais alguns:

1. Enquanto trabalhava em seu trecho de código, outros podem precisar de algumas funções nesse código. Eles não devem esperar 6 dias para obtê-lo. Nesse caso, meus colegas geralmente criam um protótipo no meu pedaço de código, o comprometem, eu adiciono o corpo e o comprometo novamente. E isso geralmente é feito em algumas horas.

2. O código 'comum' é para que todos vejam todas as alterações o mais rápido possível. Se o trecho de código no qual você está trabalhando é totalmente separado do trabalho de outras pessoas e você não espera que eles esperem, é recomendável criar um ramo para você trabalhar e, se tudo der certo, mescle-o para a linha principal.

Acredito firmemente em cometer todas as mudanças lógicas que valem a pena ser mantidas. Confirme com frequência e, se não vale a pena manter o código, volte ao estado limpo. Quanto mais você esperar para enviar / publicar seu código de volta, mais difícil será implementar e mais problemas você terá. Você também receberá comentários sobre suas contribuições muito mais rapidamente:

• eles quebram a construção?
• você está duplicando os esforços de outro membro da equipe?
• você está fazendo algo incorreto?
• ou as pessoas estão esperando por você?

Pequenas mudanças são muito mais fáceis de gerenciar.

Além disso, vale a pena notar a diferença entre diferentes sistemas de controle de versão. Alguns, como o Git (distribuído), permitem confirmar e controlar todo o seu histórico localmente, pressionando apenas quando você estiver pronto para publicar. Outros, como o SVN (centralizado), combinam as duas etapas, tornando os pequenos commits muito ineficientes.

Não esqueça que seus commits são essencialmente documentação de alterações. Quando as coisas dão errado, você ficará feliz em ter mais história do que não o suficiente. Um único commit por um período de semanas parece inútil para mim. Acabaria lendo cada linha de código alterada, em vez do resumo de cada parte lógica.

Acho que a maioria das respostas aqui perde um dos principais pontos da declaração de Martin Fowlers. Isso está relacionado à integração contínua . O código que não está registrado (enviado / publicado / mesclado) na linha principal não é testado.

Isso não deve ser lido como um incentivo para confirmar qualquer código que você tenha em sua máquina local sempre que for hora de sair do escritório. Como apontado por vários outros aqui, isso seria ruim, quebraria a compilação e causaria uma linha principal instável.

No entanto, é recomendável encorajar as alterações em pequenas etapas que podem ser registradas na linha principal sem causar problemas. Isso incentiva a evolução do código em vez de rasgar tudo e reescrever.

Agora, o que há de bom nessa maneira de trabalhar?

1. Não cometer grandes pedaços de código ou mudanças revolucionárias reduz a chance de quebrar a compilação.
2. Se o seu commit interrompe a compilação, é bastante trivial identificar quais são os problemas, revertê-lo e confirmar uma versão fixa rapidamente.
3. Ao garantir que todos os testes sejam executados em todas as pequenas alterações no código, você garante que não introduza bugs ou regressões sutis que podem resultar do crescimento do código fora do esquema de integração contínua.

É claro que nem todas as mudanças se prestam a essa abordagem. Como outros apontaram, nenhuma regra é absoluta. No entanto, para alterações que devem permanecer fora da linha principal por um longo tempo, configure uma linha principal alternativa com seu próprio esquema de integração contínua e siga a mesma abordagem. Com os VCS distribuídos de hoje, isso é algo bastante fácil de fazer.

Argumentos para o check-in todos os dias:

• O código é armazenado e protegido contra falha no disco rígido
• A atividade pode ser registrada nas notas de confirmação ( o que eu fiz na quinta-feira ...? )
• A integração com a base de código existente acontece mais cedo e em partes menores, provavelmente identificando conflitos ou mesclando problemas mais cedo
• Sua equipe tem visibilidade do que você está trabalhando
• Seus colegas podem trabalhar com suas interfaces mais cedo, dando-lhes mais tempo para se integrarem ao seu 'grande e complexo código'
• Seu código será testado no mundo real mais cedo, ou pelo menos exposto a mais uso do que o permitido, levando à identificação anterior de bugs ou omissões.

Argumentos contra o check-in todos os dias:

• Não precisa ou não quer
• Ainda não 'limpei' meu código, está uma bagunça
• Não tem tempo

Não acredito que exista uma boa razão para fazer check-in menos que diariamente, além de preguiça ou desorganização. Nada pior do que ver o código em execução no ambiente de desenvolvimento não corresponde ao código na ramificação de desenvolvimento porque alguém 'ainda não terminou' e, portanto, não fez check-in.

Eu adoraria estar errado nisso, por favor, deixe-me saber qualquer argumento legítimo contra o check-in diário.

Se você quer dizer "confirmar" como "mesclar na linha principal", definitivamente não deve fazer isso todos os dias em um projeto de software que está sendo lançado para os clientes. Você deve mesclar as alterações feitas e testadas, para que a linha principal esteja sempre funcionando e liberável, e não em um estado interrompido, com recursos pela metade.

No entanto, o luxo de trabalhar com o controle de versão distribuído de hoje é que você pode manter a linha principal estável e, ao mesmo tempo, git/hg/whatever commitsempre que sentir que deseja preservar o estado das coisas. Faço isso uma vez a cada poucas horas e definitivamente no final de cada dia.

Com o DVCS, você pode publicar seu trabalho, colaborar com outras pessoas da sua equipe e mantê-lo atualizado com as alterações na ramificação da linha principal. Você pode fazer tudo isso sem poluir a estabilidade do código de que seus clientes e / ou outras equipes dependem.

Nos tempos em que o Subversion era a tecnologia mais recente e não havia como forçar e mesclar ramificações de recursos sem muita dor, ter uma linha principal onde vários recursos diferentes estavam em construção simultânea poderia ter sido a melhor abordagem. Mas essa superioridade não escala além de 2010.

No Team Foundation Server, você pode 'Arquivar', que não é o mesmo que um check-in, mas apenas faz um backup do seu código para que, se sua máquina morrer, você não perca as alterações.

Eu também vi casas de software que têm uma 'linha de desenvolvedor' e uma 'linha principal'. Os desenvolvedores podem fazer o check-in na linha do desenvolvedor sempre que acharem adequado e apenas o líder da equipe tem acesso à linha principal, de modo que eles são responsáveis ​​por copiar o código do dev para o main quando a produção estiver pronta.