Use o SVN / GIT para o histórico de versão de software? Ou alguma outra coisa?

Question

Atualmente, estou trabalhando na implementação de uma infraestrutura de versão para nossos aplicativos no negócio. Você sabe, V1.1, 1.2 etc para nossos aplicativos.

O que eu gostaria de fazer é ter uma configuração simples de alterações de software de gravação e histórico de versões. Nós já usamos o SVN (e mudamos para o GIT) e uma parte de mim apenas diz usar isso. Mas outra parte me incomoda dizendo que isso não é suficiente.

O negócio realmente não quer passar pelo nosso rebanho SVN, não é? Eu queria saber se alguém sabia de uma maneira melhor de fazer isso? Alguma sugestão?

Obrigado, Steve

    

Answer 1

Eu uso um changelog para comunicar correções de bugs, alterações ou novos recursos para usuários finais. Eu modelo meu changelog em tortoisesvn que usa BUG: CHG: NEW:.

Eu coloco linhas de changelog no histórico do repositório via commits, junto com as informações mais técnicas que entram em commits. Isso une as duas tarefas no tempo, registrando as alterações técnicas, bem como o que deve ser visível em um nível mais alto para os usuários.

Quando eu libero eu posso facilmente puxar todas as últimas linhas de changelog e atualizar o changelog / website / etc. Com os prefixos em qualquer linha de changelog no histórico de commits, eu também posso automatizá-lo.

Eu gosto de como esse método mantém os dois fluxos de informação juntos, no repositório, onde deveriam estar.

    

Answer 2

Tem sido minha experiência que as mensagens de commit geralmente contêm detalhes altamente técnicos sobre as mudanças que estão sendo cometidas. Geralmente eles não são adequados para notas de lançamento. O que eu faço é manter um documento de 'release notes' mais amigável para esse propósito. Espero passar para um sistema baseado na web como redminar que possa rastrear os aprimoramentos e os bugs.

Se as mensagens de confirmação forem boas (ou seja, não tecnicamente), há maneiras de extrair essas informações do repositório. Por exemplo, aqui está o comando que eu usei para puxar as mensagens do svn:

svn log --verbose https://<address to server>/<repo name>/ > svnMessages.txt

    

Answer 3

Você pode usar o git in house e simplesmente fazer cortes fora do repositório para versões principais (tarballs).

    

Answer 4

Eu escolheria o sistema de controle de origem que sua equipe de desenvolvimento prefere (inclinar-se para o git se ele for apático!). O que você quer é um método padrão para 'publicar' uma versão principal junto com um changelog. Isso pode ser feito com um script que faz o download do repositório e exibe o changelog, por meio de um sistema baseado na Web, pode ser apenas um diretório compartilhado na LAN, um site FTP, etc., etc.

    

Answer 5

Sua pergunta:

The Business don't really want to go through trawling our SVN repo, do they? I was wondering if someone knew of a better way of going about it? Any suggestions?

As informações extras que você forneceu:

A non-developer, maybe a member of Business from outside IT would like to know the changes that went into the last release, bug fixes etc. So you don't want to keep version history for business wide there, but maybe in a separate system

Sistema separado: Microsoft Exchange

Solução: envie-os por e-mail quando uma nova versão for lançada.

    

Answer 6

Todos os projetos em que trabalho têm um wiki para uso por desenvolvedores e usuários. O wiki é usado principalmente para documentação / ajuda, mas também inclui logs de alterações adequados para usuários finais. O log de alterações é atualizado diariamente, referindo-se ao controle de versão, se necessário, com edição final e aprimoramento quando a construção é liberada.

Muitos usuários, especialmente o pagador de contas quando trabalham remotamente, apreciam as atualizações diárias.