blogando sobre Gerenciamento do ciclo de vida do aplicativo com TFS / VSTS.
Estratégia de versão global e # 8211; AssemblyInformationalVersion.
Já ouvi falar de um terceiro atributo de versão (opcional) nos arquivos AssemblyInfo: AssemblyInformationalVersion. Não? Por favor leia!
Sem uma estratégia de numeração de versão metódica (assembly), a capacidade de determinar quais alterações foram incluídas em qual versão foi perdida. Na minha opinião, você sempre precisa saber exatamente quais arquivos de origem foram instalados em qual compilação e qual versão do software está atualmente implantada em um ambiente específico. Um sistema de numeração de versão aleatória cria confusão e logo ou mais tarde causará riscos de implantação. Vai se tornar um pesadelo para buscar os arquivos fonte exatos para reproduzir um bug da produção.
Todo o controle de versão de assembléias que usam o tempo de execução de linguagem comum é feito no nível de montagem. A versão específica de uma montagem e as versões de montagens dependentes são registradas no manifesto de montagem # 8217 ;. A política de versão padrão para o tempo de execução é que os aplicativos são executados apenas com as versões em que foram criados e testados, a menos que sejam substituídos pela política de versão explícita nos arquivos de configuração.
Cada projeto possui um arquivo AssemblyInfo que contém um atributo AssemblyVersion e um atributo AssemblyFileVersion.
AssemblyVersion: este é o número de versão usado pela estrutura durante a compilação e no tempo de execução para localizar, vincular e carregar as montagens. Quando você adiciona uma referência a qualquer montagem em seu projeto, esse é o número da versão que é incorporado. Em tempo de execução, o CLR procura a montagem com este número de versão para carregar. Mas lembre-se que esta versão é usada juntamente com nome, chave pública chave e informações culturais somente se as assembléias tiverem o nome forte assinado. Se os assemblies não tiverem um nome forte assinado, somente os nomes dos arquivos são usados para carregar. AssemblyFileVersion: Este é o número de versão dado a um arquivo como no sistema de arquivos. É exibido pelo Windows Explorer. Nunca é usado por framework ou tempo de execução para referenciar.
Mas e quanto a essa diferença entre AssemblyVersion e AssemblyFileVersion? Muitas vezes, vejo que a mesma versão é aplicada a ambos os atributos e # 8230; mas por que esses dois atributos (diferentes) são fornecidos pelo Framework? O AssemblyVersion deve ser a versão pública de um aplicativo de software completo, enquanto o AssemblyFileVersion é mais a versão de um componente específico que pode ser apenas uma pequena parte do aplicativo inteiro. O AssemblyFileVersion é o melhor lugar para colocar informações de versão de compilação extra que podem ser importantes para corrigir componentes individuais de um aplicativo de software.
Siga as recomendações da Versão Semântica para determinar como o AssemblyVersion deve ser atribuído e incrementado. Para o AssemblyFileVersion, tendem a incluir informações de compilação específicas. Muitas vezes, você precisará criar (e testar) uma série de vezes uma versão SemVer específica do seu software.
Por exemplo: a versão 1 de um aplicativo de software poderia ter o AssemblyVersion configurado para 1.0.0 (todos os componentes), enquanto o AssemblyFileVersion dos componentes individuais poderia ser configurado para 1.0.15234.2 que se refere a um número de compilação exclusivo do sistema de compilação e é vinculado a uma determinada data e uma revisão: & # 8220; 15 & # 8221; = ano de 2015; & # 8220; 234 & # 8221; = número do dia em 2015; & # 8220; 2 & # 8221; = segunda compilação processada nesse dia. Isso também permite posteriormente o patch de componentes individuais em produção com um similar AssemblyVersion (1.0.0), mas um AssemblyFileVersion diferente (1.0.15235.1).
Então, vamos tentar aplicar isso a um projeto de teste no Visual Studio e ver os detalhes da montagem após a construção do projeto & # 8230;
Agora você deve estar confuso! Por que a versão do produto exibe AssemblyFileVersion e onde o AssemblyVersion? O problema aqui é que um novo projeto do Visual Studio não inclui um atributo de terceira versão AssemblyInformationalVersion que se destina a representar a versão pública de todo o aplicativo de software. Observe que o CLR não se preocupa com esse terceiro atributo de versão (opcional). Em suma, as mesmas regras de versão semântica da AssemblyVersion devem ser aplicadas ao AssemblyInformationalVersion.
Aha! Isso parece muito melhor, certo? Agora, também é fácil extrair esses metadados de seus assemblies implantados e esta informação pode ser bem listada na caixa sobre do seu software. O único problema com esta abordagem é que o AssemblyFileVersion não inclui o & # 8220; patch & # 8221; número (versão semântica) do AssemblyVersion, mas isso pode ser ignorado com o fato de que o AssemblyFileVersion será exclusivo e pode ser vinculado a uma execução de compilação exclusiva no sistema de compilação. Esta maneira de trabalhar é minha interpretação pessoal de como o controle de versão pode ser aplicado corretamente em aplicativos de software complexos e não reflete as diretrizes oficiais da Microsoft. Meu objetivo aqui é fazer os desenvolvedores de software conscientes dos riscos potenciais de não ter uma estratégia de versão de versão clara.
Agora, esqueça manualmente a configuração das informações da versão nos arquivos AssemblyInfo e nunca libere o software de uma compilação Visual Studio local. Em um processo de compilação simplificado, gerar números exclusivos de compilação e versão são coordenados de forma centralizada. Para uma solução eficaz de problemas e rastreabilidade, é imperativo que as montagens geradas sejam carimbadas com um identificador exclusivo que possa ser facilmente rastreado até um número de compilação do sistema.
Em uma próxima publicação, falo sobre como você pode alcançar essa estratégia global de versão com o novo sistema de compilação no TFS 2015.
Pós-navegação.
Deixe uma resposta Cancelar resposta.
O Real Semver permite uma tag de pré-lançamento como esta & # 8220; 1.2.4-beta04 & # 8221 ;. Semver também permite metadados como número de compilação, data, commit ou changeset como este & # 8220; 1.0.0 + 20130313144700 & # 8221 ;.
AssemblyInformationalVersion é o único campo que permite qualquer outra coisa que a notação de versão clássica, como 1.2.3.4. AssemblyVersion e AssemblyFileVersion só permitem a notação de versão estrita. E todas as partes estão limitadas a 65536. Eu acredito (porque por que precisamos de estranha notação para datas, certo?).
Você sugere a configuração AssemblyInformationalVersion e AssemblyVersion para a mesma versão, mas depois perdemos essa poderosa característica / idéia. E tudo o que está à esquerda é colocar uma certa data de representação do número de compilação no AssemblyFileVersion (desde que ele seja na forma de 1.2.3.4)
Talvez AssemblyInformationalVersion deve começar com AssemblyVersion, mas permitir que a tag e os metadados sejam anexados?
Ao empacotar um nupkg, o AssemblyInformationalVersion será usado. O que é ótimo porque dessa maneira você pode criar pacotes de pré-lançamento. Mas pode não ser fácil configurar tags de pré-lançamento para suas compilações automatizadas.
O mínimo que podemos dizer, é uma bagunça, é confuso e a estrutura não foi construída com tudo isso em mente. Para piorar as coisas, temos um trabalho real em vez de tentar descobrir esses detalhes inúteis 🙂
A informação de montagem global é uma boa idéia. Aliás, o Assembly Versioner e o Info Updater podem ajudar as versões de projeto / montagem do gerente e outras informações para todos os projetos / montagens em uma UI única:
O Visual Smarter tem muito mais recursos do que os dois acima.
Compartilhar uma versão comum de montagem / arquivo de informações é uma boa idéia se todas as assembléias / projetos devem ter a mesma informação / versão. Caso contrário, o Assembly Versioner e Info Updater podem vir a resgatar no último minuto:
O Visual Smarter tem muito mais recursos do que os dois acima.
Estratégia de versão
Obter através da App Store Leia esta publicação em nosso aplicativo!
Estratégia de versão para aplicativos no Git.
Minha empresa simplesmente começou a usar git e estou lutando com o controle de versão. Estamos usando a versão semântica (major. minor. patch), que definimos com base nas mudanças feitas no produto. No entanto, eu gostaria de usar a quarta parte para indicar o commit git. Eu li artigos sobre como fazer isso, especialmente um usando o gancho pós-mesclagem, mas quanto mais eu entrou nisso, mais confuso me tornei, não na parte técnica, mas na parte conceitual.
Eu realmente gosto da idéia de poder usar o hash de commit git na versão, pois deixa muito claro o que é o software. No entanto, não posso saber isso até depois do commit, em que ponto, alterar a versão exigiria outro commit e o hash seria incorreto. Então, se eu conseguir um número de versão, vá para git, eu realmente estaria recebendo o commit antes do que estava em uso. O que eu quero é poder ir ao git, pegar a etiqueta e criá-la exatamente como está em uso.
Eu suspeito que a resposta reside no processo de compilação, na medida em que esse processo iria consultar o git, obter o hash, atualizar AssemblyInfo. cs e depois construir o produto.
Como sou muito novo para tudo isso, eu me pergunto se:
Estou perdendo algo conceitualmente? Existe melhor maneira do que a construção? Se o processo de compilação for o caminho a seguir, existem maneiras comprovadas de lidar com isso?
O hash (para git, a sha1) selar todo o conteúdo do commit. Se apenas uma coisa mudar no commit, o conteúdo de um arquivo ou um metadata do commit (data de commit, commit message, author.), O hash será diferente. Nesse caso, você entende que não pode obter o hash de confirmação, modificar o conteúdo de um arquivo e alterar o commit e esperar ter o mesmo hash para o commit! Então, se você quiser criar suas assembléias, você deve atualizar o arquivo AssemblyInfo. cs com o hash de confirmação em seu processo de compilação antes de compilar a solução.
Para aqueles curiosos, esta é a solução que acabei por usar.
Depois de confirmar que eu entendi como funcionou toda a coisa commit / hash, comecei a procurar mais o processo de compilação. Acontece que foi bastante fácil. Este artigo me levou na direção certa. Aqui é o que eu fiz:
Estratégia de versão
Obter através da App Store Leia esta publicação em nosso aplicativo!
Estratégias para atualização ou versão de serviços da Web?
Estou interessado em ouvir as melhores práticas sobre como as diferentes versões dos serviços da Web são tratadas.
Para esclarecer, se você tiver alguns métodos da Web expostos como um serviço da Web, então você deseja adicionar uma característica / funcionalidade e, assim, alterar a assinatura dessas chamadas de método, como você lida com isso de uma maneira que não quebra tudo dos seus clientes que atualmente chamam de serviço?
Você implanta o serviço em um URL diferente?
Você coloca uma versão no próprio nome do método (MyMethod, MyMethodv2 etc. - ugh ..)
Você passa uma versão como parte da chamada do método junto com uma lista de parâmetros?
Alguém sabe como o Google ou o Amazon lidam com esse cenário com sua extensa biblioteca de serviços da Web?
EDIT: Até agora, encontrei algumas informações boas neste artigo da Oracle. Também esta entrada de blog em alguns detalhes do Java foi útil. Ainda estou curioso para ver algumas das outras abordagens.
A maneira típica de versionar um serviço da Web é ter clientes especificando a versão desejada. Você pode permitir restrições simples, como "> 2.0", "& lt; 1.5", ou "= 1.1". Naturalmente, você deseja minimizar o número de versões suportadas para sua própria sanidade. Se um cliente não especificar uma versão, você assume o mais recente.
As técnicas para fornecer a versão variam. Alguns defendem o uso do URL, outros encorajam cabeçalhos, alguns podem incluí-lo como um parâmetro da chamada api. Quase nenhum mudaria o nome do método, no entanto. Isso é equivalente ao "pacote" ou "namespace" que controla o link do OSGi. Isso tornará a atualização muito difícil e impedirá as pessoas de atualizar mais do que quaisquer alterações ao serviço real.
Também depende da forma como você acessa seus serviços na web. Se você estiver usando o REST, manter o URL limpo e usando cabeçalhos faz mais sentido (e seria trivial cortá-lo como um parâmetro de consulta, se necessário). Se você estiver usando SOAP / XMLRPC / o que for, o RPC, então, colocá-lo no URL geralmente é bom.
Como o cliente especifica a versão geralmente é bastante fácil. O que é mais complicado é como você executa todas as versões simultaneamente. A maioria dos idiomas não tem uma maneira de carregar várias versões da mesma biblioteca / módulo / classe / função no mesmo ambiente de tempo de execução (seja uma VM, processo ou o que você tem). O link OSGi fornecido é a solução de Java para permitir isso.
Na prática, a OSGi será superada para a maioria das situações. Normalmente, é mais fácil enviar solicitações obsoletas para outro servidor ou processo.
A melhor maneira de "versão" de seus serviços, no entanto, é criar extensibilidade e flexibilidade para eles, de modo que permaneçam compatíveis e compatíveis. Isso não significa que todas as versões devem ser compatíveis entre si, mas as versões consecutivas devem ser compatíveis entre si.
Posso dizer-lhe que a solução de criar doAPIFunction, doAPIFunctionV2 e doAPIFunctionV3, etc, produziu apenas dores de cabeça no local em que trabalho. Adicione a isso a falta de nomes de funções claramente descritivos significa todo tipo de loucura.
Você quer nomes claros da função da API e, se uma api estiver mudando, o objetivo seria tentar fazê-lo de forma compatível com versões anteriores. Eu sugeriria a versão de seus pontos de entrada para que cada ponto de entrada ofereça suporte a API e doFunction estáveis em example. org/api-1.0/ pode ser diferente de example. org/api-2.0 se existisse uma boa razão para mudar a semântica.
Não tenho certeza se eu entendi sua pergunta corretamente. Mas meus 2 centavos. Se a assinatura do método muda como outro novo parâmetro, por que não pode ser feito opcional? Mas se um tipo de dados de parâmetro existente for alterado, não será aplicável.
Vote para isso se está errado. :)
Ele costumava ser mais simples quando você poderia ter o mesmo nome do método de serviço na web, e diferentes parâmetros, há anos. :)
Uma vez que você escreve um serviço na web, você está fazendo um contrato com os clientes que é isso que você apoiará.
Para métodos mais antigos, sugiro iniciar sessão para ver se eles estão sendo usados e por quem, para ver se você pode fazê-los atualizar.
Além disso, é melhor você simplesmente escrever um novo método, então você pode ter vários nomes de funções similares que diferem por uma versão.
O problema com a passagem de um número de versão é que você deve garantir que os clientes sempre passem num número válido, o que, se você gerar os talões, funcionará, mas, se não o fizer, isso é muito frágil.
Colocar um número de versão no nome parece funcionar melhor para mim, pois torna óbvio o que é antigo e você pode usar o AOP para registrar mais facilmente versões antigas dos métodos de serviço na web.
Estratégia de versão
Obter através da App Store Leia esta publicação em nosso aplicativo!
Qual é a sua estratégia de versão do aplicativo? [duplicado]
Esta questão já tem uma resposta aqui:
Eu estaria interessado em obter as opiniões da comunidade SO sobre a melhor estratégia de versão de aplicativos.
Como você acompanha o número da versão do seu aplicativo? Você tem uma definição formal do que representa cada número / personagem dessa versão?
O que significam os diferentes números / strings na versão do aplicativo para o seu aplicativo?
Você usa qualquer sistema de atualização automatizado em suas aplicações (por exemplo, algo como Sparkle) e como ele tem sido bom para você?
Você tem um procedimento de atualização separado para testadores beta ou testadores de pré-lançamento do seu aplicativo?
marcado como duplicado pelo mosquito, MichaelT, Kilian Foth, GlenH7, Rein Henrichs 29 de abril 13 às 2:42.
Esta pergunta foi feita antes e já tem uma resposta. Se essas respostas não respondem totalmente a sua pergunta, faça uma nova pergunta.
migrou do stackoverflow 18 de maio às 11h48.
Esta questão veio do nosso site para programadores profissionais e entusiasta.
Como você acompanha o número da versão do seu aplicativo? Você tem uma definição formal do que representa cada número / personagem dessa versão?
O que significam os diferentes números / strings na versão do aplicativo para o seu aplicativo?
Eu uso o seguinte:
Major - A versão principal é um lançamento definitivo do produto. Aumentou quando há mudanças significativas na funcionalidade.
Menor - A versão menor é incrementada quando apenas foram adicionados novos recursos ou grandes correções de bugs.
Upgrade / Patch - Upgrade refere-se à substituição de um produto por uma versão mais recente do product. It é incrementado somente quando a atualização é fornecida na versão principal designada. A versão do programa começa com 0 e é incrementada somente quando o erro foi resolvido.
Build No - Build Number é incrementado quando a nova compilação é criada.
Você usa qualquer sistema de atualização automatizado em suas aplicações (por exemplo, algo como Sparkle) e como ele tem sido bom para você?
Nós usamos uma ferramenta de construção que automaticamente cria aplicativos à noite, que chamamos construção noturna e isso aumenta o número de compilação sempre que uma compilação é criada.
Você tem um procedimento de atualização separado para testadores beta ou testadores de pré-lançamento do seu aplicativo?
Não testadores testados durante a noite todas as manhãs que chamamos BAT (Build Aceceptance Test) e verificamos a construção noturna.
Permitam-me que note primeiro que parece não haver acordo sobre a "melhor" estratégia. Só posso compartilhar minha experiência em um projeto atual.
A versão do sistema é definida manualmente em uma propriedade de compilação. Acontece quando a equipe concorda em uma nova versão. Como versão de versão adicional, usamos o número de compilação que é gerado automaticamente pela construção do CI.
Seguimos vagamente o esquema de nomeação do Ubuntu YY. MM. version. patch_buildNumber, pois descobrimos que o controle de versão Major. Minor sujava as expectativas dos clientes;)
Não há atualizações automáticas, pois o aplicativo deve ser lançado por adminstrators.
Os lançamentos de teste são mais freqüentes do que as versões da GA, mas isso deve ser tudo.
Testei muitos sistemas de versões e agora estou muito feliz com este:
O Major é configurado manualmente e se refere a uma versão que inclui importantes melhorias. Menor também é configurado manualmente e se refere a uma versão de atualização / manutenção, incluindo melhorias menores e amp; correção A revisão é gerada automaticamente e se refere a uma revisão exata no repositório.
O último nos permite ser muito flexíveis com a versão. Podemos enviar múltiplas versões para vários clientes e ainda ser capazes de depurar & amp; conserte com facilidade obtendo a versão específica dos repos, então combine novamente com o tronco.
A construção, embalagem e amp; A publicação é totalmente automatizada. A única ação manual é quando movemos o último pacote para o servidor de produção por FTP. Queremos manter o controle sobre isso para garantir que não entregamos lixo na produção. Ele é um estágio preliminar em que os adotadores iniciais podem ler as notas da versão e depois decidir baixar e usar a versão. Os clientes que enfrentam erros específicos podem obter uma versão fixa muito rápido usando uma dessas versões.
Uso a versão semântica para as bibliotecas de código aberto e acho muito mais fácil trabalhar com outras bibliotecas que também o fazem. Ele fornece uma base comum para entender o que uma mudança de versão pode significar. A biblioteca ainda está em versão beta? É um lançamento apenas para correções de bugs? Haverá mudanças de API quebradas?
É basicamente uma codificação das melhores práticas de versão já utilizadas pela maioria dos projetos de código aberto.
Obter através da App Store Leia esta publicação em nosso aplicativo!
Estratégias para atualização ou versão de serviços da Web?
Estou interessado em ouvir as melhores práticas sobre como as diferentes versões dos serviços da Web são tratadas.
Para esclarecer, se você tiver alguns métodos da Web expostos como um serviço da Web, então você deseja adicionar uma característica / funcionalidade e, assim, alterar a assinatura dessas chamadas de método, como você lida com isso de uma maneira que não quebra tudo dos seus clientes que atualmente chamam de serviço?
Você implanta o serviço em um URL diferente?
Você coloca uma versão no próprio nome do método (MyMethod, MyMethodv2 etc. - ugh ..)
Você passa uma versão como parte da chamada do método junto com uma lista de parâmetros?
Alguém sabe como o Google ou o Amazon lidam com esse cenário com sua extensa biblioteca de serviços da Web?
EDIT: Até agora, encontrei algumas informações boas neste artigo da Oracle. Também esta entrada de blog em alguns detalhes do Java foi útil. Ainda estou curioso para ver algumas das outras abordagens.
A maneira típica de versionar um serviço da Web é ter clientes especificando a versão desejada. Você pode permitir restrições simples, como "> 2.0", "& lt; 1.5", ou "= 1.1". Naturalmente, você deseja minimizar o número de versões suportadas para sua própria sanidade. Se um cliente não especificar uma versão, você assume o mais recente.
As técnicas para fornecer a versão variam. Alguns defendem o uso do URL, outros encorajam cabeçalhos, alguns podem incluí-lo como um parâmetro da chamada api. Quase nenhum mudaria o nome do método, no entanto. Isso é equivalente ao "pacote" ou "namespace" que controla o link do OSGi. Isso tornará a atualização muito difícil e impedirá as pessoas de atualizar mais do que quaisquer alterações ao serviço real.
Também depende da forma como você acessa seus serviços na web. Se você estiver usando o REST, manter o URL limpo e usando cabeçalhos faz mais sentido (e seria trivial cortá-lo como um parâmetro de consulta, se necessário). Se você estiver usando SOAP / XMLRPC / o que for, o RPC, então, colocá-lo no URL geralmente é bom.
Como o cliente especifica a versão geralmente é bastante fácil. O que é mais complicado é como você executa todas as versões simultaneamente. A maioria dos idiomas não tem uma maneira de carregar várias versões da mesma biblioteca / módulo / classe / função no mesmo ambiente de tempo de execução (seja uma VM, processo ou o que você tem). O link OSGi fornecido é a solução de Java para permitir isso.
Na prática, a OSGi será superada para a maioria das situações. Normalmente, é mais fácil enviar solicitações obsoletas para outro servidor ou processo.
A melhor maneira de "versão" de seus serviços, no entanto, é criar extensibilidade e flexibilidade para eles, de modo que permaneçam compatíveis e compatíveis. Isso não significa que todas as versões devem ser compatíveis entre si, mas as versões consecutivas devem ser compatíveis entre si.
Posso dizer-lhe que a solução de criar doAPIFunction, doAPIFunctionV2 e doAPIFunctionV3, etc, produziu apenas dores de cabeça no local em que trabalho. Adicione a isso a falta de nomes de funções claramente descritivos significa todo tipo de loucura.
Você quer nomes claros da função da API e, se uma api estiver mudando, o objetivo seria tentar fazê-lo de forma compatível com versões anteriores. Eu sugeriria a versão de seus pontos de entrada para que cada ponto de entrada ofereça suporte a API e doFunction estáveis em example. org/api-1.0/ pode ser diferente de example. org/api-2.0 se existisse uma boa razão para mudar a semântica.
Não tenho certeza se eu entendi sua pergunta corretamente. Mas meus 2 centavos. Se a assinatura do método muda como outro novo parâmetro, por que não pode ser feito opcional? Mas se um tipo de dados de parâmetro existente for alterado, não será aplicável.
Vote para isso se está errado. :)
Ele costumava ser mais simples quando você poderia ter o mesmo nome do método de serviço na web, e diferentes parâmetros, há anos. :)
Uma vez que você escreve um serviço na web, você está fazendo um contrato com os clientes que é isso que você apoiará.
Para métodos mais antigos, sugiro iniciar sessão para ver se eles estão sendo usados e por quem, para ver se você pode fazê-los atualizar.
Além disso, é melhor você simplesmente escrever um novo método, então você pode ter vários nomes de funções similares que diferem por uma versão.
O problema com a passagem de um número de versão é que você deve garantir que os clientes sempre passem num número válido, o que, se você gerar os talões, funcionará, mas, se não o fizer, isso é muito frágil.
Colocar um número de versão no nome parece funcionar melhor para mim, pois torna óbvio o que é antigo e você pode usar o AOP para registrar mais facilmente versões antigas dos métodos de serviço na web.
No comments:
Post a Comment