Para integrar versões do git como números de compilação ou não?

Um colega e eu nos revezamos debatendo / discutindo os problemas / méritos da integração de uma versão derivada do atual repositório git em nosso código sempre que ele é compilado.

Acreditamos que os méritos incluem:

• Não há necessidade de se preocupar com erros humanos na atualização de um número de versão
• Rastreabilidade entre o que encontramos em um dispositivo e o código fonte do qual foi derivado

Os problemas que surgiram (para nós) incluem:

• Os sistemas de compilação derivados do IDE (por exemplo, MPLABX) podem dificultar a identificação de onde colocar esses tipos de ganchos (e, no final, pode acabar sendo bastante brega)
• Mais trabalho para realmente integrar isso nos scripts / makefiles de construção
• O acoplamento a uma abordagem de compilação específica (por exemplo, e se uma pessoa compilar com o XCode e a outra MPLABX) pode criar surpresas posteriores

Portanto, estamos curiosos sobre onde outros chegaram a esse debate. É realmente fácil para a discussão se tornar anedótica. Existem muitas pessoas que insistem em automação de ponta a ponta, penduram a quantidade de trabalho inicial e o acoplamento que ele cria. E há muitos outros do outro lado do debate, que apenas fazem a coisa mais fácil que funciona e convive com os riscos.

Existe uma resposta fundamentada para qual lado é melhor aterrar?

Usamos git description com tags de versão. O fluxo é basicamente:

• crie uma tag para a versão em que estamos trabalhando (por exemplo, v1.1.2)
• toda execução de compilação git describe
• quando enviarmos, use o nome da tag

git describefornece o nome da tag, o número de confirmações desde a tag e o hash da tag. Um exemplo de tag é semelhante a:

v1.1.2-6-a3b27gae

Isso tem o benefício de que os desenvolvedores obtenham hashes; portanto, se algo acontecer entre as compilações, o desenvolvedor poderá diferenciar facilmente as alterações. Também é estúpido e simples de gerenciar; peça ao líder da equipe que crie e envie a tag para uma nova ramificação de correções de erros, e seu sistema de compilação cuida do resto.

Nós removemos o hash (e o número da compilação) porque facilita para os usuários entender nossos números de versão. Descobrimos que isso nos dá o melhor dos dois mundos, enquanto ainda fornecemos informações relevantes suficientes ao projetar uma versão.

Atualmente, temos uma versão um pouco mais complicada disso, mas a idéia permanece.

Nós costumávamos ser uma loja do SVN, então essa matemática era fácil - o número de compilação era a rev. Do SVN e era isso. Tentamos continuar assim quando começamos a mudar para DCVSes e descobrimos que ela falhou por alguns motivos.

Primeiro, quem sabe se a rev 69bc333bc8d8 é anterior, posterior ou simultânea à rev 25b0f0d1052c? Há muito pouco contexto em comparação com o sistema SVN quando você pelo menos sabia que 101 estava depois de 100. Segundo, a natureza do controle de fonte DCVS torna as coisas não lineares de várias maneiras quando as construções subseqüentes podem não estar avançando na mesma esfera.

Finalmente decidimos usar um servidor de compilação para distribuir números de compilação às coisas, pois ele tinha a visibilidade e a capacidade corretas de lidar com isso.

Eu uso o esquema a seguir para um sistema de criação do Visual Studio de uma DLL C # para gerar automaticamente números de versão (historicamente, tivemos problemas com implantações que não estavam sendo executadas corretamente; portanto, era necessária uma maneira limpa de garantir a implantação da versão correta).

• Principal - codificado 1, geralmente determinado pelo lado comercial
• Menor - Codificado 0, geralmente determinado pelo lado comercial
• Revisão - Número de dias desde 1º de janeiro de 2010 (ou qualquer outra data de início arbitrária)
• Build - Metade do número de segundos desde a meia-noite (já que é um número não assinado de 16 bits)

Observe que isso pressupõe que você tenha 2 números não assinados e fungíveis de 16 bits para brincar. A criação de um sistema equivalente que utiliza números menores também pode ser feita.

Observe também que os campos não numéricos podem ser úteis se você puder anexá-los como metadados. Por exemplo, adicionando o número da versão git como o número da versão informativa.

Estou vinculando diretamente a saída do status git, log e diff no executável. Depois, há uma opção para imprimir isso. A vantagem é que você não é apenas capaz de descobrir de qual ramificação seu binário foi construído, mas também quais alterações de código fonte não confirmadas estão incluídas. Por favor, veja:

https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state

Você deve poder usar esses 3 arquivos para criar sua própria coisa de lib de estado do SCM.

Eu recomendaria o uso da Autorevision .

Você pode obter saída em diversos formatos, por exemplo, um cabeçalho no estilo c .

Existem também alguns exemplos (no diretório contribs) de como você pode conectar as coisas para que, independentemente de quem esteja construindo e de como esteja fazendo, elas sempre obtenham as mesmas informações de versão, mesmo que estejam construindo a partir de um tarball.

Além disso, uma vez que, além do gitAutorevision, trabalha svne hgfacilita o afastamento do svn sem precisar mudar muito depois que você o configurar.