Em uma arquitetura distribuída, por que é difícil de gerir versões?

Question

Eu vejo isso uma e outra vez. O gerente de teste UAT quer que a nova compilação para estar pronto para teste até sexta-feira. A uma das primeiras perguntas feitas, na reunião pré-teste é: "Qual versão eu vou estar testando, contra?" (Que é uma boa pergunta). A sala fica em silêncio, então alguém vai voltar com "todas as igrejas têm a sua própria versão, basta clicar com o botão direito e olhar para as propriedades ...".

A partir dos gerentes de teste de ponto-de-vista, este é nenhum uso. Eles querem uma versão / label / tag através tudo que lhes diz o que eles estão trabalhando. Eles querem que esta informação facilmente disponíveis atualmente.

Eu tenho visto soluções onde a versão de áreas diffierent de um sistema que está sendo armazenados em um armazenamento de dados, em seguida, mostrado em cerca de caixa do aplicativo principal. O problema é que isso precisa ser mantida.

Que soluções você já viu que contorna isto em ir problema?

EDIT. O tampas sistema distribuído VB6, ASP clássico, VB.Net, C #, Web Services (accross departamentos, de modo que a versão que estamos usando?), SQL Server 2005.

Answer 1

Eu acho que o problema é que você e seu gerente de teste estamos falando de duas coisas diferentes. versões de montagem são grandes para os conjuntos, mas o seu gerente de teste está falando de uma versão de nível superior, uma "versão do sistema", se você quiser. Pelo menos essa é a minha leitura do seu post.

O que você tem a fazer em tais situações é mapear todos os seus diferentes conjuntos de componentes em uma versão do sistema. Você diz algo ao longo das linhas de "A versão 1.5 do sistema é composto por Foo.Bar.dll v1.4.6 e Baz.Qux.dll v2.6.7 e (etc.)". Inferno, em um sistema distribuído, você pode querer versões diferentes para cada um dos seus serviços, o que pode, em si e por si, ser compostas por diferentes versões do .dlls. Você pode dizer, por exemplo: "A versão 1.5 do sistema é composto pelo v1.3 serviço Foo, que é composto de Foo.dll v1.9.3 e Bar.dll v1.6.9, ea v1.9 serviço de Bar, que é composto por Baz.dll v1.8.2 e Qux.dll v1.5.2 e (etc.)".

Fazendo coisas como esta normalmente é o trabalho do arquiteto de software e / ou gerente de construção em sua organização.

Há uma série de ferramentas que você pode usar para lidar com essa questão que não tem nada a ver com o idioma de sua escolha. O meu favorito é atualmente Jira , que, além de acompanhamento de bugs, tem um grande controle de versão de produto e roadmapping apoio.

Answer 2

Pode querer ter um olhar para desta página que explica algumas maneiras para integrar o controle de versão consistente em seu processo de criação.

Answer 3

Há uma série de coisas diferentes que contribuem para o problema. Fora do topo da minha cabeça, aqui está um:

Um dos benefícios de uma arquitetura distribuída é que ganhamos um enorme potencial para reutilização através da criação de serviços e publicar suas interfaces, de alguma forma ou de outra. O que isso significa, então, é que os lançamentos de um aplicativo cliente não são necessariamente estreitamente sincronizadas com lançamentos dos serviços subjacentes. Assim, uma nova versão de um aplicativo de negócios pode ser liberado que usa o mesmo serviço confiável de idade que tem sido usado por um ano. Como veremos em seguida, aplicar um único marcador de lançamento neste caso?

No entanto, é uma pergunta justa, mas que exige uma resposta não-trivial para ser significativo.

Answer 4

A não utilização de construção com base versão de numeração para qualquer coisa, mas as referências internas. Quando o gerente UAT faz a pergunta que você diz "* de sexta-feira".

O único truque então é para se certificar de rotulagem acontece de forma confiável em seu controle de origem.

* inserção apropriada datestamp / label aqui

Answer 5

Nós usamos .NET e Subversion. Todos os nossos conjuntos de aplicativos compartilham um número de versão, que é derivado de um números de revisão maiores e menores atualizados manualmente e o número de revisão Subversion (<major>.<minor>.<revision>). Temos uma tarefa prebuild que atualiza esse número de versão em um arquivo AssemblyVersionInfo.vb compartilhada. Então, quando testadores pedir o número da versão, que pode dar-lhes o número 3 partes completo ou apenas a revisão subversão. As bibliotecas que consumimos não estão mudando ou a mudança não é relevante para o testador.