estratégias de pacote e versão em um ambiente com vários repositórios

Somos uma empresa pequena, com várias equipes que gerenciam seus próprios repositórios git. Essa é uma plataforma da web e os artefatos de cada equipe são implementados no final do dia para testes noturnos. Estamos tentando formalizar o processo de versionamento e empacotamento.

Cada equipe tem um ramo principal, onde eles desenvolvem o dia-a-dia. Os membros de garantia de qualidade de cada equipe desejam que os artefatos das alterações de sua equipe sejam implantados em um local de teste onde todos os componentes são combinados pelo chef. Os artefatos são tarballs, mas gostaria de convertê-los em RPMs para que possamos pensar e raciocinar sobre as versões corretamente.

O processo de liberação envolve cortar uma ramificação de liberação da ramificação de desenvolvimento (mestre na maioria dos casos) de cada repositório git. Isso é concedido à garantia de qualidade, que executa testes e termina com um conjunto de artefatos.

Por exemplo, este é um repositório git típico com seus ramos de versão associados:

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

Estou preso tentando descobrir um esquema para executar a versão de pacotes provenientes de ramos de desenvolvimento. Não queremos marcar excessivamente a ramificação principal de cada repo e restringir as tags para liberar apenas ramificações. Mas devemos poder consultar os pacotes implementados nas máquinas de teste usando a semântica padrão yum / rpm. Como seriam as versões de desenvolvimento quando o ramo mestre não possui tags? Entendo que isso git describepode me fornecer uma representação útil de uma versão de compilação, mas que funciona bem quando vários pontos de liberação na ramificação são marcados.

EDIT1: Em resposta à resposta de @ Urban48

Eu pensei que deveria explicar um pouco mais o nosso processo de lançamento. Para os propósitos desta discussão, vamos assumir que temos ramificações masterem todos os repositórios. A masterramificação é considerada a ramificação de desenvolvimento e é implantada em um ambiente de controle de qualidade habilitado para CI-CD automatizado. É aqui que um subconjunto de testes noturnos é executado para garantir a estabilidade do mestre. Examinamos esse fluxo de trabalhos antes de cortar um ramo de lançamento. Nossos ramos de lançamento têm vida curta. Por exemplo, depois de cortar uma ramificação de liberação (de um mestre estável), uma regressão completa é executada, as correções são feitas e implementadas na produção. Isso leva cerca de uma semana para fazer. Lançamos quase a cada duas semanas para produção.

Nossas ramificações de recursos são sempre cortadas do mestre e passam por uma certa quantidade de testes do desenvolvedor antes de serem mescladas com o mestre no qual eles passam pelas verificações de estabilidade do CI-CD.

Os hotfixes são feitos em ramificações de hotfix (cortados das ramificações de lançamento) e implantados com testes de impacto mínimo na produção.

Nossa estratégia de versão para ramificações de versão e hotfix segue sempre. As ramificações de liberação durante o ciclo de controle de qualidade passam por versões como e v2.0.0-rc1, v2.0.0-rc2finalmente, após a aprovação do controle de qualidade v2.0.0.

Às vezes, fazemos lançamentos pontilhados para pequenos recursos que são mesclados para liberar ramificações (e depois dominar) onde as versões se tornam v2.1.0. E os hotfixes assumem o v2.1.1padrão.

A questão, no entanto, não é sobre a versão desses ramos. Eu preferiria não mudar completamente esse esquema de versão. A única mudança ocorre no ramo de desenvolvimento, ie. mestre. Como posso indicar de forma confiável no ambiente do CI-CD qual versão existe na versão anterior em produção. Idealmente, isso seria feito através da marcação inteligente com git, mas é preferível algo que não marque excessivamente a ramificação principal.

— tsps
fonte

por que não adicionar -rc. <build_number> às compilações dos ramos de desenvolvimento e, uma vez liberados do ramo mestre / release, use apenas um xyz?

— Urban48

O que precederia o rcsufixo? Isso ditaria a major.minorversão de desenvolvimento. rce o número da compilação pode ser obtido com base apenas nisso. Também rcno master não faz sentido, porque nunca saímos do master. Nós marcar nossos candidatos libertação hoje em ramos de libertação como parte do ciclo de lançamento

— TSPS

Entendo, então que tal não liberar de vários ramos, mas escolher recursos completos em um único ramo de lançamento, onde você pode usar tags. os pacotes de versão (rpm ou deb) se tornarão mais fáceis, tudo o que não estiver no ramo de lançamento terá um rcsufixo.

— Urban48

Respostas:

Hmm, bem, eu tenho um exemplo .net que pode ser independente da tecnologia.

Vou apenas fazer um resumo rápido.

repositório git por componente com estratégia de ramificação gitflow
todos se comprometem a desenvolver desencadear uma construção de cidade em equipe
O teamcity build altera a versão com menor manual maior + o número do build em AssemblyInfo.cs, isto é, 1.1.hotfix.build
O teamcity aciona o empacotamento de nuget usando o mesmo número de versão para as bibliotecas publicadas por nuget
o polvo implementa a construção concluída no qa para testes manuais (assumindo que todos os testes passam)
se tudo estiver bom, implante manualmente a versão na produção via polvo.

Agora, isso significa que você tem MUITOS pacotes com versão flutuando. Experimentamos o uso do sinalizador -prerelease, mas isso exigiu um pacote de movimentação manual adicional da pré-versão para a etapa 'normal' e um requisito para reconstruir os componentes que dependiam deles.

O principal é a versão de cada compilação exclusivamente por meio de um processo central.

Então você está na situação de 'hmm, quais versões eu quero' em vez de 'omg, que versão tenho?'

Editar: re comentários.

Apenas para sublinhar essa coisa realmente. Decida qual ramificação constitui o software completo e a versão que a ALL compromete. implante apenas software com versão desta ramificação.

Minha opinião, porém, é que você precisa abordar sua estratégia de ramificação.

não versão ramos de recurso (ou qualquer dev).
faça mestre de versão
use somente pacotes do master

— Ewan
fonte

Eu explorei o git-flow várias vezes no passado e, infelizmente, não consegui avançar. Alterar a estratégia de ramificação e quaisquer fluxos de trabalho git dos desenvolvedores é um problema difícil de resolver. Queremos mudar a estratégia de versão para que os números façam sentido quando implementados no desenvolvimento, teste e produção.

— tsps 23/11

Além disso, hoje temos versões nos ramos de desenvolvimento. É só que temos que marcar cada commit, às vezes duas vezes para fazer a versão dessa maneira. Gostaria de fornecer uma visão mais clara do desenvolvimento indicando que a versão atual sair é v next+ buildssemelhante à forma comogit describe

— TSPS

bem, você ainda pode construir e a versão se compromete a dominar. eles nem usam ramificações de recursos?

— Ewan

se você não quiser o mestre da versão. você precisará atualizar manualmente a versão secundária na ramificação de lançamento. que significa configurar manualmente o seu constrói toda vez que você faça uma nova farelo de liberação h

— Ewan

Os ramos de recursos existem e eu preciso aplicar versões a eles também. Não é avesso a adicionar tags / versões no master, apenas que isso é feito excessivamente hoje. Qualquer estratégia que aponta para o ponto em que posso marcar o branch master e indicam que é uma versão de desenvolvimento em oposição a versões em ramos de libertação é útil

— TSPS

Deixe-me oferecer um fluxo de trabalho alternativo, que pode resolver seu problema de controle de versão ou apenas ajudá-lo a pensar em mais maneiras de encontrar a solução.

Um pouco de filosofia primeiro ..
(Estou fazendo algumas suposições sobre o seu fluxo de trabalho, por favor, corrija-me se estiver errado)

Os testes são executados retroativamente :

Ramifique para destacar masera ramificação e, em seguida, transforme-o em um artefato para teste pelo controle de qualidade.
o problema é : e se os testes falharem, masterpodem ser quebrados!

efeitos colaterais:
- Faz com que os desenvolvedores não confiem master
- Como você sai do mestre para liberar ramificações, o que acontece se a liberação anterior for interrompida? ele interrompe a integração do novo recurso até que o mestre seja corrigido novamente.
- quando o bug é corrigido no ramo de lançamento, mesclar novamente para mastercriar conflitos de mesclagem. (e não gostamos de conflitos)
código pequeno mescla e corrige :

É difícil acompanhar todo o código mesclado master, como pequenas correções ou alterações que não fazem parte de um determinado recurso.

efeitos colaterais:
- O desenvolvedor não tem certeza se deve alterar essa pequena correção agora ou mais tarde.
- devo versão também esta nova pequena correção?
- A qualquer momento, não está claro qual é o estado da masterramificação e qual código está flutuando lá
- algo quebrou a compilação, que não faz parte do novo recurso. e é realmente difícil rastrear de onde veio

Minha ideia para o fluxo de trabalho do git é a seguinte:

ramificar para o desenvolvimento de masternovos recursos, como você já faz. mas agora, em vez de liberar-se desse ramo recém-criado, faça com que esse recurso seja escolhido e mesclado no releaseramo.

Agora você tem melhor controle sobre o que está entrando em um determinado lançamento.
Agora é realmente fácil isolar versões de desenvolvimento e versões estáveis.

Você pode continuar criando artefatos a partir dessas ramificações de recursos para o controle de qualidade.
Se tudo estiver ok, mescle esse recurso novamente mastere escolha esse recurso / correção de bugs / hot-fix no ramo de lançamento.

versionamento
A versão dos ramos de recursos pode usar alguma convenção de nome como1.2.3-rc.12345

as versões no releaseramo usarão apenas 1.2.3 ( 1.2.3> 1.2.3-rc.12345também menos uma coisa com que se preocupar)

Esse fluxo de trabalho corrige os problemas mencionados acima e muito mais.
Ele também propõe uma estratégia de versão sã, e a maior parte desse ciclo de lançamento pode ser automatizada.

Espero que isso ajude você de alguma forma, discutirei com prazer quaisquer casos extremos que você possa apresentar.

ps:
peço desculpas pelo meu inglês, não é o meu idioma principal.

— Urban48
fonte

Obrigado pela sua resposta detalhada. Responderei na postagem original como EDITs, pois a barra de comentários não permite texto suficiente.

— tsps

Seu processo parece muito complicado e a obtenção de um número pequeno de tags parece inevitável.

Duas idéias vêm à mente:

Você trata o ramo "mestre" como o que normalmente temos no ramo "desenvolvimento". Isso polui muito o ramo da mensagem.
Quando o controle de qualidade termina o trabalho, você pode ter o servidor de criação / IC para criar um relatório (por exemplo, um arquivo de texto) com as tags de todos os repositórios em uso. Agora você terá um arquivo com as versões que podem ser postadas no repositório. Em seguida, você marca a ramificação apenas com a versão de lançamento e, se desejar verificar as versões dos componentes individuais, poderá verificar o relatório.

— John Kouraklis
fonte