Como você mantém os binários liberados sob controle de versão?

Como você mantém os binários liberados sob controle de versão? Isso permite rastrear quais itens são alterados entre cada versão. Quero separar os binários liberados do repositório de origem. Os binários lançados são criados a partir do software de integração contínua ou compilados manualmente.

Duas opções:

a) não. Apenas verifique se você tem construções determinísticas reproduzíveis, ou seja, criar a mesma revisão de controle de origem com a mesma configuração sempre produz exatamente o mesmo binário.

b) Designe um diretório em algum lugar como a fonte autorizada para compilações publicadas. Torne o carregamento dos binários parte do procedimento de implantação / envio e verifique se o diretório de construção publicado está coberto pelo seu plano de backup. Você não precisa de nenhum controle de versão aqui; As construções são gravadas uma vez; se você precisar alterar alguma coisa, você cria uma nova construção.

De qualquer forma, os binários e outras saídas de compilação não pertencem ao controle de origem, por várias razões.

Use um repositório de artefato para binários, não um sistema de controle de versão. Uma versão específica de um binário liberado não deve mudar ao longo do tempo, portanto, o controle de versão não faz sentido, pois os arquivos não mudam.

Veja, por exemplo, repositórios Maven como repositório para arquivar / publicar / oferecer lançamentos e outros binários (por exemplo, como documentação)

Basta colocá-los. Não há problema com isso, a menos que você esteja usando o git (que não combina bem os binários, então você terá que gerenciá-los) ou estará comprometendo-os muitas vezes (apenas confirme quando for necessário). pronto para enviar, nem sempre que você o montar).

Na maioria dos binários delta de SCMs, muito bem, costumávamos colocar uma DLL de recurso de 2Mb em nosso SVN e deltava para alguns kb de cada vez.

Ouvi muitos argumentos de que os SCMs são para fonte, não binários, mas isso é claramente falso quando você considera que a maioria dos softwares consiste em imagens, mesmo que sejam apenas arquivos de ícones. Eles são binários, mas fazem parte da fonte, então coloque-os e não seja tão dogmático sobre isso. Também soube que você pode reconstruir o binário apenas quando necessário, geralmente esse é o caso, mas pode ser um grande esforço para desperdiçar tempo em sistemas mais antigos que não são mais ativamente suportados. Se você precisar recriar um sistema com apenas service packs ou patches mais antigos para corresponder ao sistema que foi usado para criar um binário há 3 anos, ficará satisfeito por ter adicionado a lixeira ao seu SCM naquela época.

O único momento em que você precisa se preocupar em adicionar builds ao seu SCM é se estiver fazendo isso automaticamente como parte do processo do servidor de build - não faça isso. Você preencherá seu SCM com compilações que não têm nenhum benefício para você. Em vez disso, adicione-os apenas quando forem liberados. Dessa forma, você sabe exatamente o que seu cliente possui e pode reproduzir quaisquer problemas relatados pelo cliente com os binários que estão usando, e não com os que você reconstruiu (usando, digamos, as atualizações mais recentes para o compilador ou o sistema operacional).

Não mantenho binários de lançamento sob controle de versão. Em vez disso, publico-os em um local bem definido para que outras ferramentas os inspecionem e usem. Faço muito trabalho em Java, o que significa que publico Jars em repositórios locais do Maven. No entanto, não uso essas ferramentas para rastrear o que mudou por versão. Afinal, eles são binários e não há muito o que rastrear além da contagem de arquivos.

Para rastrear as alterações entre os lançamentos, eu marcaria ou rotularia lançamentos no meu sistema de controle de versão com o número da versão. Mas isso é realmente apenas para rastrear os arquivos de origem, não os binários. Os binários são artefatos da construção e não precisam estar sob controle de versão.

A melhor solução é fazer uso exclusivo do seu sistema de IC para todas as compilações organizacionalmente significativas (liberações, liberar candidatos etc ...).

Isso sistematicamente vincula os binários liberados ao conteúdo do repositório sem precisar realmente armazenar os binários no repositório.

Por exemplo, se você estiver usando SVN, use o esquema organizacional principal da filial; faça todo o desenvolvimento diário em / trunk e crie uma tag / para cada release assim que estiver pronto.

Configure seu sistema de IC para criar tags e também de tronco e faça com que ele grave a saída em um diretório de rede cuja estrutura reflete a estrutura de nível superior do repositório:

• / builds / trunk / [rev] [date] [build_id] /
• / builds / tags / release_0_1_3beta4 / [rev] [date] [build_id] /

O sistema de compilação precisará tratar o diretório / builds / trunk / como um buffer circular, armazenando as últimas n compilações, excluindo as compilações antigas à medida que for avançando.

O diretório / builds / tags / , por outro lado, é um armazenamento permanente. Os artefatos de construção são armazenados em diretórios com nomes gerados de acordo com o seguinte esquema:

• [rev] [data] [build_id]

onde [rev] é o ID da revisão do SVN, [date] é a data no formato AAAAMMDD e [build_id] é um contador exclusivo de três dígitos, incrementando a partir da primeira compilação, tornando cada diretório de compilação exclusivo.

O processo detalhado acima oferece os seguintes benefícios:

1. Os artefatos de construção estão vinculados sistematicamente à origem que os gerou, para que você possa encontrar a origem de um artefato de construção específico com muita facilidade (e vice-versa).

2. Isso forma a base para automação de liberação adicional. Por exemplo, geração automática de documentos de lançamento, etc ...