Quando é apropriado começar a usar a próxima revisão de uma ferramenta ao alimentar cães?

Especificamente, estou trabalhando em uma ferramenta que integra um DVCS e um sistema de compilação, mas imagino que o desafio que enfrentarei surgiria para qualquer pessoa que desenvolvesse uma ferramenta "meta" (compilador, VCS, sistema de compilação, test runner etc.) deseja desenvolver através de "dogfooding" .

Minha pergunta é: em um processo de liberação no estilo scrum usando o fluxo de trabalho de ramificação , em que momento começo a usar uma versão mais nova da ferramenta no ciclo de desenvolvimento da ferramenta?

Estou procurando um processo para criar equilíbrio entre:

• use constantemente a developversão da ferramenta: Acho que estou interrompendo meu próprio desenvolvimento à medida que as alterações são incorporadas.

• use constantemente a masterversão da ferramenta: quaisquer problemas que eu descubra através do dogfooding são problemas que já foram liberados.

A primeira coisa a fazer é ter testes de regressão off-line automatizados muito completos. Torne a aprovação nesses testes um requisito mínimo para o que você usa oficialmente.

Segundo, você precisa de uma maneira simples e simples de voltar à versão de trabalho anterior, para problemas que seus testes automatizados não detectam.

Por exemplo, meu kernel Linux foi corrigido por um tempo personalizado. Eu corrigia e compilava meu kernel no mesmo computador em que pretendia usá-lo, o que significava que eu poderia perder meu ambiente de desenvolvimento se criasse um kernel com defeito. Portanto, certifiquei-me de sempre manter um bom kernel conhecido no meu menu GRUB; portanto, se eu cometer um erro, voltei a um bom ambiente de desenvolvimento com uma simples reinicialização.

Coordenar isso com uma equipe é complicado, mas suponho que seja principalmente uma questão de permitir que alguém inicie um fallback e comunique os motivos. No controle de versão, uma maneira de designar isso seria algo como uma last_known_goodramificação, em algum lugar entre develope masterno seu fluxo de trabalho. Nada é empurrado até que você tenha alimentado com êxito uma compilação.

Se esta ferramenta estiver sendo usada para produzir software com qualidade de produção (especialmente se estiver sendo usado recursivamente, ou seja, para se desenvolver), aumentaria seus esforços iniciais de teste e esperaria o uso de alimentos para cães até que a versão seja estável o suficiente para que você esteja bastante confiante de que não quebrará o código de produção usando-o.

Se você precisar aguardar que a versão principal tenha esse nível de confiança, que assim seja.

O Git também é uma ferramenta desse tipo e, obviamente, também alimenta cães. Mas faz isso em diferentes graus em diferentes ambientes. Os servidores públicos estão apenas executando o release, enquanto os desenvolvedores geralmente trabalham com next(esse é o nome do projeto git para "desenvolver") ou pu(ainda mais desenvolvem que desenvolvem). Qualquer desenvolvedor que está bloqueada por algum problema pode voltar para nextou masterou a última versão sempre que eles são bloqueados por alguma coisa e o repositório principal não é afetado, assim que os problemas podem ser limpos, referindo-se a ele.

O modelo de ramificação é semelhante ao anterior, com nomes ligeiramente diferentes. masteré a partir do qual os grandes lançamentos são feitos, o maintramo de lançamento para o próximo lançamento pontual, nexté semelhante ao desenvolvimento, com uma pequena diferença, de que os recursos podem ser mesclados para serem masterizados separadamente depois de estar no próximo já, em vez de no próximo próximo.

Há um ramo extra pu,. Isso é criado mesclando todas as ramificações de recursos consideradas para integração next(a ramificação é descartada e recriada toda vez). O IIRC é publicado apenas se for aprovado no conjunto de testes. A última vez que olhei para Junio, o mantenedor, estava executando os scripts para construí-lo regularmente manualmente, mas esses scripts podiam ser executados por integração contínua todas as noites e acredito que a Gerrit o cria automaticamente.

Então esse é o tipo de resposta. Você usa a versão mais desenvolvida em ambientes de desenvolvimento, mas usa a versão anterior para criar versões.

Com base na resposta aceita , expandirei o fluxo de trabalho de ramificação para manter ramificações semelhantes à seguinte:

• master: mescla com release-*após o fechamento
• dogfood: galhos de master; inclui correções identificadas durante a alimentação para cães; mescla a partir de developquando o software é considerado "estável" para uso interno; o chefe deste ramo pode ser movido de volta no tempo, se necessário
• develop: galhos de master; inclui mudanças contínuas, correções de bugs e mesclagens dogfoode feature-*ramificações
• feature-*: galhos de develop; inclui alterações para um novo recurso em particular
• release-*: ramifica a partir de dogfoodquando o software é considerado "estável" para uso externo; inclui atualizações de documentação e pequenas correções de erros antes da fusão commaster