Em ALM com TFS / VSTS.
blogando sobre Gerenciamento do ciclo de vida do aplicativo com TFS / VSTS.
TFS Build 2018 & # 8230; e controle de versão!
Ultimamente tive algum tempo para jogar um pouco mais com o novo sistema de compilação que foi lançado com o TFS 2018 e que também está disponível para o Visual Studio Online. O novo sistema de compilação foi inicialmente anunciado como build vNext, mas agora com o lançamento do TFS 2018, é seguro chamá-lo de Team Foundation Build 2018 (TFBuild 2018) enquanto o & # 8220; old & # 8221; O sistema de compilação pode ser referido como o sistema de compilação xaml (workflow). Colin Dembovsky tem uma ótima publicação porque você deve mudar para o novo sistema de compilação.
Nos últimos anos, tive que implementar muitas personalizações no sistema de compilação xaml e tornei-me muito produtivo com as atividades de fluxo de trabalho. Ao longo do caminho, desenvolvi uma série de atividades genéricas que eu poderia reutilizar para outras tarefas e eu realmente conhecia meu caminho no fluxo de trabalho de compilação. Em muitos casos, as extensões de compilação TFS foram usadas para não reinventar a roda. Então, na primeira fase, fiquei um pouco cético sobre a ascensão de mais um sistema de construção, mas eu vi claramente algumas vantagens interessantes que são explicadas na publicação por Colin. Uma desvantagem do sistema de compilação xaml é a curva de aprendizado íngreme para dominar o processo de personalização e também o mecanismo de implantação para atualizar o (s) controlador (es) de compilação TFS. Mas, como eu experimentei, uma vez que você chegou lá, você conseguiu integrar personalizações muito poderosas no processo de compilação. De qualquer forma, o & # 8220; old & # 8221; O sistema de compilação não desapareceu e você ainda pode depender dessa funcionalidade por algum tempo no futuro, mas eu recomendo que tenha um bom visual no novo sistema de compilação e use-o para suas definições de compilação novas / futuras.
Nesta publicação, quero compartilhar a forma como eu integrado uma atividade comum no processo de compilação: Versão. Com as etapas de compilação disponíveis, tornou-se extremamente simples ligar seus próprios scripts ao processo de compilação. Nos scripts, você terá acesso a algumas variáveis de compilação predefinidas.
No meu blog anterior escrevi sobre a adoção de uma Estratégia de Versão Global e a existência de um terceiro atributo de versão (opcional): AssemblyInformationalVersion. Vamos usar esta estratégia para adicionar o controle de versão a uma amostra do aplicativo de software Fabrikam.
Minha definição de construção:
Na captura de tela acima, você verá que eu lanço um script powershell (PreBuild. ps1) antes de construir a solução e eu passo um argumento productVersion para o script. O script do powershell fará a magia em segundo plano para substituir todos os valores de versão para AssemblyVersion, AssemblyFileVersion e AssemblyInformationalVersion nos arquivos Assembly Info, com base nesta versão do produto. A versão do produto será passada como um todo aos atributos AssemblyVersion e AssemblyInformationalVersion. O AssemblyFileVersion será substituído por um número de versão completo que consistirá no número de versão maior e menor da versão do produto, uma data baseada em Julian e um número de compilação incremental.
Assembly File Version = 1.0.15236.3.
1 = & gt; tirado de & # 8220; Major & # 8221; versão do produto 0 = & gt; tirado de & # 8220; Minor & # 8221; versão do produto 15236 = & gt; gerado pelo processo de compilação: & # 8220; 15 & # 8221; = ano 2018, & # 8220; 236 & # 8221; = dia do ano 2018 3 = & gt; terceira compilação, executada no dia 236 no ano de 2018.
Analisar os detalhes da montagem de uma montagem Fabrikam feita sob encomenda agora revela meta dados corretos:
Também modifiquei o formato do número de compilação para ter mais informações de versão exibidas na execução de compilação.
Eu adicionei uma essência no GitHub para compartilhar o script do powershell. Observe que o script foi usado para experimentação e pode não estar pronto para ser usado para produção. Certamente, não há validação adequada e tratamento de erros. Use por sua conta e risco.
Também dê uma olhada em algumas postagens de blog inspiradoras semelhantes sobre versões do TFS Builds que me ajudaram a desenvolver o script powershell que funciona para o meu cenário.
Pós-navegação.
Deixe uma resposta Cancelar resposta.
Você está usando o termo Número de dia juliano incorretamente. O valor que você está referindo é chamado corretamente a Data Ordinal.
Eu atualizei do TFS 2018 para 2018, mas tenho problemas com o novo sistema de compilação, o novo agente não está tirando o mais recente do TFVC, compilações antigas do XAML e todas funcionam como esperado. Mesmo reparando o TFS, o problema não é resolvido. Parece ser um erro com o agente que não está funcionando corretamente.
Se eu manualmente fazer uma entrada para a pasta de compilação do agente antes de executar a compilação, defina as opções de limpeza como falso e ligue para o agente, tudo corre bem.
Além disso, se a pasta estiver vazia, a compilação falhará. Então, o que está acontecendo é que o agente não está conseguindo obter corretamente a versão mais recente do TFS, mesmo que mostre uma mensagem bem-sucedida no registro que não está baixando nada na pasta do mapa de destino.
Alguma ideia? Realmente aprecio o seu tempo!
Parece promissor, mas por que isso ainda é que as lojas precisam rolar suas próprias para & # 8230; certamente a maioria dos ISVs gostaria disso? Estou fascinado com o que o MS usa internamente.
Você poderia compartilhar seu postbuils. ps1? Quero saber como você registrou suas mudanças. Fyi, I & # 8217; m usando o controle de versão TFS.
Nenhum check-in de modificações. É o processo de compilação que está sempre a cargo para configurar o controle de versão. Não é necessário confirmar isso no controle de versão.
Coloquei seu PS em uma pasta de solução e configure o campo do nome de arquivo do script no passo de construção do powershell para apontar para ele, mas não executou. Ele diz Iniciar tarefa & # 8230; mas ainda não escreve mais nada no console e não atualiza a versão também. Mudei esse PS para o projeto e alterei o & # 8216; Copiar para o diretório de saída & # 8217; para & # 8216; copiar se mais novo & # 8217; e alterou o & # 8216; Script filename & # 8217; mas ainda não há diferença.
Eu segui o post do MSDN (msdn. microsoft/en-us/Library/vs/alm/Build/scripts/index) e ele está funcionando, mas eu prefiro o PS que você colocou aqui como aceitando o versão como um parâmetro. Eu acho que o problema é em como eu estou chamando seu. Você poderia compartilhar PreBuild. ps1?
O script do powershell que adicionei na essência do github está envolvido em uma função. Remova a função e funcionará bem & # 8230;
Confira este script que escrevi: ele aplica a versão dos arquivos de informações de montagem, mas também incrementa o número de compilação e verifica os arquivos de informações de montagem novamente no controle de origem:
Você tem uma solução para o indicador Missing build Quality in 2018 Builds? É uma questão importante em caso de gerenciamento do ciclo de vida. Como lidamos com isso em 2018?
Observe que usando yyDOY apresenta dois problemas de longo prazo:
& # 8211; O Century Bug (aka, Y2K), onde uma compilação em 2100 parecerá ser apresentada antes de uma compilação em 2099. Mas nós ganhamos, então, chegar tão longe, porque o & # 8230;
& # 8211; As compilações começarão a falhar em 2066, uma vez que o 66001 está além do limite UInt16.Max-1 para os componentes na versão Assembly e outros números.
As partes Maior e Menor da Versão da Assembléia e outros números são realmente uma decisão _design_ que deve ser implementada no código-fonte, não em tempo de implantação. Parece fazer mais sentido implementar esse design no código-fonte em vez do processo de compilação.
Nós ainda atualizaríamos o 3 * & amp; 4 partes durante o processo de construção, uma vez que é necessário um controle centralizado do incremento. Mas o Major & amp; Pequenas porções seriam retiradas do código fonte.
* A menos que você se mova para a versão semântica, que usa a 3ª porção como # 8220; Patch & # 8221; número. A escolha do & # 8220; Patch & # 8221; O número a usar também seria uma decisão _design_ a ser implementada no código-fonte.
Uma grande vantagem para esta abordagem é que você não precisa atualizar o parâmetro para o script PowerShell em sua Definição de Construção ao longo do tempo ou fornecer um valor correto para uma variável com cada requisição de compilação. As porções são definidas em código ou pelo próprio processo de compilação.
estratégia de versão do Tfs
Obter através da App Store Leia esta publicação em nosso aplicativo!
Estratégias de ramo e de mesclagem.
Fui encarregado de elaborar uma estratégia de ramificação, fusão e lançamento nos próximos 6 meses.
A complicação vem do fato de que estaremos executando vários projetos com diferentes mudanças de código e datas de lançamento diferentes, mas aproximadamente as mesmas datas de início de desenvolvimento.
No momento, estamos usando o VSS para gerenciamento de código, mas estamos conscientes de que provavelmente causará alguns problemas e estará migrando para o TFS antes do início do novo desenvolvimento.
Quais estratégias devo empregar e quais as coisas que eu deveria considerar antes de definir um plano?
Desculpe se isso é vago, sinta-se à vontade para fazer perguntas e atualizarei com mais informações, se necessário.
Este é o melhor padrão de controle de origem que encontrei. Ele enfatiza a importância de deixar o tronco livre de qualquer lixo (sem junk no tronco). O desenvolvimento deve ser feito em ramificações de desenvolvimento, e as fusões regulares (após o código ter sido testado) devem ser feitas de volta ao tronco (Pic 1), mas o modelo também permite que a fonte seja corrigida enquanto ainda está em desenvolvimento (Figura 2). Eu definitivamente recomendo ler o post na sua totalidade, para entender completamente.
Editar: as imagens são definitivamente confusas sem palavras. Eu poderia explicar, mas basicamente vou copiar o autor original. Dito isto, provavelmente deveria ter selecionado uma imagem melhor para descrever o processo de mesclagem, então espero que isso ajude. Eu ainda recomendaria ler o post, no entanto:
A maneira mais simples e mais comum que eu vi o trabalho de ramificação é de duas premissas. Tronco e lançamento. Eu acho que isso é conhecido como a filosofia do "tronco instável, estável".
Trunk é a sua principal fonte. Isso contém o código "mais recente e o maior" e está em frente. Geralmente nem sempre é estável.
Release é uma associação de um a muitos com o tronco. Há um tronco, mas muitos lançamentos que derivam do porta-malas. Os lançamentos geralmente começam com um ramo do tronco, uma vez que um marco de funcionalidade particular foi atingido, de modo que as "únicas" coisas que devem entrar para uma implantação específica devem ser apenas correções de bugs. Você então ramifica o tronco, dá-lhe um rótulo (por exemplo, versão 1.6 é a nossa última versão atual), crie e envie a versão para o controle de qualidade. Também empurra o número da versão (geralmente o número menor) do tronco neste ponto para garantir que não possamos duas versões com o mesmo número.
Em seguida, você inicia o ciclo de teste em seu ramo de lançamento. Quando testes suficientes foram aplicados, aplique correções de bugs para o ramo de lançamento, junte-os de volta ao tronco (para garantir que as correções de bugs sejam levadas adiante!) E, em seguida, re-lançar uma compilação do ramo. Este ciclo com QA continua até que ambos estejam felizes e a versão finalmente seja dada ao (s) cliente (s). Qualquer relatório de erro do (s) cliente (s) que são precisos (ou seja, são um bug!) Comece outro ciclo de QA com o ramo em questão.
À medida que você cria versões futuras, é uma boa idéia também tentar mover os clientes mais antigos para os ramos mais recentes para reduzir o número potencial de filiais que você pode ter para corrigir uma correção de erros.
Usando esta técnica, você pode implantar soluções usando sua tecnologia para uma variedade de clientes que exigem diferentes níveis de serviço (começando pelo menos primeiro), você pode isolar suas implantações existentes do novo código "perigoso" no tronco e o pior cenário de mesclagem é um ramo.
A minha primeira recomendação seria ler o HOWTO de Controle de Origem de Eric Sink - especificamente os capítulos de fusão e fusão.
Temos 3 contentores - DEV, MAIN e RELEASE para o nosso trabalho. O MAIN contém todo o código "pronto para liberar" e tendemos a pensá-lo como "basicamente estável". DEV / Iteration (ou DEV / Feature, ou DEV / RiskyFeatureThatMightBreakSomeoneElse) são ramificações do MAIN e são mescladas quando o Iteration / Feature está pronto para promover o passado do ambiente DEV. Também temos compilações TFS configuradas a partir do ramo DEV / Iteration e do ramo MAIN.
Nosso contêiner RELEASE contém lançamentos numerados (semelhante ao contêiner "tags" usado em muitos repositórios do Subversion). Simplesmente tomamos um ramo da MAIN a cada vez - eu gosto de dizer que estamos "cortando" um ramo de LIBERTAÇÃO para significar que isso não deve ter muita atividade acontecendo quando a mesclagem for concluída.
Quanto ao VSS-> TFS - a Microsoft aceita um caminho de atualização que deve manter o histórico da sua versão, mas se você não precisar do histórico, eu simplesmente obteria a versão mais recente do VSS, verificá-lo no TFS e arquivar o repositório VSS.
Uma dica final - informe os membros da sua equipe do controle de origem. Eles devem entender ramificação e fusão ou você estará preso fazendo um monte de trabalho de limpeza :).
O livro de subversão descreve alguns padrões comuns de ramificação. Talvez você também possa aplicá-los ao TFS.
Em ALM com TFS / VSTS.
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 2018; & # 8220; 234 & # 8221; = número do dia em 2018; & # 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, falarei sobre como você pode alcançar essa estratégia global de versão com o novo sistema de compilação no TFS 2018.
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 + 20180313144700 & # 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 do Tfs
Obter através da App Store Leia esta publicação em nosso aplicativo!
Versões de versões.
Perguntando-se sobre qual é a melhor abordagem para a versão de compilações?
TFS 2018 para controle de versão TFS gated check-ins Wix 3.8 para codificar o pacote para arquivos MSI.
Eu quero configurar a versão de:
assemblies (AssemblyInfo. cs ou um compartilhado referenciado em todos os projetos) documentação MSI (em código Wix) (por exemplo, dentro do arquivo readme. txt na saída final da compilação) etc.
O número de versão ideal permitiria rastrear o software instalado de volta ao código-fonte exato.
Primeiras 2 partes da versão que eu quero armazenar em algum texto simples \ arquivo XML no controle de versão perto da solução, pois acredito que eles devem viver juntos. Os desenvolvedores atualizarão este arquivo manualmente (por exemplo, seguindo a abordagem Semantic Versioning). Cada compilação lerá este arquivo de versão, obterá parte da versão em 3D da ferramenta CI de chamada e atualizará todos os arquivos necessários com a versão.
Qual é a melhor maneira de implementar isso?
Eu usei algumas abordagens no passado:
1) NAnt \ MsBuild wrapper que esta versão funciona, em seguida, chama MsBuild para a solução. Pode ser chamado a partir da ferramenta CI (Jenkins \ TeamCity \ etc).
Problema - a integração com TFS fechado check-in é feia como eu construir uma solução duas vezes.
2) personalize o modelo de processo de compilação TFS.
Problema - não é tão simples e causa algum trabalho de mesclagem nas atualizações TFS. Também o número de conjunto de alterações ainda não existe nos check-in fechados, portanto, podemos usar apenas o id anterior das mudanças.
3) Um projeto separado da MsBuild em solução, que faz somente essa tarefa de versão, e está configurado para executar primeiro no Project Build Order da solução VS.
Problema - precisa referenciar este meta-projeto em todos os outros projetos (incluindo todos os futuros) que se sentem feios.
Conheço diferentes pacotes de extensão MsBuild e TFS que podem simplificar as atualizações. Este tópico não é sobre qual é o melhor. A questão é mais metodológica do que técnica.
Eu também acho que seria ideal se a Microsoft incluir algo para a versão em seu modelo de compilação TFS padrão. Outras ferramentas CI já possuem essa funcionalidade (AssemblyInfo patcher).
Eu decidi expressar claramente os Princípios de Versões que se ajustariam às melhores práticas de Agile \ Continuous Delivery:
1) Capacidade de reproduzir qualquer construção histórica.
2) Como conseqüência de 1) e de acordo com princípios de CD, tudo (código-fonte, testes, configurações de aplicativos, configurações de env, compilação \ pacote \ implantar scripts, etc.) é armazenado sob controle de versão e, portanto, tem uma versão atribuída a ele.
3) O número da versão é armazenado firmemente em conjunto com o código-fonte ao qual se aplica.
4) As pessoas podem atualizar a versão de acordo com suas lógicas de negócios \ marketing.
5) Existe apenas uma cópia mestre da versão, que é usada em todas as partes do processo automatizado de compilação \ empacotamento.
6) Você pode facilmente dizer qual versão do software está atualmente instalada no sistema de destino.
7) A versão do software instalado deve identificar inequivocamente o código-fonte que foi usado para compilá-lo.
8) É muito simples comparar as versões para dizer qual é menor e qual é maior - para controlar quais cenários de atualização / downgrade são permitidos e especificações de implementação deles.
Veja a minha própria resposta abaixo.
Eu tive a sorte de encontrar a solução que atende todos os meus requisitos!
Bom sofrimento, todas essas respostas complicadas.
No TFS 2018, isso é simples. O site Community TFS Build Extensions oferece um PowerShell simples para puxar o número de compilação a partir do nome de compilação atribuído pelo TFS.
Você configura seu formato de número de compilação para ser "$ (BuildDefinitionName) _6.0.0 $ (Rev:.r)", o que resultará em algo como "6.0.0.1" onde o "1" é incrementado para cada compilação.
Em seguida, adicione o script de versão do PowerShell à sua compilação e ele raspa automaticamente o número da versão acima e aplica-o a todos os arquivos AssemblyInfo. * Na pasta de compilação. Você pode adicionar tipos de arquivo adicionais atualizando o script.
Eu encontrei uma solução que atende todos os meus requisitos, e surpreendentemente bastante simples!
Coloque todo o Versioning personalizado em um script Version. proj MsBuild personalizado e ligue-o na definição de compilação TFS antes do. sln. O script injeta a versão no código-fonte (SharedAssemblyInfo. cs, código Wix, readme. txt) e, em seguida, a compilação da solução cria esse código-fonte.
A versão é formada por números maiores e menores que vivem no arquivo Version. xml armazenado em TFS juntamente com os códigos-fonte; e de Changeset Number fornecido como TF_BUILD_SOURCEGETVERSION env var pelo processo de compilação TFS original.
Agradecemos a Microsoft por isso:
TFS 2018 - passa as variáveis de ambiente TF_BUILD para o processo de compilação, é assim que eu obtenho o número do conjunto de alterações do código atual que está sendo criado. MsBuild permite tarefas inline em C # - para substituir a versão em arquivos de origem usando a classe Regex C #.
Portanto, não há necessidade de usar qualquer MsBuild ou TFS community \ extension packs \ addons \ whatever. E não há necessidade de modificar o modelo de processo de compilação TFS padrão. Solução simples leva a alta capacidade de manutenção!
Injetar o número do Changeset é ótimo, mas realmente não faz tudo o que preciso. Por exemplo, se eu conheço o número do conjunto de mudanças de uma compilação produzida pelo meu sistema de compilação, eu realmente sei o que há nesse executável? Não, não, como a compilação poderia ter sido uma compilação privada, ou mesmo uma compilação falhada.
Nós colocamos nossa confiança no número de compilação (BuildID, realmente) em vez disso, para que possamos obter tantos dados sobre essa compilação quanto possível consultando o sistema TFS após o fato. Desta forma, podemos determinar se a compilação era uma compilação privada, era uma compilação que tinha parâmetros de linha de comando especiais passados para ela e outros detalhes pertinentes.
Usamos a seguinte configuração:
Defina o formato de compilação na definição de compilação para ser algo como: 1.0.0. $ (BuildId)
No modelo de processo de compilação, na tarefa MSBuild, injete o seguinte ao item MSBuildArguments. Certifique-se de deixar o que já estava lá.
Em seus projetos (ou, idealmente, um arquivo de suporte comum incluído em todos os seus projetos) definiu uma propriedade chamada número de compilação que padrão é algo como 0.0.0.1. note que você pode quebrar isso, porém, você gosta de usar as funções de propriedade. Usamos isso para obter o número principal por exemplo: e sim, isso coloca uma dependência no formato do número de compilação em nossas compilações!
No seu projeto, você pode usar a propriedade do número de compilação para injetar vários arquivos durante o tempo de compilação. Você pode usar tarefas de compilação personalizadas (eu uso 'sed' e essa macro para injetar um número de versão em um arquivo. h por exemplo - o mesmo pode ser feito com qualquer tipo de arquivo baseado em texto).
Se você tiver requisitos de versão mais completos, você pode usar os destinos MSBuild personalizados que injetaram o número de compilação em outros tipos de arquivo. Eu fiz exatamente isso com o controle de versão para pacotes NuGet que nossas compilações criam automaticamente para nossos projetos CS de biblioteca comum, por exemplo.
Para consultar uma compilação por seu número de compilação, você pode fazer o seguinte no PowerShell (com as Ferramentas elétricas do Visual Studio Team Foundation Server instaladas):
Com o '$ bld', agora você pode consultar todas as propriedades dessa construção específica. Por exemplo, para ver o que o conjunto de mudanças foi construído, o status da compilação, quem instigou a compilação e, se houvesse um shelveset para a compilação:
Editar: corrigir o erro de digitação no script Powershell.
Eu baixei este script (graças à resposta de MrHinsh), verifiquei o script no controle de origem e o especifiquei no caminho de script de pré-compilação de definição de compilação:
Então eu configurei o formato de número de compilação como "$ (BuildDefinitionName) _1.0.0 $ (Rev:.r)" (veja a resposta de MrHinsh para detalhes).
E isso é para minha surpresa.
Estou trabalhando em um projeto que tenha requisitos semelhantes, mas não idênticos. As versões maiores e menores são mantidas no AssemblyInfo, como qualquer projeto padrão as teria. No nosso servidor de compilação, temos um script wrapper MsBuild que invoca a compilação. sln, mas também faz algumas tarefas de configuração, incluindo a geração de informações de compilação adicionais. Este arquivo de compilação só é executado em nosso servidor de compilação. Os desenvolvedores que desenvolvem o Visual Studio só criarão o. sln e não obterão esse comportamento adicional.
Temos um requisito semelhante e utilizamos a TAREFA NANT ASMINFO. Durante a compilação TFS invocamos esse destino adicional NANT que cria um novo arquivo AssemblyVersion. cs.
Anote a propriedade $, que é realmente definida com base em sua exigência. Em seguida, seguimos os arquivos Assemblyversion. cs existentes e fazemos que eles sejam lidos somente e, em seguida, substituí-lo pelo novo arquivo que criamos.
Como você pode saber, esse alvo é executado antes da compilação.
Eu uso [Major]. [Menor]. [BuildNumber]. [Revisão]
Posso então rastrear de volta para uma compilação, que dará um conjunto de alterações, que dará um item de trabalho, etc.
Você pode usar as tarefas de construção da comunidade ou eu rolo o meu próprio.
Eu faço o mesmo para MSI e DacPac's.
basicamente atribua o arquivo assemblyinfo e, em seguida, atualize o número usando um regex, em uma compilação diária deixe a versão líquida no mesmo valor e apenas atualize a versão do arquivo, para que você possa manter a compatibilidade.
Implementando uma Estratégia de Versão.
O controle de versão é o ato de atualizar a implementação de um artefato e incrementar seu número de versão.
O controle de versão do aplicativo BizTalk pode se tornar um problema quando você precisa executar duas versões de uma solução BizTalk lado a lado, ou se você não pode agendar o tempo de inatividade do aplicativo BizTalk para implantar uma nova versão. Se você não precisa executar duas versões da solução simultaneamente (por exemplo, se você não possui orquestrações de longa duração), então é perfeitamente aceitável implantar a versão antiga e implementar a nova versão como uma estratégia de controle de versão (sem versão de montagem ). Esta é uma possível estratégia de versão, embora ainda recomendamos incrementar o número da versão do arquivo (para que você saiba qual versão é implantada nos servidores BizTalk). Para obter mais informações sobre como atualizar um aplicativo implantado, consulte Lista de verificação: atualizando um assembly.
Se você precisar suportar orquestrações de longa duração e / ou precisar executar implantações de aplicativos do BizTalk sem tempo de inatividade do aplicativo BizTalk, então uma estratégia de controle de versão sólida do BizTalk precisa ser implementada e praticada de ponta a ponta para os diferentes cenários de versão. Isso inclui controle de versão e versão de montagem de todos os artefatos BizTalk. Isso inclui esquemas, mapas, pipelines, componentes de pipeline, orquestrações, adaptadores personalizados, classes personalizadas chamadas em orquestrações e mapas, regras de negócios e BAM. Para obter mais informações sobre o controle de versão lado a lado, consulte Atualizando usando a versão Side-by-Side.
Quando você atualiza uma montagem, você pode escolher entre o seguinte:
Escolhendo uma versão de montagem fixa para um determinado fornecimento e incrementando apenas o número da versão do arquivo.
Essas abordagens são comparadas na tabela a seguir:
Número da versão da montagem = número fixo.
Número da versão do arquivo = Número da compilação.
Número da versão Assembly = Número da compilação.
Número da versão do arquivo = Número da compilação.
O tempo de execução do BizTalk Server pode escolher a versão errada do assembly se várias montagens estiverem instaladas.
O BizTalk Server sempre executa a versão mais recente da montagem, mesmo que várias montagens estejam instaladas.
Only one version of the solution can be deployed at any time.
Different versions of the solution can be deployed side by side (although other aspects of the solution, such as schema definitions, may conflict).
BizTalk Host needs to be restarted to force the loading of updated assemblies.
Forces BizTalk Server to load new assemblies.
Requires less work to create a new deployment because files that reference the assembly version number (for example, binding files and tracking profiles) do not need to be edited.
Requires more work for deployment because files that reference the assembly version number need to be kept updated with the new version.
You may choose to use the fixed assembly version and dynamic file version approach if you are prototyping a system or developing any other type of project that will not be released. If you do not intend to deliver the application to an end user, you can streamline deployment tasks and reduce broken dependencies by fixing the assembly version and incrementing the file version number. For version tracking, you must remember to increment the file version number for each build.
Obter através da App Store Leia esta publicação em nosso aplicativo!
Versões de versões.
Perguntando-se sobre qual é a melhor abordagem para a versão de compilações?
TFS 2018 para controle de versão TFS gated check-ins Wix 3.8 para codificar o pacote para arquivos MSI.
Eu quero configurar a versão de:
assemblies (AssemblyInfo. cs ou um compartilhado referenciado em todos os projetos) documentação MSI (em código Wix) (por exemplo, dentro do arquivo readme. txt na saída final da compilação) etc.
O número de versão ideal permitiria rastrear o software instalado de volta ao código-fonte exato.
Primeiras 2 partes da versão que eu quero armazenar em algum texto simples \ arquivo XML no controle de versão perto da solução, pois acredito que eles devem viver juntos. Os desenvolvedores atualizarão este arquivo manualmente (por exemplo, seguindo a abordagem Semantic Versioning). Cada compilação lerá este arquivo de versão, obterá parte da versão em 3D da ferramenta CI de chamada e atualizará todos os arquivos necessários com a versão.
Qual é a melhor maneira de implementar isso?
Eu usei algumas abordagens no passado:
1) NAnt \ MsBuild wrapper que esta versão funciona, em seguida, chama MsBuild para a solução. Pode ser chamado a partir da ferramenta CI (Jenkins \ TeamCity \ etc).
Problema - a integração com TFS fechado check-in é feia como eu construir uma solução duas vezes.
2) personalize o modelo de processo de compilação TFS.
Problema - não é tão simples e causa algum trabalho de mesclagem nas atualizações TFS. Também o número de conjunto de alterações ainda não existe nos check-in fechados, portanto, podemos usar apenas o id anterior das mudanças.
3) Um projeto separado da MsBuild em solução, que faz somente essa tarefa de versão, e está configurado para executar primeiro no Project Build Order da solução VS.
Problema - precisa referenciar este meta-projeto em todos os outros projetos (incluindo todos os futuros) que se sentem feios.
Conheço diferentes pacotes de extensão MsBuild e TFS que podem simplificar as atualizações. Este tópico não é sobre qual é o melhor. A questão é mais metodológica do que técnica.
Eu também acho que seria ideal se a Microsoft incluir algo para a versão em seu modelo de compilação TFS padrão. Outras ferramentas CI já possuem essa funcionalidade (AssemblyInfo patcher).
Eu decidi expressar claramente os Princípios de Versões que se ajustariam às melhores práticas de Agile \ Continuous Delivery:
1) Capacidade de reproduzir qualquer construção histórica.
2) Como conseqüência de 1) e de acordo com princípios de CD, tudo (código-fonte, testes, configurações de aplicativos, configurações de env, compilação \ pacote \ implantar scripts, etc.) é armazenado sob controle de versão e, portanto, tem uma versão atribuída a ele.
3) O número da versão é armazenado firmemente em conjunto com o código-fonte ao qual se aplica.
4) As pessoas podem atualizar a versão de acordo com suas lógicas de negócios \ marketing.
5) Existe apenas uma cópia mestre da versão, que é usada em todas as partes do processo automatizado de compilação \ empacotamento.
6) Você pode facilmente dizer qual versão do software está atualmente instalada no sistema de destino.
7) A versão do software instalado deve identificar inequivocamente o código-fonte que foi usado para compilá-lo.
8) É muito simples comparar as versões para dizer qual é menor e qual é maior - para controlar quais cenários de atualização / downgrade são permitidos e especificações de implementação deles.
Veja a minha própria resposta abaixo.
Eu tive a sorte de encontrar a solução que atende todos os meus requisitos!
Bom sofrimento, todas essas respostas complicadas.
No TFS 2018, isso é simples. O site Community TFS Build Extensions oferece um PowerShell simples para puxar o número de compilação a partir do nome de compilação atribuído pelo TFS.
Você configura seu formato de número de compilação para ser "$ (BuildDefinitionName) _6.0.0 $ (Rev:.r)", o que resultará em algo como "6.0.0.1" onde o "1" é incrementado para cada compilação.
Em seguida, adicione o script de versão do PowerShell à sua compilação e ele raspa automaticamente o número da versão acima e aplica-o a todos os arquivos AssemblyInfo. * Na pasta de compilação. Você pode adicionar tipos de arquivo adicionais atualizando o script.
Eu encontrei uma solução que atende todos os meus requisitos, e surpreendentemente bastante simples!
Coloque todo o Versioning personalizado em um script Version. proj MsBuild personalizado e ligue-o na definição de compilação TFS antes do. sln. O script injeta a versão no código-fonte (SharedAssemblyInfo. cs, código Wix, readme. txt) e, em seguida, a compilação da solução cria esse código-fonte.
A versão é formada por números maiores e menores que vivem no arquivo Version. xml armazenado em TFS juntamente com os códigos-fonte; e de Changeset Number fornecido como TF_BUILD_SOURCEGETVERSION env var pelo processo de compilação TFS original.
Agradecemos a Microsoft por isso:
TFS 2018 - passa as variáveis de ambiente TF_BUILD para o processo de compilação, é assim que eu obtenho o número do conjunto de alterações do código atual que está sendo criado. MsBuild permite tarefas inline em C # - para substituir a versão em arquivos de origem usando a classe Regex C #.
Portanto, não há necessidade de usar qualquer MsBuild ou TFS community \ extension packs \ addons \ whatever. E não há necessidade de modificar o modelo de processo de compilação TFS padrão. Solução simples leva a alta capacidade de manutenção!
Injetar o número do Changeset é ótimo, mas realmente não faz tudo o que preciso. Por exemplo, se eu conheço o número do conjunto de mudanças de uma compilação produzida pelo meu sistema de compilação, eu realmente sei o que há nesse executável? Não, não, como a compilação poderia ter sido uma compilação privada, ou mesmo uma compilação falhada.
Nós colocamos nossa confiança no número de compilação (BuildID, realmente) em vez disso, para que possamos obter tantos dados sobre essa compilação quanto possível consultando o sistema TFS após o fato. Desta forma, podemos determinar se a compilação era uma compilação privada, era uma compilação que tinha parâmetros de linha de comando especiais passados para ela e outros detalhes pertinentes.
Usamos a seguinte configuração:
Defina o formato de compilação na definição de compilação para ser algo como: 1.0.0. $ (BuildId)
No modelo de processo de compilação, na tarefa MSBuild, injete o seguinte ao item MSBuildArguments. Certifique-se de deixar o que já estava lá.
Em seus projetos (ou, idealmente, um arquivo de suporte comum incluído em todos os seus projetos) definiu uma propriedade chamada número de compilação que padrão é algo como 0.0.0.1. note que você pode quebrar isso, porém, você gosta de usar as funções de propriedade. Usamos isso para obter o número principal por exemplo: e sim, isso coloca uma dependência no formato do número de compilação em nossas compilações!
No seu projeto, você pode usar a propriedade do número de compilação para injetar vários arquivos durante o tempo de compilação. Você pode usar tarefas de compilação personalizadas (eu uso 'sed' e essa macro para injetar um número de versão em um arquivo. h por exemplo - o mesmo pode ser feito com qualquer tipo de arquivo baseado em texto).
Se você tiver requisitos de versão mais completos, você pode usar os destinos MSBuild personalizados que injetaram o número de compilação em outros tipos de arquivo. Eu fiz exatamente isso com o controle de versão para pacotes NuGet que nossas compilações criam automaticamente para nossos projetos CS de biblioteca comum, por exemplo.
Para consultar uma compilação por seu número de compilação, você pode fazer o seguinte no PowerShell (com as Ferramentas elétricas do Visual Studio Team Foundation Server instaladas):
Com o '$ bld', agora você pode consultar todas as propriedades dessa construção específica. Por exemplo, para ver o que o conjunto de mudanças foi construído, o status da compilação, quem instigou a compilação e, se houvesse um shelveset para a compilação:
Editar: corrigir o erro de digitação no script Powershell.
Eu baixei este script (graças à resposta de MrHinsh), verifiquei o script no controle de origem e o especifiquei no caminho de script de pré-compilação de definição de compilação:
Então eu configurei o formato de número de compilação como "$ (BuildDefinitionName) _1.0.0 $ (Rev:.r)" (veja a resposta de MrHinsh para detalhes).
E isso é para minha surpresa.
Estou trabalhando em um projeto que tenha requisitos semelhantes, mas não idênticos. As versões maiores e menores são mantidas no AssemblyInfo, como qualquer projeto padrão as teria. No nosso servidor de compilação, temos um script wrapper MsBuild que invoca a compilação. sln, mas também faz algumas tarefas de configuração, incluindo a geração de informações de compilação adicionais. Este arquivo de compilação só é executado em nosso servidor de compilação. Os desenvolvedores que desenvolvem o Visual Studio só criarão o. sln e não obterão esse comportamento adicional.
Temos um requisito semelhante e utilizamos a TAREFA NANT ASMINFO. Durante a compilação TFS invocamos esse destino adicional NANT que cria um novo arquivo AssemblyVersion. cs.
Anote a propriedade $, que é realmente definida com base em sua exigência. Em seguida, seguimos os arquivos Assemblyversion. cs existentes e fazemos que eles sejam lidos somente e, em seguida, substituí-lo pelo novo arquivo que criamos.
Como você pode saber, esse alvo é executado antes da compilação.
Eu uso [Major]. [Menor]. [BuildNumber]. [Revisão]
Posso então rastrear de volta para uma compilação, que dará um conjunto de alterações, que dará um item de trabalho, etc.
Você pode usar as tarefas de construção da comunidade ou eu rolo o meu próprio.
Eu faço o mesmo para MSI e DacPac's.
basicamente atribua o arquivo assemblyinfo e, em seguida, atualize o número usando um regex, em uma compilação diária deixe a versão líquida no mesmo valor e apenas atualize a versão do arquivo, para que você possa manter a compatibilidade.
Implementando uma Estratégia de Versão.
O controle de versão é o ato de atualizar a implementação de um artefato e incrementar seu número de versão.
O controle de versão do aplicativo BizTalk pode se tornar um problema quando você precisa executar duas versões de uma solução BizTalk lado a lado, ou se você não pode agendar o tempo de inatividade do aplicativo BizTalk para implantar uma nova versão. Se você não precisa executar duas versões da solução simultaneamente (por exemplo, se você não possui orquestrações de longa duração), então é perfeitamente aceitável implantar a versão antiga e implementar a nova versão como uma estratégia de controle de versão (sem versão de montagem ). Esta é uma possível estratégia de versão, embora ainda recomendamos incrementar o número da versão do arquivo (para que você saiba qual versão é implantada nos servidores BizTalk). Para obter mais informações sobre como atualizar um aplicativo implantado, consulte Lista de verificação: atualizando um assembly.
Se você precisar suportar orquestrações de longa duração e / ou precisar executar implantações de aplicativos do BizTalk sem tempo de inatividade do aplicativo BizTalk, então uma estratégia de controle de versão sólida do BizTalk precisa ser implementada e praticada de ponta a ponta para os diferentes cenários de versão. Isso inclui controle de versão e versão de montagem de todos os artefatos BizTalk. Isso inclui esquemas, mapas, pipelines, componentes de pipeline, orquestrações, adaptadores personalizados, classes personalizadas chamadas em orquestrações e mapas, regras de negócios e BAM. Para obter mais informações sobre o controle de versão lado a lado, consulte Atualizando usando a versão Side-by-Side.
Quando você atualiza uma montagem, você pode escolher entre o seguinte:
Escolhendo uma versão de montagem fixa para um determinado fornecimento e incrementando apenas o número da versão do arquivo.
Essas abordagens são comparadas na tabela a seguir:
Número da versão da montagem = número fixo.
Número da versão do arquivo = Número da compilação.
Número da versão Assembly = Número da compilação.
Número da versão do arquivo = Número da compilação.
O tempo de execução do BizTalk Server pode escolher a versão errada do assembly se várias montagens estiverem instaladas.
O BizTalk Server sempre executa a versão mais recente da montagem, mesmo que várias montagens estejam instaladas.
Only one version of the solution can be deployed at any time.
Different versions of the solution can be deployed side by side (although other aspects of the solution, such as schema definitions, may conflict).
BizTalk Host needs to be restarted to force the loading of updated assemblies.
Forces BizTalk Server to load new assemblies.
Requires less work to create a new deployment because files that reference the assembly version number (for example, binding files and tracking profiles) do not need to be edited.
Requires more work for deployment because files that reference the assembly version number need to be kept updated with the new version.
You may choose to use the fixed assembly version and dynamic file version approach if you are prototyping a system or developing any other type of project that will not be released. If you do not intend to deliver the application to an end user, you can streamline deployment tasks and reduce broken dependencies by fixing the assembly version and incrementing the file version number. For version tracking, you must remember to increment the file version number for each build.
No comments:
Post a Comment