Você tem alguma políticas de compromisso?

Question

Meu chefe anunciou ontem uma nova políticas de compromisso para checkins no repositório. Essas políticas são válidas para compromissos em cabeça/tronco e galhos.
Uma mensagem de confirmação deve ter os seguintes itens:

• Razão (ID de bug, ID do projeto ou mudança não funcional)
• Nome do revisor

Após a confirmação, também precisamos criar uma entrada de blog de mudança em nosso CMS.

Não sou um grande fã dessa políticas de compromisso, porque normalmente não preciso de um revisor quando estou fazendo coisas novas ou experimentais em um ramo não produtivo.

Você tem alguma políticas de compromisso que você tem que seguir?

Eu acho que é uma boa idéia mudar o ramo produtivo apenas devido a um relatório de bugs, mas os compromissos nas filiais de desenvolvimento devem ser menos restritivos.

Answer 1

Cometer cedo e cometer frequentemente.

Na verdade, usamos /tronco como desenvolvimento e tags para ramificar diferentes lançamentos. Somente mudanças intrusivas estruturais entram /ramificações.

Usamos ativamente tags para lançamentos de produção e aceitação, para que possamos voltar no tempo facilmente. Qualquer coisa cometida no porta -malas deve ter apenas uma mensagem descrevendo o que a confirmação mudou ou adicionada brevemente.

Não sou um grande fã de usar o espaço de mensagem para vincular -se à ID de bugs, ainda requer uma pesquisa para o ID, nesse caso, você também pode procurar no software de rastreamento de bugs e fechá -lo lá, o que para mim é sobre o mesmo esforço.

Para não dizer que não gosto de nenhuma integração do SVN: - Usamos mais bondade de scripts NANT automatizados para fazer lançamentos que os ramifica em /tags - os adereços SVN realmente armazenam nossos números de versão: p. - Scripts de gancho para notificação de email e registro de mensagens (ótimo para cópias de coleta de notas de liberação).

Answer 2

Temos várias políticas, que são aplicadas através de um plug-in interno para o Visual Studio. Verificamos que os compilados de código e que os testes de unidade foram executados com sucesso. No momento, também verificamos a cobertura do código e emitimos avisos de código que não têm testes suficientes. Também fazemos várias verificações de consistência e verificamos se uma tarefa apropriada está presente em nosso sistema de gerenciamento de mudanças, a fim de fornecer rastreabilidade para todas as alterações.

A vantagem do suporte da ferramenta é ótima, pois não cabe às pessoas respeitarem as políticas, mas obviamente há uma desvantagem, assim como esses cheques levam tempo para executar. No entanto, com muitos desenvolvedores, é difícil aplicar padrões sem suporte adequado à ferramenta.

Answer 3

Um revisor parece inútil pelas razões que você mencionou, porque nem tudo precisa ser revisado por outras pessoas.

No passado, a única política de comprometimento que tínhamos (onde eu costumava trabalhar) era incluir um comentário indicando o que você mudou e por quê, mas isso é mais comum do que qualquer outra coisa.

Answer 4

Uma política de comprometimento comum é associar um ID de bug ao comprometimento do Trunk como uma justificativa. Às vezes, os sistemas de controle de versão e rastreamento de bugs são configurados para aplicar essa política.

Answer 5

Nossa política de comprometimento parece um pouco com a sua, apenas não a aplicamos nas filiais de tarefas (onde uma filial de tarefas é como a caixa de areia de um desenvolvedor para experimentar).

Nossos comentários de confirmação devem incluir um ID de controle de alteração (novo recurso, aprimoramento) ou um ID de problema (correção de bug). Você também deve incluir uma breve explicação sobre Por quê Você fez essa mudança; O controle de versão rastreia o Who, o que, quando e onde.

Answer 6

Minha mensagem de confirmação inclui uma breve descrição do que eu implementei ou alterei nas classes.

O número do bug e as descrições adicionais que coloquei na comentário acima do novo código. IDs dentro das mensagens de confirmação que colocamos quando mesclamos alterações em uma ramificação marcada.

Todas as noites, uma compilação automática verifica os diferentes recursos e produtos também, tenha certeza de que a base de código é Stabil.

Mas, no final, acho que você não pode ter muitas descrições para classes novas ou alteradas, mas muitas políticas que você precisa fazer antes de um compromisso. O nome do revisor é algo que eu não colocaria na mensagem de confirmação.

Pense nisso às vezes você precisa invadir seu código que você implementou há 2 anos. E então você está feliz com as mensagens de confirmação que não são como "Atualizar após a depuração".

Answer 7

Temos ramificações para cada versão principal lançada do software que ainda é apoiado ativamente. Verificar em qualquer um desses ramos requer um id de bug - isso é imposto por scmbug, que não apenas verificará se o comentário é prefixado pelo ID do bug, mas também procurará esse bug no banco de dados de bug, garantirá que ele seja atribuído ao componente e, potencialmente Campo é o ramo que está sendo comprometido).

Um dos produtos tem mais potencial para fracassar de maneiras embaraçosas, e a verificação disso exige não apenas um ID de bug, mas também uma revisão de código. No entanto, os critérios para a revisão do código são tratados em nosso banco de dados de bug - temos campos personalizados para isso e o bug não pode ser aceito e fechado até que ele tenha sido revisado. Para mim, isso funciona de um nível conceitual - provavelmente é melhor verificar o código que se acredita trabalhar no repositório não revisado, reabrir o bug e alterá -lo, se necessário, em vez de adiar o cometimento até que você esteja claro Está pronto para ser lançado.

Fora isso, não há política explícita para o porta -malas (embora, é claro, os princípios gerais de verificar frequentemente sem quebrar a construção, incluindo boas mensagens de comprometimento descritivo, verificando unidades de trabalho ainda se aplicam atomicamente).