Estratégia de controle de versão ágil

DevOpsNet.
Random DevOps Ramblings.
Estratégia de versão de compilação.
Ao longo dos últimos anos, segui uma estratégia de versão de compilação do seguinte formato:
O uso de pontos decimais nos permite implementar uma estratégia de auto-incremento para nossas construções, o que significa que o ID de compilação não precisa ser alterado manualmente sempre que produzimos uma compilação, pois isso é feito pelo sistema de compilação. Tanto Maven quanto Ant têm métodos simples de incrementar esse número.
Garantir que cada compilação tenha um número de versão exclusivo (ao incrementar o ID de compilação) nos permite distinguir entre compilações, uma vez que nenhuma compilação do mesmo projeto terá o mesmo ID de compilação. Os outros números são alterados manualmente, quando necessário.
Versão principal - Normalmente, muda quando há mudanças muito grandes no produto ou no projeto, como após uma reescrita ou uma mudança significativa na funcionalidade.
Release Version - Incrementado quando existe um lançamento oficial de um projeto que não é considerado uma alteração na versão principal. Por exemplo, podemos planejar lançar um projeto para um cliente em 2 ou 3 versões separadas. Esses lançamentos podem representar a mesma versão principal (digamos, versão 5), mas ainda gostaríamos de identificar o fato de que estes são lançamentos planejados subsequentes, e não os patches.
Número do Patch - Isto indica um patch para uma versão existente. O lançamento que está sendo corrigido é refletido na Versão de lançamento. Normalmente, um patch é emitido para corrigir um erro crítico ou uma coleção de problemas importantes e, como tal, é diferente de uma versão "planejada".
ID de compilação - Este auto-incrementos com cada compilação de versão no sistema CI. Isso garante que cada compilação tenha um número de versão exclusivo. Quando a versão principal, versão de versão ou número de patch é aumentada, o ID de compilação é redefinido para 1.
17.23.0.9 - Isto representa a versão 17.23. É a 9ª versão desta versão.
17.24.0.1 - Esta é a próxima versão, versão 17.24. Esta é a primeira versão do 17.24.
17.24.1.2 - Isso representa um patch para a versão 17.24. Esta é a primeira versão do patch, e é a 2ª compilação desse patch.
Compartilhar isso:
Relacionados.
Pós-navegação.
3 comentários.
Eu acho que você deveria trocar o patch e os números de compilação & # 8211; apenas a minha preferência pessoal.
& # 8220; acho que você deve trocar o patch e os números de compilação - apenas minha preferência pessoal. & # 8221;
Pense nisso, 1 patch pode demorar algumas construções antes de passar em todos os ambientes, (oh dispare, trabalhou para jetty, mas não websphere, configure o X e reconstrua!), Mas é (assumindo qualquer processo CI real) uma impossibilidade de ter o O mesmo número de compilação ocorre mais de uma vez.
então 1.0.0.b1 e 1.0.0.b2 podem ocorrer, e parece legal.
1.0.b1.0 e 1.0.b2.0 parece bobo, e 1.0.b1.0 e 1.0.b1.1 nunca devem acontecer.

Estratégia de versão ágil
Obter através da App Store Leia esta publicação em nosso aplicativo!
Versionamento semântico em Agile.
Digamos que eu tenho 14 dias de iteração de sprint, onde eu tenho várias histórias para novos recursos, poucas melhorias e alguns erros para consertar. Eu também implanto essas mudanças quando estão prontas, eu não estou aguardando o fim do sprint.
Meu problema é - como controlar o controle de versão semântico de produtos desenvolvidos e mantidos assim? Se houver lançamento a cada 14 dias, será fácil, aumentarei o número da versão e anotarei todas as alterações no changelog. Mas e se as mudanças forem implantadas de forma contínua? Deveria haver uma versão aumentada sempre que algo for implantado? Ou devo esperar até que Sprint termine e depois disso, faça algum "currículo" e aumente o número da versão apenas uma vez por iteração de forma independente na implantação real? Quais são as melhores práticas para o controle de versão semântico no Agile?
EDITAR: Para melhor explicar minhas necessidades, eu quero uma mudança para as partes interessadas em primeiro lugar. Eu não acho que eles estarão interessados ​​em novo registro em changelog após cada mudança implantada.
Para o gerenciamento de lançamento típico, você quer que um número de compilação seja gerado pelo seu sistema de compilação para que as DLLs sejam versionadas sempre que forem implantadas. Isso garantirá que você poderá verificar a versão que é implantada em um determinado servidor.
Sua versão de "marketing", que geralmente é colocada em notas de versão ou publicada em seu site, não deve ser atualizada em cada versão. Essas notas de lançamento devem ser acumuladas e agrupadas, provavelmente programadas com o final do seu sprint.
Se o clássico esquema de versão semântica "MAJOR. MINOR. PATCH" faz sentido, depende de quem você implantar e, especialmente, quando e com que frequência você se implanta para o usuário final. O esquema é mais útil se você trabalhar com versão estável "4.5", onde você começa com 4.5.0. As versões 4.5.1, 4.5.2, e assim por diante, contêm apenas correções de bugs, enquanto você internamente já trabalha na versão 4.6.
Por exemplo, se você fornecer um "ramo estável" ao seu usuário final, dê uma versão 4.5.0 para a implantação inicial e 4.5.1, 4.5.2 sempre que você liberar um patch. No seu desenvolvimento interno "ágil" e na implementação do meio do sprint, você já pode ter uma versão 4.6, basta chamá-la de "versão beta". Sempre que você o implanta no meio do sprint, adicione o número de compilação gerado automaticamente como "4.6.beta build 123". Quando o seu sprint termina, atribua-o "4.6.0" e mude o número da versão para o próximo sprint internamente para "4.7". Começar com ".0" é apenas uma convenção, você também pode usar o ".0" para etiquetar versões beta e começar com ".1" para seus usuários finais. IMHO a palavra "beta" é muito mais expressiva, dizendo a todos que o sprint "ainda não está completo".
Se você liberar um registro completo de alterações do usuário final com cada versão beta depende de você, mas pelo menos no final do sprint, o log de alterações deve ser concluído e sempre que você fornecer um bugfix ao usuário final, você também deve atualizar os documentos de histórico.
Você encontrará a estratégia de liberar dois ramos separados, um ramo "estável" com números de versão semântica e um "ramo de desenvolvimento" marcado com números de compilação ou algo similar, em muitos produtos de código aberto como o Inkscape, o Firefox ou o 7-zip.
Se, no entanto, você não trabalha com estações estáveis ​​e de desenvolvimento separadas, e divulgue diariamente uma nova versão ao usuário final, você também deve incrementar um número de versão diariamente. Para tal caso, os números de versão "4.5.1", "4.5.2",. provavelmente refletirá suas implantações individuais e não indicará a diferença entre correções de erros e outras alterações. Isso pode estar certo, não é mais o "controle de versão semântico" clássico. Nesse cenário, você também pode implantar versões 4.5, 4.6, 4.7, 4.8, que não dá nenhuma diferença real.
No que diz respeito à sua pergunta sobre as entradas no seu changelog: IMHO quando algo é visível para o usuário final, vale a pena uma entrada no changelog, assim que você implantar a alteração. Por exemplo, se você usar alternar recursos e fazer alterações em algum recurso meio cozido que ainda não esteja ativado para o usuário, isso não pertence a um changelog. Se você fizer apenas refatoração, sem alteração visível para o usuário, isso não pertence a um changelog. Se você corrigir um bug que poderia ter afetado alguns usuários, isso pertence definitivamente ao changelog - e deve ser mencionado lá ao mesmo tempo em que você implanta o bugfix. E não importa se você liberar diariamente, mensalmente ou anualmente.
Eu usaria números de compilação. Normalmente, um número de compilação corresponderia à versão mais alta do sistema de controle de versão. Se o número de compilação das segundas-feiras era 1745 e verificou-se 5 mudanças durante a terça-feira, o número de construção das noites de terça-feira seria 1750.
Em seguida, faça um breve resumo do que mudou entre 1745 e 1750.
Então, toda vez que você atualiza o número da versão do seu sistema, você pode adicionar todos os resumos curtos das compilações para obter as alterações do último número da versão para o novo.
O método preferido que usei há pelo menos alguns anos agora é superar o número após a conclusão de cada história. Isto significa que as versões lançadas no final do sprint não serão contínuas, p. Depois de 1.2.3 você pode encontrar 1.5.2 em vez de 1.4.0.
No changelog você pode listar as versões intermediárias com suas descrições correspondentes ou apenas agrupar todas as mudanças na versão "lançada" e ignorar as versões no meio.
Inicialmente, eu estava com medo de que os usuários achassem os "buracos" entre os números de versão problemáticos, mas uma vez que eles sabem sobre isso, não é um problema na prática. A grande vantagem é que aumentar o número após cada história torna o processo menos propenso a erros - você não precisa verificar todo o trabalho a partir de 2 semanas para decidir qual será o próximo número de versão - ao olhar para uma única história, é óbvio . Além disso, os "saltos" em números de versão entre cada versão dão uma estimativa aproximada de quantas mudanças entraram no lançamento. No geral, eu achei que este sistema funcionou bem (isto foi com clientes internos da empresa, mas se você já trabalha em um ciclo de liberação ágil, ele também deveria funcionar para clientes externos).

Estratégias de ramificação com TFVC.
Neste artigo.
VSTS | TFS 2018 | TFS 2017 | TFS 2018 | VS 2017 | VS 2018 | VS 2018.
Você planeja adotar Team Foundation Version Control (TFVC) e está se perguntando como usar melhor as filiais? Não aprofundaremos as características de ramificação, pois estão bem documentadas na documentação e orientação do produto, mas exploraremos algumas estratégias de ramificação comuns para ajudá-lo a tomar a decisão certa.
Ao contrário dos ramos Git, que são repositórios escopo, os ramos TFVC são escopo do caminho e não como peso leve. Defina sua barra para criar ramos altos, para evitar o gerenciamento necessário para acompanhar ramos, recursos de armazenamento e resolução de conflitos de mesclagem. Considere ramificação somente se você tiver várias equipes trabalhando na mesma base de código ou precisar de isolamento para desenvolvimento ou lançamento.
A estratégia Main Only pode ser baseada em pastas ou com a pasta principal convertida em Branch, para permitir recursos adicionais de visibilidade. Você compromete suas alterações no ramo principal e, opcionalmente, indica os marcos de desenvolvimento e lançamento com rótulos.
RISCO: a mutabilidade e a falta de histórico com rótulos TFVC podem aumentar o risco de controle de mudanças.
Comece com a principal estratégia de ramificação, faça um ramo estrategicamente e adote outras estratégias para evoluir para estratégias mais complexas, conforme necessário.
Isolamento do desenvolvimento.
Quando você precisa manter e proteger um ramo principal estável, você pode ramificar um ou mais ramos de desenvolvimento do principal, dando-lhe isolamento e desenvolvimento simultâneo. O trabalho pode ser isolado em ramificações de desenvolvimento por recurso, organização ou colaboração temporária.
As mudanças feitas no ramo principal, devem ser integradas para a frente (FI) para o ramo dev e os conflitos de mesclagem foram resolvidos, antes que as alterações sejam revertidas (RI) de volta ao main. Para manter a mesma barra de qualidade em filiais, sempre crie e execute testes de verificação de compilação (BVTs) no dev da mesma forma que você está fazendo no main. Opcionalmente, combine esta estratégia de ramificação com outras estratégias aqui abrangidas.
NOTA: Com esta estratégia, é provável que as equipas mantenham o desenvolvimento do desenvolvimento em torno de sempre, potencialmente construindo um grande histórico de tickets de mesclagem.
Isolamento de características.
O isolamento de recursos é uma derivação especial do isolamento do desenvolvimento, permitindo que você ramifique um ou mais ramos de recursos da principal, como mostrado, ou de seus ramos de dev.
Quando você precisa trabalhar em um recurso particular, pode ser uma boa idéia criar um ramo de recursos.
Você deve manter a vida útil do recurso e o ramo de recurso associado de curta duração. A integração direta (FI) muda do ramo pai com freqüência, mas inverte a integração (RI) de volta para o pai somente quando alguns critérios de equipe acordados, por exemplo, definição de feito, são atendidos. A recuperação dos recursos no main pode ser dispendiosa e pode reiniciar o teste.
Liberar o isolamento.
O isolamento de lançamento introduz um ou mais ramos de liberação do principal, permitindo o gerenciamento de lançamento simultâneo, lançamentos múltiplos e paralelos e instantâneos precisos da sua base de código ao tempo de liberação.
Quando sua base de código possui o primeiro candidato a liberar ou a versão está pronta para ser bloqueada, pode ser um bom momento para criar um novo ramo para a versão.
Nunca encaminhe integrar (FI) dos ramos de lançamento principal e de bloqueio usando permissões de acesso, para evitar modificações não intencionais em uma versão. Os remendos e correções rápidas feitas no ramo de liberação podem ser integrados de forma reversa (RI) de volta ao ramo principal.
NOTA: Nenhum dos cenários de ramificação é imutável, razão pela qual você percebe os hotfixes de emergência executados em ramos de lançamento. Evolua cada estratégia para combinar com seus requisitos, sem perder de vista a complexidade e o custo associado.
Manutenção e liberação de isolamento.
A estratégia de manutenção e isolamento de lançamento introduz os ramos de manutenção, permitindo o gerenciamento simultâneo de serviços de service packs e instantâneos precisos da base de código no serviço e tempo de liberação.
Considere esta estratégia se você precisar de um modelo de manutenção para que os clientes atualizem para a próxima versão principal e pacotes de serviço adicionais por versão.
Como o isolamento do lançamento, os ramos de isolamento e liberação de serviço são criados quando a versão está pronta para ser bloqueada. Nunca encaminhe integrar de main para manutenção, nem de manutenção para liberação, e bloquear o ramal de liberação para evitar modificações. Alterações no serviço futuro podem ser feitas no ramo de manutenção.
Crie novos ramos de manutenção e lançamento para lançamentos subseqüentes, se você precisar desse nível de isolamento.
Manutenção, Hotfix, Liberação de isolamento.
Embora não seja recomendado, você pode continuar evoluindo as estratégias, introduzindo ramos de hotfix adicionais e cenários de lançamento associados.
Neste ponto, você explorou com sucesso alguns dos cenários de ramificação TFVC comuns. Você pode evoluí-los ou investigar outras estratégias, como ativação e desativação de recursos, para determinar se um recurso está disponível em tempo de execução.
Por que os ramos devem ser de curta duração?
Ao manter os ramos de curta duração, os conflitos de fusão são mantidos ao menor número possível.
Por que apenas ramo se for necessário?
Para abraçar o DevOps, você precisa confiar na automação de compilação, teste e implantação. A mudança é contínua, freqüente e combina operações mais desafiadoras, pois os conflitos de mesclagem geralmente requerem intervenção manual. Recomenda-se, portanto, evitar a ramificação e confiar em outras estratégias, como a alternância de recursos.
Por que remover ramos?
Seu objetivo deve ser obter as mudanças de volta ao principal o mais rápido possível, para mitigar as consequências da fusão de longo prazo. Os ramos temporários, não utilizados e abundantes causam confusão e despesas gerais para o time.
Pode uma base de código ser ramificada em projetos de equipe?
Sim, mas não é recomendado, a menos que as equipes compartilhem fonte e não compartilhem um processo comum.
E a estratégia de promoção do código?
A estratégia de promoção do código parece uma relíquia da era do desenvolvimento da cachoeira. É tipicamente com ciclos de testes longos e equipes separadas de desenvolvimento e teste. A estratégia já não é recomendada. Consulte a orientação de ramificação para obter mais informações.
Ao fundir o dev para o ramo principal, por que as alterações não são detectadas?
Você provavelmente ignorou as alterações em mesclagens anteriores, por exemplo, usando a opção de manter a resolução de conflito de origem. Consulte fusão do ramo de desenvolvimento para principal: não houve alterações para fundir detalhes.
Existem semelhanças entre estratégias TFVC e Git?
A estratégia de ramificação do Isolamento de Recursos do TFVC é semelhante aos ramos do tópico Git.
Autores: Jesse Houwing, Marcus Fernandez, Mike Fourie e Willy Schaub.
(c) 2018 Microsoft Corporation. ÃїTodos os direitos reservados. Este documento é fornecido "como está". & quot; Informações e opiniões expressas neste documento, incluindo URL e outras referências de sites da Internet, podem mudar sem aviso prévio. Você corre o risco de usá-lo.
Este documento não fornece qualquer direito legal a qualquer propriedade intelectual em qualquer produto da Microsoft. Você pode copiar e usar este documento para fins internos de referência.

O recurso abre caminho para a grandeza.
Ou tarefa que se ramifica para lá. Ou liberar ramificações. Você escolhe.
Quase todos os sistemas de controle de versão hoje oferecem suporte a ramos e ndash, linhas de trabalho independentes que decorrem de uma base de código central. Dependendo do seu sistema de controle de versão, o ramo principal pode ser chamado de mestre, mainline, padrão ou tronco. Os desenvolvedores podem criar seus próprios ramos da linha principal do código e trabalhar de forma independente ao lado dele.
Por que se preocupar com a ramificação?
O Branching permite que equipes de desenvolvedores colaborem facilmente dentro de uma base de código central. Quando um desenvolvedor cria um ramo, o sistema de controle de versão cria uma cópia da base de código naquele momento. As mudanças na filial não afetam outros desenvolvedores no time. Isso é uma coisa boa, obviamente, porque os recursos em desenvolvimento podem criar instabilidade, o que seria altamente perturbador se todo o trabalho estava acontecendo na linha principal do código. Mas os ramos não precisam viver em confinamento solitário. Os desenvolvedores podem facilmente reduzir as mudanças de outros desenvolvedores para colaborar em recursos e garantir que seus ramos privados não se divertem muito do mestre.
Os ramos não são bons para o trabalho de recurso. Os ramos podem isolar o time de mudanças arquitetônicas importantes, como atualizações, bibliotecas comuns, etc.
Três estratégias de ramificação para equipes ágeis.
Os modelos de ramificação geralmente diferem entre equipes e são objeto de muito debate na comunidade de software. Um grande tema é a quantidade de trabalho que deve permanecer em um ramo antes de ser incorporado de novo ao mestre.
Liberação de ramificação.
A ramificação de lançamento refere-se à idéia de que uma versão está inteiramente contida em um ramo. Isso significa que, no final do ciclo de desenvolvimento, o gerente de lançamento criará um ramo do mestre (por exemplo, & ldquo; 1.1 ramo de desenvolvimento & rdquo;). Todas as alterações para a versão 1.1 devem ser aplicadas duas vezes: uma vez para o ramo 1.1 e, em seguida, para a linha do código mestre. Trabalhar com dois ramos é trabalho extra para a equipe e é fácil esquecer de fundir os dois ramos. Os ramos de liberação podem ser difíceis de manejar e difíceis de gerenciar, pois muitas pessoas estão trabalhando no mesmo ramo. Nós sentimos a dor de ter que combinar muitas mudanças diferentes em um único ramo. Se você deve fazer um ramo de lançamento, crie o ramo o mais próximo possível da versão real.
A ramificação de lançamento é uma parte importante do suporte de software versionado no mercado. Um único produto pode ter vários ramos de libertação (por exemplo, 1.1, 1.2, 2.0) para suportar o desenvolvimento de sustentação. Tenha em mente que as mudanças em versões anteriores (ou seja, 1.1) podem precisar ser mescladas para ramos de liberação posteriores (ou seja, 1.2, 2.0). Confira nosso webinar abaixo para saber mais sobre como gerenciar os ramos de lançamento com o Git.
Característica ramificação.
Os ramos de recursos geralmente são acoplados com bandeiras de recurso e ndash; & quot; toggles & quot; que permitem ou desativam um recurso dentro do produto. Isso facilita a implantação do código em mestre e controle quando o recurso é ativado, facilitando a implantação do código antes do recurso ser exposto aos usuários finais.
Outro benefício das bandeiras de recursos é que o código pode permanecer dentro da compilação, mas inativo enquanto ele está em desenvolvimento. Se algo estiver errado quando o recurso estiver ativado, um administrador do sistema pode reverter o sinalizador de recurso e voltar para um bom estado conhecido em vez de ter que implantar uma nova compilação.
Ramificação de tarefas.
Na Atlassian, nos concentramos em um fluxo de trabalho de ramificação por tarefa. Toda organização tem uma maneira natural de quebrar o trabalho em tarefas individuais dentro de um rastreador de problemas, como o Jira Software. As questões então se tornam o ponto central de contato da equipe para esse trabalho. A ramificação de tarefas, também conhecida como ramificação de problemas, conecta diretamente esses problemas com o código-fonte. Cada questão é implementada em seu próprio ramo com a chave de problema incluída no nome da filial. É fácil ver qual código implementa qual questão: basta procurar a chave de problema no nome do ramo. Com esse nível de transparência, é mais fácil aplicar mudanças específicas ao mestre ou qualquer ramo de lançamento legado em execução.
Desde centros ágiles em torno de histórias de usuários, os ramos de tarefas parecem bem com o desenvolvimento ágil. Cada história de usuário (ou correção de bugs) vive dentro de seu próprio ramo, facilitando a visão de quais problemas estão em andamento e estão prontos para serem lançados. Para um mergulho profundo em uma ramificação de tarefas (às vezes chamado de ramificação de problemas ou ramificação por questão), pegue algumas pipocas e confira a gravação do webinar abaixo do & ndash, um dos nossos mais populares de todos os tempos.
Agora conheça o gêmeo malvado da ramificação: a fusão.
Todos nós sofremos a dor de tentar integrar vários ramos em uma solução sensata. Tradicionalmente, sistemas de controle de versão centralizados como o Subversion fizeram uma operação muito dolorosa. Mas os sistemas de controle de versões mais recentes, como o Git e o Mercurial, tomam uma abordagem diferente para rastrear versões de arquivos que vivem em diferentes ramos.
Os ramos tendem a ser de curta duração, tornando-os mais fáceis de fundir e mais flexíveis em toda a base do código. Entre a capacidade de mesclar freqüentemente e automaticamente os ramos como parte da integração contínua (CI), e o fato de que os ramos de curta duração simplesmente contêm menos mudanças, "fundir o inferno" torna-se uma coisa do passado para equipes usando Git e Mercurial.
Isso é o que faz a ramificação de tarefas tão incrível!
Validar, validar, validar.
Um sistema de controle de versão só pode ir tão longe em afetar o resultado de uma fusão. Testes automatizados e integração contínua também são críticos. A maioria dos servidores CI pode automaticamente colocar novos ramos em teste, reduzindo drasticamente o número de "surpresas" na junção final a montante e ajudando a manter a linha principal do código estável.
A Agile teve um enorme impacto sobre mim tanto profissional como pessoalmente, como eu aprendi, as melhores experiências são ágeis, tanto no código como na vida. Muitas vezes, você me encontrará na interseção de tecnologia, fotografia e motociclismo. Encontre-me no Twitter! @danradigan.
Inscreva-se para mais artigos.
Obrigado por inscrever-se!
Como fazer scrum com o Jira Software.
Um guia passo a passo sobre como conduzir um projeto de Scrum, priorizar e organizar seu backlog em sprints, executar cerimônias Scrum e muito mais, tudo dentro do Jira Software.
Git se ramifica para equipes ágeis.
Mudar para o Git abre um novo nível de agilidade para equipes de software. Aqui é como projetar esquemas de ramificação para envio tanto SaaS quanto produtos instalados.

Estratégia de versão de compilação.
Junte-se à comunidade DZone e obtenha a experiência dos membros completos.
O Nexus Suite é projetado exclusivamente para um mundo nativo do DevOps e cria valor no início do pipeline de desenvolvimento, fornece controles contextuais precisos em todas as fases e acelera a inovação do DevOps com a automação em que você pode confiar. Leia como neste ebook.
Nos últimos anos, segui uma estratégia de versão de compilação do seguinte formato:
O uso de pontos decimais nos permite implementar uma estratégia de auto-incremento para nossas construções, o que significa que o ID de compilação não precisa ser alterado manualmente sempre que produzimos uma compilação, pois isso é feito pelo sistema de compilação. Tanto Maven quanto Ant têm métodos simples de incrementar esse número.
Garantir que cada compilação tenha um número de versão exclusivo (ao incrementar o ID de compilação) nos permite distinguir entre compilações, uma vez que nenhuma compilação do mesmo projeto terá o mesmo ID de compilação. Os outros números são alterados manualmente, quando necessário.
Versão principal - Normalmente, muda quando há mudanças muito grandes no produto ou no projeto, como após uma reescrita ou uma mudança significativa na funcionalidade.
Release Version - Incrementado quando existe um lançamento oficial de um projeto que não é considerado uma alteração na versão principal. Por exemplo, podemos planejar lançar um projeto para um cliente em 2 ou 3 versões separadas. Esses lançamentos podem representar a mesma versão principal (digamos, versão 5), mas ainda gostaríamos de identificar o fato de que estes são lançamentos planejados subsequentes, e não os patches.
Número do Patch - Isto indica um patch para uma versão existente. O lançamento que está sendo corrigido é refletido na Versão de lançamento. Normalmente, um patch é emitido para corrigir um erro crítico ou uma coleção de problemas importantes e, como tal, é diferente de uma versão "planejada".
ID de compilação - Este auto-incrementos com cada compilação de versão no sistema CI. Isso garante que cada compilação tenha um número de versão exclusivo. Quando a versão principal, versão de versão ou número de patch é aumentada, o ID de compilação é redefinido para 1.
17.23.0.9 - Isto representa a versão 17.23. É a 9ª versão desta versão.
17.24.0.1 - Esta é a próxima versão, versão 17.24. Esta é a primeira versão do 17.24.
17.24.1.2 - Isso representa um patch para a versão 17.24. Esta é a primeira versão do patch, e é a 2ª compilação desse patch.
A Zona DevOps é trazida a você em parceria com o Sonotype Nexus. Veja como a plataforma Nexus infunde a inteligência precisa do componente de código aberto no encanamento DevOps cedo, em todos os lugares e em escala. Leia como neste ebook.
Como esse artigo? Leia mais do DZone.
Free DZone Refcard.
DevOps para banco de dados.
Publicado em DZone com permissão de James Betteley, DZone MVB. Veja o artigo original aqui.
As opiniões expressas pelos contribuidores da DZone são próprias.