Qual é a melhor maneira de versão de um projeto com vários componentes

Eu tenho um programa que é composto de 5 componentes principais. Acho a numeração da versão padrão muito limitada porque gostaria de ver em qual versão cada componente está.

Alguém encontrou uma maneira fácil de fazer isso além de listar cada uma separadamente?

Temos exatamente o mesmo problema com nosso produto e decidimos fazer números de versão individuais para cada componente, e a versão do produto é apenas uma versão de marketing que é composta pelos vários componentes em uma revisão específica.

Temos uma "versão de lançamento do sistema", que é um número de versão padrão que descreve uma configuração específica de componentes e, em seguida, um arquivo separado lista as versões de componentes individuais para esse lançamento de sistema específico. Os clientes dizem 5.2.1, mas podemos procurar a compilação individual, se necessário. Normalmente, para uma versão principal, sincronizamos todas as versões individuais para que tudo seja construído a partir do mesmo número de ramificação novamente.

O controle de versão é um problema separado do desenvolvimento de aplicativos com base em componentes. Você quer versão de cada componente ou versão do aplicativo inteiro.

Um bom padrão conhecido para versionamento é da Microsoft :

major version.minor version.build number.revision

Por exemplo, você pode ver os arquivos DLL na plataforma .NET para ter versões como 2.0.3600.1 ou algo parecido.

Portanto, eu recomendo que você determine primeiro se deseja fazer a versão de todo o sistema ou de seus componentes. Se você deseja fazer a versão de todo o sistema, após cada integração, crie o projeto inteiro e aumente a parte do número da construção . Caso contrário, simplesmente faça a versão de cada componente na compilação.

Cuidado com o controle de versão, pois isso pode te matar :-) Não tente tornar as coisas muito complicadas.

Eu acho que a seguinte abordagem pode ajudá-lo:

Versão de cada componente individualmente com o esquema de versão que você deseja. Pelos seus comentários, entendo que você possui um VCS. Suponho também que cada componente tenha um arquivo em que sua versão é mantida (certo?). Uma vez por dia / semana (o que funcionar melhor para sua equipe), adicione uma tag a uma das revisões mais recentes no VCS que marque essa revisão como a revisão oficial mais recente (e, opcionalmente, aumente um número de super revisão). Agora você pode consultar o VCS para obter as revisões com essa tag e, em seguida, procurar a versão dos componentes nessa compilação oficial.

Se você quiser apenas localmente, escreva um pequeno script que agregue a versão de cada componente do local onde está armazenado no código.

Se você quiser torná-lo ainda mais sofisticado, depois de fazer a marcação, poderá ver os arquivos pertencentes a cada componente, considerando que é possível identificar os arquivos que pertencem a um componente específico. Se algum foi alterado, aumente a versão para esse componente específico. A alternativa é fazer isso manualmente. Outra alternativa é uma combinação de ramificação e fusão com o rastreamento de versão.

A maioria dos números de versão usa uma revisão principal e secundária, orientada pelo marketing, portanto, você não pode usá-las para rastrear versões de componentes individuais. Em resumo, você precisa encontrar outra parte da versão que possa ser usada para rastrear versões de componentes individuais e reservar os números de versão principais e secundários para rastrear todo o pacote.

Se você está seguindo algo semelhante ao padrão da Microsoft:

major-version.minor-version.build-number.revision

Você pode usar a revisão. Para rastrear a versão de cada componente individual e usar os números de revisão principais e secundárias para rastrear uma alteração completa do produto, da maneira usual.

Se você está seguindo um padrão semelhante a este:

Major-Version.Minor-Version.Build-Number

Você precisará usar o número da compilação para rastrear as versões individuais dos componentes.

Livros inteiros são escritos sobre software de versão.

Aqui está uma abordagem que eu uso.

Cada parte tem uma versão no formato:

major.minor.developmental

Cada um deles é um número, começando em 0.

Para uma liberação formal (ou seja, para clientes), a parte do desenvolvimento deve sempre ser 0 como uma questão de política.

Major é incrementado por decisão de marketing.

Menor é incrementado pelo lançamento de conjuntos de recursos - no mercado.

Exemplo:

• Inicio o desenvolvimento de um novo componente, portanto, o número da minha versão será 0.0.1. Ao liberar minha mesa para meus colegas, por exemplo, para testes internos, o número de desenvolvimento sobe para 0.0.2, 0.0.3 e assim por diante.

• Lancei essa novidade no mercado como 1.0.0, onde a única alteração permitida do final do desenvolvimento à versão foi alterar o número da versão (por exemplo, 0.0.43 -> 1.0.0).

• Alguns novos recursos devem ser adicionados. Começo a trabalhar na linha de base 1.0.0, adicionando esses recursos; portanto, as versões que libero para meus colegas para teste são 1.0.1, 1.0.2 e assim por diante.

• Os próximos recursos são lançados no mercado como 1.1.0.

• O marketing decide que a próxima grande novidade será realmente grande e, portanto, sairá como 2.0.0. Começo a trabalhar no 1.1.1, progredindo no 1.1.xe lançamento como 2.0.0.

E assim o ciclo se repete.

Essa abordagem, para cada componente, fornece rastreabilidade de ancestralidade.

Interno ao seu sistema de gerenciamento de revisões de origem (e objeto), use ramificações e tags (rótulos, seja qual for a sua terminologia do dia) para gerenciar o desenvolvimento.

Seu controle de revisão pode gerenciar cada componente completamente separadamente, com ramificações de desenvolvimento e rótulos / tags para cada um. Ou você pode agrupá-los todos juntos, caso em que pode desejar ramificar por pacote de trabalho - mas lembre-se de rotular / rotular a liberação de cada componente (e, quando fizer isso, rotular / rotular tudo, não apenas os bits para o Dessa forma, você tem um instantâneo do estado de tudo no momento.)

É provável que seu processo de liberação exija uma reflexão cuidadosa. O uso dessa abordagem inclui algumas etapas manuais, e isso pode ser indesejável - tudo depende de como o sistema de compilação coloca os números de versão no objeto final. Para muitos códigos incorporados nos quais os números de versão são apenas números nomeados (por exemplo, # definido no código C), você tem pouca opção a não ser fazer tudo manualmente de qualquer maneira. As plataformas de desktop com boas GUIs geralmente tornam tudo muito mais amigável.

Sumário

Para mim, a única maneira confiável de criar versão de software é usar o identificador de hash ou conjunto de alterações do seu sistema de controle de versão.

Um número de versão geral da compilação pode ser útil, mas só é realmente garantido que seja exclusivo se você tiver um servidor de compilação e / ou assinar cada release. Para muitos de nós, porém, isso simplesmente não é viável.

Se o seu projeto estiver dividido em vários repositórios de controle de versão, você também precisará criar um mecanismo pelo qual sua interface com o usuário possa consultar cada repositório dependente e reportar seu hash de volta ao usuário.

Exemplo da experiência pessoal

Em um projeto de um empregador anterior, onde tivemos problemas com o software de modificação do cliente (interno) e recompilá-lo, institui um processo pelo qual os hashes mercuriais eram compilados em cada aplicativo e biblioteca. Sempre que o software foi iniciado, uma sequência de revisões foi criada consultando todos os componentes do software.

Essa sequência de revisão foi exibida quando você foi para a página sobre e foi gravada no arquivo de log toda vez que o aplicativo foi iniciado. Era da forma:

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

A partir disso, pude ver facilmente que eles haviam modificado a Library3 e não haviam confirmado essas alterações no repositório; portanto, eles estão usando código que não é controlado. Também pude comparar os hashes com o meu sistema de teste atual, para poder identificar que eles reverteram (digamos) o Library1 para uma versão mais antiga.

Isso significava que sempre que eles relatavam um erro, eu sempre podia reconstruir exatamente o código em uso no momento em que o problema ocorreu ou, no mínimo, ter certeza de que não conseguia reproduzir a instalação.

Para obter mais detalhes do sistema de compilação que usei, como consegui isso, quais problemas tive e o que as pessoas sugeriram para evitá-los, dê uma olhada na minha pergunta do Stack Overflow .

Nota: Este sistema só é realmente viável se você usar um sistema de controle de revisão em que um determinado hash tenha a garantia de resultar no mesmo conjunto de arquivos em seu diretório de trabalho (por exemplo, git e mercurial) se um determinado diretório de trabalho puder conter uma mistura de arquivos e diretórios de várias revisões (por exemplo, svn), todas as apostas estão desativadas em relação ao estado do diretório de trabalho e esse método não funciona.