Estratégia de versão de Java

Obter através da App Store Leia esta publicação em nosso aplicativo!
Uma boa estratégia para implementar um sistema de versão.
Eu tenho lutado com o software de versão por um tempo agora. Eu não estou falando sobre uma convenção de nomenclatura, estou falando sobre como realmente aplicar uma versão em um sistema de compilação até o final de uma versão.
Eu geralmente uso major. minor. maintenance - [release type], ou seja, 1.0.2-rc1.
O problema é gerenciar o número da versão. Eu tentei muitas maneiras (colando-o em um arquivo de compilação, um arquivo de propriedades, um banco de dados, etc., etc.), mas não encontrei nada que realmente funcione bem.
Pergunto-me se alguém tem boas ideias sobre isso. Além disso, perguntando-se como as pessoas lidam com a liberação de uma versão. ou seja, se eu liberar / implantar a versão 1.0.0-rc1, os erros encontrados nesta versão, então, faça o login no 1.0.0 (a próxima versão de produção).
A Microsoft usa & lt; major & gt;. & Lt; minor & gt;. & Lt; patch & gt; - & lt; build number & gt; (ou uma variação).
Eu gosto de usar & lt; major & gt;. & Lt; minor & gt;. & Lt; buildnumber & gt;
Onde eu estou trabalhando, usamos o sistema Maven: artefato [-major-menor-revisão] [- INSTANTÂNEO] que nos permite desenvolver versões "em andamento" que mudam em um momento de aviso (SNAPSHOT) e aqueles que foram lançados formalmente . Alguns exemplos são:
-services-1.0.0-SNAPSHOT. jar - web-2.3.11.war crm-2.5.0.ear.
Se tiver SNAPSHOT nele, não passou o conjunto completo de testes ou é apenas uma experiência de desenvolvedor. Se não tiver o SNAPSHOT, é um candidato à liberação. Nós mantemos um repositório de candidatos de lançamento e o mais recente é enviado para implantação uma vez que os testadores estão felizes com ele.
Tudo isso pode ser gerenciado com algumas entradas simples em um arquivo de compilação sob o Maven. Veja o tutorial Maven2.
Este é provavelmente um post morto agora, mas vou adicionar meus dois centavos de qualquer maneira. Eu sou de opinião que os números de compilação deveriam significar algo para todos os que vêem isso. Então eu pessoalmente acho que esta é uma boa maneira de nomear versões:
major. minor. patch. revision - e. 1.1.4.2342.
Os números principais / menores são bastante auto-explicativos. Mas, na perspectiva do terceiro número, ainda precisa significar algo para o cliente. Lancei esta nova versão para você, Sr. Cliente, mas não valia a pena um novo número menor, já que acabamos de corrigir alguns erros. Então aumentamos o número do patch.
O 4º número geralmente significa absolutamente nada para o cliente, então você também pode torná-lo útil para você e para qualquer outra pessoa da sua empresa que o veja. Então, para nós, esse número é o número de revisão SVN. Ele nos diz exatamente qual revisão foi responsável por essa versão para que possamos retirá-la a qualquer momento para recriá-la. O código de ramificação obviamente obtém isso também, mas não para 100% de certeza.
Além disso, outra vantagem com um número de versão totalmente numérico é que ele se integra facilmente em quase todos os sistemas de compilação contínua.
De qualquer forma, são meus dois centavos.
+1 na solução Jira / Bamboo. A única informação adicional sobre a compilação que eu incluíria (para meus propósitos) é a versão do Subversion, embora a operação de marcação seja 80% do que eu quero.
A manutenção manual das informações de versão / versão é uma dor real. Deixar o JIRA dirigi-lo é uma ótima idéia.
Na pergunta final, sobre onde os erros / defeitos são registrados e liberando uma versão:
O defeito / Problema é registrado contra o lançamento onde ele aparece. Um defeito no 1.0.0-rc1 é registrado contra 1.0.0-rc1 A JIRA (ou talvez adicionamos) um campo 'Fix-For' que teria a versão planejada, neste caso 1.0.0 Se o defeito / problema for suficientemente grave, pode ser necessário adicionar outra versão 'rc'. O lançamento é feito quando não há defeitos / problemas críticos pendentes eo cliente (ou gerenciamento) concorda que quaisquer problemas remanescentes podem ser diferidos.
A beleza de gerenciar isso através do JIRA é que a adição de lançamentos, geração de logs de mudanças, etc. é automatizada bastante bem.
Nós também usamos & lt; major & gt;. & Lt; minor & gt;. & Lt; buildnumber & gt; e nós gerenciamos isso com CruiseControl / () no nosso servidor de compilação. E use Wix e CruiseControl Config para gerenciar os principais números menores - ainda assim incrementar esses com a mão - mas o número da compilação acontece automaticamente quando no servidor de compilação. Você poderia configurar uma regra de um incremento de maior / menor automaticamente também. Eu acredito - nós simplesmente gostamos de fazer isso manualmente para que seja preciso um pensamento consciente por um dev quando é hora de nomear um nível de lançamento particular.
Major e Menor são definidos por nós, incrementando-os manualmente como acharmos adequados.
BuildDateNumber é o número de meses desde o início do projeto multiplicado por 100, mais o número do dia do mês atual.
DailyBuildNumber é incrementado para cada compilação após a meia-noite a cada dia, começando em zero.
Por exemplo. 4ª versão da versão 5.2 em 10 de julho, onde o projeto começou 1 de janeiro desse ano, teria o número da versão.
Isso é tudo calculado para nós pela tarefa Versão em Nant.
Isso mantém os números de versão únicos e também nos permite calcular rapidamente quando uma instalação foi criada.

Kyle Lieber.
algumas coisas pelas quais eu senti escrever.
Estratégia de versão do Maven.
Eu tenho tido muitas discussões com analistas da minha organização sobre como o software de versão usando Maven e I & rsquo; achar que há um equívoco comum sobre o que realmente significa SNAPSHOT. Eu estava procurando um bom blog para enviá-los que ajude a explicar o controle de versão em Maven, mas infelizmente tudo que eu encontrei apenas discute formatos de versão e não como usá-los como você está desenvolvendo um aplicativo. Então, eu decidi que eu tomaria uma facada nisso. Congratulo-me com quaisquer comentários e críticas construtivas que me ajudem a melhorar este documento, então fique à vontade.
Primeiro, um SNAPSHOT não é o mesmo que uma versão alpha / beta / etc. É uma palavra-chave especial que significa que é a versão mais recente do seu código. Isso significa que ele muda. Se você derrubou o someapp-1.0-SNAPSHOT ontem e então você tenta retirá-lo hoje, provavelmente não será o mesmo. Isso também significa que se você tiver um projeto dependente de uma versão do SNAPSHOT, o maven precisará verificar o repositório remoto para as mudanças sempre que você executar uma compilação.
A próxima coisa a entender é qual é a versão em Maven. Uma versão não significa que a versão esteja pronta para a produção. Isso significa que o desenvolvedor decidiu que ele está em um ponto em seu desenvolvimento que ele quer que o código seja bloqueado para que não seja perdido. Ele também pode querer distribuir esse código para alguém, talvez seja uma biblioteca, um desenvolvedor em outra equipe precisa começar seu próprio desenvolvimento de aplicativos ou talvez seja um aplicativo que será instalado em um ambiente de teste para testes. Então, isso significa que uma versão do maven pode ser um alfa, beta, candidato a liberação, patch, produção ou qualquer outra coisa que você deseja categorizar.
Faz sentido? Bem, talvez passar por um cenário de como eu lido com isso o ajudaria. Primeiro, olhe para a estratégia de versão que uso:
Estratégia de versão.
A sintaxe para esta estratégia é baseada no formato em Maven: The Complete Reference. As diferenças são I & rsquo; m rename & ldquo; incremental version & rdquo; para & ldquo; patch & rdquo; e quebra o opcional & ldquo; qualifier & rdquo; em & ldquo; type & rdquo; e uma & ldquo; tentativa & rdquo; simplesmente por clareza.
& lt; major & gt; - Este é um número que indica uma mudança significativa no aplicativo. Uma versão importante talvez seja uma reescrita completa da versão principal anterior e / ou quebra a compatibilidade com versões anteriores. & lt; minor & gt; - Este é um número que indica um pequeno conjunto de alterações da versão secundária anterior. Uma versão menor geralmente consiste em um conjunto uniforme de correções de bugs e novos recursos e deve sempre ser compatível com versões anteriores. & lt; patch & gt; - Este é um número que indica que foram corrigidos alguns erros que não podiam esperar até a próxima versão menor. Uma versão de patch só deve incluir correções de bugs e nunca incluir novos recursos. Também deve ser sempre compatível com versões anteriores. As correções de segurança são um exemplo de um patch típico. [& lt; type & gt; - & lt; tentativa & gt;] - Esta última parte é opcional e usada apenas para identificar que esta versão não é necessariamente estável. O tipo é uma palavra-chave e pode ser qualquer coisa, mas geralmente aderem a alpha, beta e RC. A tentativa é apenas um número para indicar qual tentativa desse tipo é essa. Então, por exemplo, beta-01, RC-02, RC-05, ect. Para uma versão estável, deixo essa parte, no entanto, eu vi outros projetos que gostam de usar a palavra-chave de RELEASE para indicar a versão estável (você deixa a tentativa, porque isso não faria sentido, use RC (lançamento candidato) para isso).
Exemplo Scenerio.
Então, agora, para o cenário. Deixe-nos dizer que eu estou trabalhando no aplicativo Foobar. Minha organização está esperando que eu entregue a versão 1.0 do foobar no final do trimestre. (Observe que eu digo 1,0, o que significa que eu só uso os dois primeiros números para se referir à versão. Isso ocorre porque a versão maior e menor são realmente as únicas versões em que qualquer pessoa se importará além do seu time de desenvolvimento. Além disso, não há caminho para eu saber qual será a versão final, mas eu sei que o maior e o menor permanecerão o mesmo.) Eu estou trabalhando em uma equipe ágil, então eu vou implantar tudo o que eu fiz no final de cada sprint para o meu ambiente de teste para que meus testadores possam validar tudo. Então, aqui é o que eu posso fazer:
Vou começar com a versão 1.0.0-SNAPSHOT no meu pom. xml no início do Sprint # 1. No final do Sprint # 1, vou usar o plugin maven-release para criar a versão foobar-1.0.0-RC-01 da aplicação Foobar. O plugin irá mudar a versão de 1.0.0-SNAPSHOT para 1.0.0-RC-01, marcar o código em scm com foobar-1.0.0-RC-01 e, finalmente, criar essa versão. Em seguida, o plugin irá atualizar o tronco para ser a próxima versão de desenvolvimento do aplicativo que iremos em 1.0.0-SNAPSHOT. Então eu vou implantar o foobar-1.0.0-RC-01 para o ambiente de teste. Este processo continuará para os próximos sprints até chegarmos a uma fase em que estamos a um ponto em que pensamos estar completo.
Então, deixe-nos dizer que estamos agora na Sprint # 5. Nós lançamos quatro versões de candidatura de lançamento do aplicativo, corrigindo erros e adicionando recursos ao longo do caminho. Agora nos sentimos foobar-1.0.0-RC-04 está pronto para uso em produção. Agora eu lanço o maven-release-plugin novamente para criar a versão foobar-1.0.0 do meu aplicativo. Mais uma vez, o plugin irá marcar a versão atual do código no scm com foobar-1.0.0 e, em seguida, construir essa versão. O plugin então atualizará o tronco para ser a próxima versão de desenvolvimento do aplicativo que desta vez eu escolho ser 1.1.0-INSTANTÂNEO.
Aviso, incremento a versão menor e não a versão do patch. Em um mundo perfeito, eu seria feito com a versão 1.0, mas é claro que isso não é um mundo perfeito e, provavelmente, I & rsquo; eu tenho que corrigir minha versão 1.0.0 em algum momento. Como eu não sei quando isso será, eu vou seguir com a vida e começar a trabalhar na próxima versão do aplicativo, 1.1.
Algumas semanas depois, minha equipe de QA me informa que um erro foi encontrado nos testes de lançamento que precisam ser corrigidos. O que vou fazer agora? I & rsquo; ve movido e tem novo 1.1 código no tronco que pode & rsquo; t entrar na versão 1.0. Sem preocupações, lembro que o plugin de lançamento marca cada um dos meus lançamentos para mim. Então, eu crio um ramo da tag foobar-1.0.0 e chama foobar-1.0.X. Em seguida, marquei o novo ramo e incremente a versão do patch para 1.0.1-SNAPSHOT. Este novo ramo é agora meu ramo de remendo. Eu corrigirei o bug relatado pela equipe de QA e use o plugin de lançamento para produzir a versão de patch foobar-1.0.1. Então, imediatamente depois de produzir foobar-1.0.1, mesclaremos as alterações 1.0.1 no tronco para que a correção esteja presente na versão 1.1 (que ainda não foi lançada).
Então respiro fundo e volto a trabalhar no 1.1. Se surgir outro erro, talvez, mesmo depois de sairmos à produção, vou continuar a voltar ao meu ramo de remendo foobar-1.0.X para fazer a correção e mesclar as mudanças de volta ao tronco.
Estratégia simplificada.
Eu não uso sempre a estratégia acima. Na verdade, muitas vezes eu uso o que eu chamaria de versão simplificada desta estratégia. Essencialmente, é a mesma coisa, exceto que eu removo o - & lt; type & gt; - & lt; tentativa & gt; completamente e em vez de um & lt; patch & gt; , Eu tenho um mais genérico & lt; incrementalVersion & gt; (assim como no livro maven). Então, parece assim:
Deixe o & rsquo; s voltar para o cenário de exemplo acima e compare a estratégia completa com esta estratégia simplificada:
Como você pode ver, a estratégia simplificada perde uma parte da verbosidade da estratégia completa que pode ser uma coisa boa e ruim. Não será óbvio se uma versão está pronta para a produção ou apenas um candidato a liberação. No entanto, isso significa que você não precisa testar o candidato de lançamento aceito duas vezes. Se você notou, a versão fornecida pela Sprint # 4 também é a versão de produção. Não há necessidade de reconstruí-lo apenas para remover o - RC-04.
Para uma equipe menor ou uma equipe que não tem realmente seus artefatos consumidos por muitas outras áreas, esta pode ser uma solução melhor porque há muito menos versões para gerenciar. Você só precisa se certificar de que está se comunicando claramente com sua equipe para que todos saibam o que está acontecendo.
Postagens recentes.
GitHub Repos.
Atualização do status. klieber no GitHub.
Direitos autorais e cópia; 2016 Kyle Lieber - Licença - Desenvolvido pelo tema Hugo e Hugo-Octopress.

estratégia de versão de Java
Obter através da App Store Leia esta publicação em nosso aplicativo!
Estratégia adequada para o banco de dados de controle de versão.
Estou lendo este blog e tenho uma pergunta sobre as 5 postagens que estão escritas. Pelo que eu entendo, você cria no grande script de linha de base que inclui todas as estatísticas SQL DDL. Depois disso, você acompanha cada alteração em scripts separados.
No entanto, não entendo como o nome do arquivo de script pode ser relacionado a uma compilação específica do seu aplicativo? Ele diz que, se um usuário relatar um erro em 3.1.5.6723, você pode re-executar os scripts para essa versão. E você acompanharia as mudanças em uma tabela, etc, em um arquivo próprio ou ter todas as alterações DLL no mesmo arquivo de script e, em seguida, ter exibições etc em arquivos próprios como ele diz?
Em primeiro lugar, as atualizações de banco de dados são ruins, mas esse blog descreve um pesadelo total.
Aquele pode criar uma Matriz de Competências do Programador com base na abordagem de atualização:
Nível 0: sem atualizações. Os clientes estão aterrorizados e movem os dados manualmente usando UI fornecida por um aplicativo ou soluções de gerenciamento de banco de dados de terceiros (acredite, é realmente possível). Nível 1: há um script para atualizar um despejo de banco de dados. Os clientes se sentem seguros, mas eles resolverão problemas pequenos e muito irritantes para os próximos 1-2 anos. O sistema está funcionando, mas nenhuma alteração é permitida. Nível 2: alteração da tabela. Tempo de inatividade monstruoso, especialmente em caso de problemas durante a atualização. Problemas enormes e praticamente nenhuma garantia para obter resultados 100% seguros. A conversão de dados é gerenciada por um script de buggy. Os clientes não estão felizes. Nível 3: design sem esquema: um tempo de inatividade de uma hora para permitir que scripts de buggy traduzam a configuração no banco de dados (este passo pode danificar o DB em muitos casos). O pessoal de apoio tem todas as reservas de café completamente esgotadas. Nível 4: Atualizações transparentes preguiçosas: tempo de inatividade zero, mas ainda são possíveis alguns problemas. Os clientes estão quase felizes, mas ainda se lembram de experiências anteriores. Nível 5: arquitetura ideal, nenhuma atualização explícita é necessária. Felicidade total. Os clientes não sabem qual é o procedimento de atualização. Os desenvolvedores são produtivos e tranquilos.
Vou descrever todas as questões técnicas, mas antes disso, deixe-me indicar o seguinte (por favor, perdoe uma resposta bastante longa):
os ciclos de desenvolvimento de hoje em dia são muito compactados e os DBs são grandes, praticamente qualquer característica pode introduzir mudanças de esquema e quebrar a compatibilidade, então, temos um procedimento de atualização simples e estável ou podemos adiar uma característica que um problema pode ser identificado por um cliente, então existe uma chance para ter uma compilação urgente de hot-fix com algumas etapas de atualização necessárias em geral, é muito melhor evitar barreiras entre você e seu cliente.
Nível 0 e Nível 1 Ambos os casos são óbvios e estúpidos. Alguém deve evitar isso.
Nível 2 Alterar não é tão ruim para pequenas mesas, mas pode ser um problema para o grande. Em mesas realmente grandes (> 1Gb), provavelmente levará várias horas ou até dias para que ALTER TABLE complete. Além disso, ele resolve apenas problemas de atualização de esquema, mas e os dados armazenados? Eu também sugiro pensar sobre o layout dos dados físicos para entender os impedimentos reais por trás dessa abordagem. Todo o procedimento pode ser inseguro, então tenha certeza de ter backups.
Nível 3 O problema com a atualização do esquema é resolvido movendo o esquema para a camada superior. A solução sem esquema é um pouco limitada, principalmente porque desabilita todo o poder por trás de um modelo relacional. Uma abordagem híbrida pode ser proposta para ter melhorias rápidas e capacidade de usar a álgebra relacional. Existem alguns artigos interessantes:
Observe, a complexidade do procedimento de atualização ainda está lá, ele simplesmente mudou para o nível do aplicativo. Existem muitos cenários relevantes, mas vou descrever um sistema híbrido com o qual trabalhei há vários anos. Posso descrever um modelo de dados como "Entidades com relações". As relações entre as entidades foram representadas no nível do banco de dados, as próprias entidades foram armazenadas como bolhas XML.
Este sistema era maduro e tinha clientes suficientes. Havia muitos pedidos de recursos, então as equipes de R e D e QA estavam um pouco estressadas. Inicialmente, o procedimento de atualização foi implementado como um aplicativo Java autônomo que lê bolhas XML do banco de dados, atualizando-o usando a API DOM e escrevendo de volta para o banco de dados. A abordagem atual parece bastante direta, mas há várias questões ocultas por trás:
a lógica de atualização pode ser um pouco buggy, então existe a chance de escrever dados XML errados, aumentando significativamente o tempo de inatividade para um cliente, pode demorar algum tempo a ler-transformar-escrever 1-2GBs de XML, todas as etapas do procedimento de atualização devem ser abordadas com Testes automatizados (eu diria que CI é um MUST) falhas ocultas podem ser encontradas em um dia ou dois, então os backups não são úteis, porque o novo código de atualização inserido pode se tornar um pouco bagunçado, especialmente se você deseja / precisar para atualizações entre compilações (requisito normal para qualquer equipe ágil)
Eu tentei mitigar todos os riscos potenciais usando uma definição de procedimento de atualização mais rigorosa, regras de validação e testes extensivos realizados pelo sistema CI contra dados da vida real (coletados em todos os clientes). Fiquei surpreso ao ver alguns passos falhando por causa das antigas questões introduzidas há muito tempo por um antigo script de atualização. Etapas de atualização separadas foram desenvolvidas para corrigir esses problemas ocultos. Alguma otimização também foi realizada para diminuir o tempo de atualização para 20-30 minutos razoáveis. A implementação da barra de progresso baseada em console fez o resto.
Nota rápida: qualquer usuário final está ansioso para ver um progresso para qualquer operação de longa duração (> 2 min). Por favor, não se esqueça de implementar tal "prazer".
Inicialmente, a versão DB foi armazenada na tabela separada. Não use essa abordagem, porque é muito melhor ter as entidades com versões separadas e evitar o bloqueio DB completo durante a atualização.
Mostrará um procedimento de atualização como um exemplo (todas as etapas de validação e verificação estão escondidas atrás da lógica de processamento & lt; build / & gt; e & lt; version / & gt;). '-' significa menos, '*' - qualquer compilação.
Cada script é uma pequena implementação Java ou Groovy (XSLT também foi usado). Mais tarde, um procedimento de downgrade também foi desenvolvido, mas esta é uma história totalmente diferente.
O esquema de dados de nível 4 na camada de aplicação permite fazer muitas coisas interessantes. Por exemplo, é possível substituir XML com protobuf. Como de costume, há várias razões para fazer isso (é mais simples, rápido, etc.). Se você não gosta de conceito de construtor, você pode usar o Thrift.
De qualquer forma, o protobuf permite criar um sistema compatível com versões anteriores (em termos de dados armazenados) quase sem dor de cabeça. Boa sorte, por sinal. Com o seu sistema compatível com versões anteriores, você pode facilmente implementar atualização preguiçosa e totalmente transparente. Pode ser um processo em segundo plano ou atualização após um pedido, etc. A boa notícia é zero-downtime, usuários felizes e capacidade de atualizações com mais freqüência. O que significa que você pode se desenvolver rapidamente, responder prontamente aos pedidos dos clientes, ter mais sucesso nas outras palavras.
Nível 5 Desculpe, não por este tempo. Tenha cuidado com as estratégias de atualização. É muito fácil vender um sistema com algum esquema definido e bloquear-se. Sem novos recursos - sem clientes.
Lista de verificação simples mas extremamente útil:
Você poderá resolver prontamente um problema do lado do cliente? Será seguro para o cliente atualizar o sistema (e se for pelo menos missão crítica)? Quanto tempo será necessário para identificar um problema? Existe alguma verificação automática?
Obrigado por ler.
As alterações em tabelas e visualizações não serão mantidas em seu próprio arquivo. Você criará um novo script de mudança para cada mudança que você fizer. Então, se você alterar a tabela 'X' 5 vezes, você terá 5 scripts de mudança diferentes para cada uma dessas mudanças.
Quando você deseja criar o esquema a partir de determinada versão, você receberá o código-fonte rotulado para essa versão. Crie o banco de dados a partir da linha de base. Em seguida, execute os scripts de alteração naquela versão do código, em ordem cronológica. por exemplo.
Agora, digamos que deseja recriar o banco de dados a partir da versão 1.2:
você sincronizaria o código para rotular a versão_1.2 execute os scripts na ordem baseline. sql, add_publisher. sql, add_publish_date. sql.
Em vez de Liquibase, você pode usar o Flyway (flywaydb. org/) que permite que você escreva seus próprios scripts SQL de atualização / downgrade. Isso oferece mais flexibilidade e também funciona para visualizações e procedimentos armazenados.
O Liquibase requer que você faça alterações de esquema usando seu próprio idioma baseado em XML, o que pode ser um pouco limitante.
Manter um número de versão no banco de dados, e aplicar scripts de atualização na inicialização, é uma parte importante desta estratégia.
Veja como funciona o arranque:
verifica o registro DB_VERSION no banco de dados, encontra atualizações> versão atual; talvez por código. executa cada "atualização" aplicável, script ou ações programáticas ... DB_VERSION é atualizado após cada um, portanto, uma falha a meio caminho pode ser re-executada.
encontre DB_VERSION atualmente = 789; código sofisticado ou uma grande cadeia IF longa, encontra as atualizações 790 e acima. atualização # 790, upgrade Customer & amp; Tabelas de contas; atualização # 791, tabela de atualização; atualização # 792, reestruturar tabela de pedidos; versão do banco de dados agora = 792.
Existem algumas ressalvas. Isso funciona razoavelmente bem; As pessoas afirmam que deve ser 100% confiável, mas não é.
Problemas de scripts incompletos, variações nos comprimentos de campo ou diferenças nas versões do servidor podem ocasionar que scripts / SQL passem alguns bancos de dados, mas falham em outros.
Encontrar os scripts para executar, pode ser tão simples como um grande método único com muitas instruções IF. Ou você pode carregar os scripts por descoberta ou metadados, de forma mais elegante. Às vezes, é útil incluir código programático, não apenas SQL.

Estratégia de versão de compilação.
Junte-se à comunidade DZone e obtenha a experiência dos membros completos.
Baixe o modelo que pode levar uma empresa de qualquer nível de maturidade até a entrega contínua em escala empresarial usando uma combinação de automação liberação Automação, mais de 20 anos de experiência de automação comercial da Automic e as ferramentas e práticas comprovadas que a empresa já está alavancando .
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.
Faça o download do "Modelo prático para entrega contínua" para saber como a automação liberação automação pode ajudá-lo a começar ou continuar a transformação digital da sua empresa.
Como esse artigo? Leia mais do DZone.
Free DZone Refcard.
Começando com Docker.
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.