É uma boa prática armazenar tempos de execução da estrutura sob controle de origem?

Sei que muitas lojas de software mantêm binários sob controle de origem . No entanto, nossa loja chegou a armazenar estruturas inteiras no repositório: DirectX runtime, CUDA, nVidia Optix, o que for.

Diz-se que facilita a configuração de uma máquina de desenvolvimento (supostamente, obtenha as últimas e comece a codificar). No entanto, incha consideravelmente o repositório e o sobrecarrega com uma história irrelevante.

Eu nunca vi esse padrão de uso. Você considera uma boa prática?

[EDIT:] Não tenho nenhum problema com binários de terceiros isolados de controle de origem. A pergunta se refere a tempos de execução completos da estrutura, geralmente consistindo em mais de 10 binários. Como um exemplo extremo, considere o Windows SDK (que não mantemos no repositório, graças a Deus, mas não vejo diferença de princípio).

Os binários geralmente não são adequados para o sistema de controle de versão porque:

• eles não se beneficiam dos recursos de controle de versão (mesclagem, diferenças)
• eles aumentam o tamanho do repositório ...
• ... o que importa, porque você não remove facilmente uma versão de um VCS (os VCS são feitos para manter o histórico), em oposição aos repositórios de artefatos como o Nexus , que são diretórios compartilhados simples (fácil de limpar: cd+ rm!)
• elas devem ser referenciadas no VCS como um texto , uma declaração de caminho + versão: você pode manter o histórico relevante dessa maneira , registrando qualquer alteração da versão binária como uma alteração no arquivo de texto (como um pom.xml se você estiver usando o Nexus por exemplo)

Eu estou bem com a versão que controla ativos binários. Sou contra a versão que controla os arquivos gerados .

Além disso, a configuração do ambiente é algo diferente do desenvolvimento. Desenvolvemos principalmente em Python e ele possui uma ferramenta chamada virtualenv, que permite criar um ambiente isolado leve (incluindo bibliotecas) para um projeto. Quando verificamos nossas fontes, temos um script de configuração que cria esse virtualenv. Usando um manifesto, isso especifica quais versões de bibliotecas são necessárias e outras coisas semelhantes. Nada disso é controlado por versão. Somente o script de instalação é.

Jogar toda a estrutura no seu projeto principal irá desorganizar sua história e atrapalhar seriamente as coisas. Não faz parte do seu projeto e deve ser tratado de maneira diferente.

Geralmente, é uma boa idéia fazer o gerenciamento de configurações com versões de estrutura. Se o seu código precisar de uma versão específica do DirectX, essa versão deverá estar facilmente disponível e se você fizer o check-out de uma versão mais antiga do seu software, será fácil determinar quais dependências externas ele possui.

O que não acho uma boa idéia aqui é usar seu sistema de controle de versão típico para armazenar esses binários. Em nossa empresa, armazenamos todas as versões de estruturas, bibliotecas e ferramentas externas em uma estrutura de subpasta em uma unidade de rede. Onde achamos que faz sentido, temos arquivos leia-me para documentar qual versão de ferramenta pertence a qual versão de software ou, se possível, temos scripts para instalar ou usar uma versão específica. Somente esses arquivos e scripts leia-me entram no controle de versão.

Também mantemos versões mais antigas de ferramentas e bibliotecas, desde que pensemos que pode haver uma chance de reconstruirmos e versões mais antigas, dependendo dessas ferramentas. Dessa forma, nos permite excluir algumas das bibliotecas e ferramentas muito antigas da unidade de rede quando elas foram preteridas (é claro, apenas no caso de termos arquivos em mídia externa).

Eu acho que os binários devem ser armazenados em algum lugar. Eu sugeriria armazená-los fora de um repositório, especialmente se eles forem grandes e levar a grandes tempos de check-out. Não vou ver as más práticas, mas também não as que já vi.

Isso pode ser uma boa ideia, se sua organização tiver muitos projetos direcionados a diferentes versões de tempo de execução. Ele garante que você tenha o binário de tempo de execução correto quando estiver trabalhando nos projetos certos.

Pessoalmente, considero isso uma prática muito ruim. Prefiro configurar um wiki com instruções de instalação e carregar os binários necessários. Esses arquivos são necessários apenas por novos desenvolvedores, não há necessidade de inchar repositórios de todos os outros.

Há uma boa razão para fazer isso: você tem tudo o que precisa em um único local, sem dependências externas.

Isso é muito mais importante do que você imagina. Essencialmente, garante que você não confie em um artefato em um servidor de fornecedor que poderá desaparecer após alguns anos, já que você tem tudo internamente.

Em relação ao inchaço do repositório. Isso é apenas um problema se o seu VCS mantém uma cópia local completa (o git faz isso, o cvs não), pois a clonagem e / ou a atualização serão lentas. Em troca, você terá cópias em cada máquina de desenvolvimento, o que pode salvar sua empresa se, por algum motivo, seu esquema de backup central falhar algum dia.

É uma questão de prioridade ou política. Enquanto a decisão for deliberada, eu ficaria bem com isso.