Melhor solução de processo de construção para gerenciar versões de construção

Question

Dirijo um projeto bastante complexo com vários aplicativos independentes.No entanto, eles usam alguns componentes compartilhados.Então, eu tenho uma árvore de origem parecida com a abaixo.

• Meu projeto
  • Aplicação A
  • Compartilhado1
  • Compartilhado2
  • Aplicação B
  • Aplicação C

Todos os aplicativos têm seu próprio script MSBuild que cria o projeto e todos os recursos compartilhados necessários.Eu também executo essas compilações em um servidor de compilação de integração contínua controlado pelo CruiseControl.

Quando os aplicativos são implantados, eles são implantados em vários servidores para distribuir a carga.Isto significa que é extremamente É importante acompanhar qual build/revisão está implantada em cada um dos diferentes servidores (precisamos ter a versão atual na versão DLL, por exemplo “1.0.0.68”).

É igualmente importante ser capaz de recriar uma revisão/construção que foi construída para poder reverter se algo não funcionar como esperado (sim, isso acontece...).Hoje estamos usando o SourceSafe para controle de origem, mas isso pode mudar se pudermos apresentar boas razões para isso (SS está realmente funcionando bem para nós então distante).

Outro princípio que tentamos seguir é que apenas o código que foi construído e testado pelo servidor de integração é que implantamos posteriormente.

Solução "CrusieControl Build Labels"

Tínhamos várias ideias para resolver o problema acima.A primeira foi construir o servidor de integração contínua, implantar localmente o projeto e testá-lo (isso é feito agora).Como você provavelmente sabe, uma compilação bem-sucedida no CruiseControl gera um rótulo de compilação e acho que de alguma forma poderíamos usá-lo para definir a versão DLL de nossos executáveis ​​(então o rótulo de compilação 35 criaria uma DLL como “1.0.0.35”).A ideia também era usar esse rótulo de construção para rotular o completo árvore de origem.Então provavelmente poderíamos verificar esse rótulo e recriar a compilação mais tarde.

A razão para rotular a árvore completa é incluir não apenas o código real do aplicativo (que está em um local na árvore de origem), mas também todos os itens compartilhados (que estão em locais diferentes na árvore).Portanto, uma construção bem-sucedida do “Aplicativo A” rotularia toda a árvore com o rótulo “ApplicationA35”, por exemplo.

No entanto, pode haver um problema ao tentar recriar esta compilação e definir a versão DLL antes da implantação, pois não teremos mais acesso ao rótulo de compilação gerado pelo CruiseControl.Se todos os rótulos de construção do CrusieControl fossem exclusivos para todos os projetos, poderíamos usar apenas o número para rotulagem, mas esse não é o caso (ambos os aplicativos A e B poderiam estar ao mesmo tempo na compilação 35), então temos que incluir o nome do aplicativo no rótulo.Daí o rótulo SourceSafe “Application35”. Como posso recriar o build 34 e definir 1.0.0.34 para os números de versão da DLL depois de construirmos o build 35?

Solução "Número de revisão"

Alguém me disse que o Subversion, por exemplo, cria um número de revisão para toda a árvore de origem em cada check-in – é este o caso?O SourceSafe tem algo semelhante? Se isso estiver correto, a ideia é pegar esse número de revisão ao obter a versão mais recente e compilar no servidor CruiseControl.O número de revisão poderia então ser usado para definir o número da versão da DLL (por exemplo, “1.0.0.5678”).Acho que poderíamos obter esta revisão específica para o Subversion, se necessário, e isso incluiria esse aplicativo e todos os itens compartilhados para poder recriar uma versão específica do passado. Isso funcionaria e também poderia ser conseguido usando o SourceSafe?

Resumir

Portanto, os dois requisitos principais são:

1. Ser capaz de rastreie o número de compilação/revisão da compilação e da DLL implantada.
2. Ser capaz de reconstruir uma revisão/compilação anterior, definir o número de compilação/revisão antigo nos executáveis ​​dessa compilação (para cumprir o requisito 1).

Então, como você resolveria isso? Qual seria sua abordagem preferida e como você resolveria (ou tem uma ideia totalmente diferente?)?**Por favor, dê respostas detalhadas.**

Pergunta bônus Qual é a diferença entre um número de revisão e um número de compilação e quando seria realmente necessário ambos?

Answer 1

Seu esquema é sólido e viável no VSS (embora eu sugira que você considere uma alternativa, o VSS é realmente um produto desatualizado).

Para o seu build "CI" - você faria o controle de versão, dê uma olhada em Projeto de tarefas da comunidade MSBuild que tem tarefas de "Versão".Normalmente você terá um "Version.txt" em sua árvore de origem e a tarefa MSBuild incrementará o número "Release" enquanto os desenvolvedores controlam os números Major.Minor.Release.Revision (é assim que um cliente meu queria).Você pode usar a revisão se preferir.

Você então teria uma tarefa "FileUpdate" para editar o arquivo AssemblyInfo.cs com essa versão, e seus EXE e "DLL" terão a versão desejada.

Finalmente, a tarefa VSSLabel rotulará todos os seus arquivos adequadamente.

Para sua compilação "Reconstruir" - você modificaria seu "Get" para obter arquivos desse rótulo, obviamente não executaria a tarefa "Versão" (pois você está SELECIONANDO uma versão para compilar) e então as tarefas FileUpdate usariam esse número de versão.

Pergunta bônus:

Tudo isso é "como você deseja usá-los" - eu usaria o número da compilação, bem, o número da compilação, é isso que eu incrementaria.Se você estiver usando CI, terá muitas compilações - a grande maioria sem intenção de implantar em qualquer lugar.

O maior e o menor são evidentes - mas a revisão sempre usei para um indicador de "Hotfix".Pretendo ter uma versão "1.3" - que na realidade seria um produto com a versão 1.3.1234.0, digamos.Enquanto trabalhava no 1.4 - encontrei um bug - e preciso de um hot fix como 1.3.2400.1.Então, quando 1.4 estiver pronto - seria, digamos, 1.4.3500.0

Answer 2

Preciso de mais espaço do que responder, pois os comentários permitem diretamente...

Obrigado!Boa resposta!Qual seria a diferença, o que seria melhor resolver isso usando a subversão, por exemplo? Richard Hallgren (15 horas atrás)

Os problemas com o VSS não têm nada a ver com este exemplo (embora acredito que o recurso "Rotulagem" seja implementado de forma ineficiente ...)

Aqui estão alguns dos problemas com o VSS

1) A ramificação é basicamente impossível 2) O check -out compartilhado geralmente não é usado (conheço algumas pessoas que tiveram sucesso com ele) 3) O desempenho é muito ruim - é extermidamente "falador" 4), a menos que você tenha um repositório muito pequeno - É completamente não confiável, a ponto de a maioria das lojas que é um timebomb.

Para 4 - o problema é que o VSS é implementado por todo o repositório sendo representado como "arquivos simples" no sistema de arquivos.Quando o repositório ultrapassa um determinado tamanho (acredito que 4 GB, mas não estou confiante nesse número), você tem uma chance de "corrupção".À medida que o tamanho aumenta as chances de corrupção crescem até se tornar quase uma certeza.

Portanto, dê uma olhada no tamanho do seu repositório - e se você estiver usando Gigabytes - eu recomendo fortemente que você comece a planejar a substituição do VSS.

Independentemente disso - um google de "VSS Sucks" dá 30 mil acessos...Acho que se você começar a usar uma alternativa, perceberá que vale a pena o esforço.

Answer 3

1. Faça com que CC.net rotule as compilações bem-sucedidas
2. faça com que cada projeto na solução seja vinculado a um arquivo Solutioninfo.cs comum que contém atributos de montagem e versão do arquivo (remova de cada projeto assemblyinfo.cs)
3. Antes da compilação, o Cruise Control execute uma substituição de regex msbuild (das tarefas da comunidade msbuild) para atualizar as informações da versão usando o rótulo de compilação cc.net (passado como parâmetro para a tarefa msbuild)
4. construir a solução, executar testes, FX Cop etc.
5. Opcionalmente, reverta o arquivo de informações da solução

O resultado é que todos os assemblies na compilação publicada do cc.net têm os mesmos números de versão que estão em conformidade com um rótulo no repositório do código-fonte

Answer 4

UppercuT pode fazer tudo isso com uma tarefa de empacotamento personalizado para dividir os aplicativos.E para obter o número da versão da fonte, você pode pensar no Subversion.

Também é incrivelmente fácil começar.

http://code.google.com/p/uppercut/

Algumas boas explicações aqui: Gancho