Quais são os motivos para não usar o Bitbucket-server para armazenar artefatos?

Estou trabalhando com uma empresa que está montando um novo projeto e estamos falando sobre quais ferramentas usar para o que. Eu estava falando sobre o Artifactory ou o Nexus para armazenar artefatos construídos (APKs neste caso), e eles perguntaram por que eles não podem usar o Bitbucket como usarão no software, para reduzir o número de ferramentas necessárias para instalar e manter.

Minha resposta inicial foi "A fonte entra no repositório de origem e os artefatos entram no repositório de artefato", mas essa não é realmente uma resposta por que ou por que não. De fato, pesquisar no Google também não ofereceu nenhum raciocínio.

ADICIONANDO A ISTO: Este produto é para uma indústria regulamentada. Isso significa que precisamos de um registro auditável e com versão completa dos artefatos construídos. Essa é uma das razões pelas quais analisamos isso. Além disso, como eu disse em alguns comentários, mas adicionaremos aqui, instalaremos o Bitbucket em um GCP privado não acessível ao público, portanto, não há preocupações sobre outras pessoas acessando-o.

Alguma entrada nisso? Algo que nos morderia mais tarde se os armazenarmos em Bitbucket?

Razões para não armazenar binários grandes em um gitrepositório:

• Todo mundo que clonar seu repositório fará o download de todos esses binários, por padrão. Os binários, se construídos regularmente, tendem a consumir grandes quantidades de armazenamento, em comparação com o código-fonte - gitnão podem compactá-los ou calcular deltas para reduzir seu tamanho.
• gitse esforça ao máximo para garantir que o histórico não seja perdido, nunca excluirá nada que faça parte do histórico de qualquer um ref(ramos ou tags). Isso também significa que, se você decidir posteriormente excluir binários antigos e inúteis devido à falta de espaço, descobrirá que, embora não seja impossível, é realmente muito difícil.
• Um ponto das lojas de artefatos adequadas é que elas ajudam a eliminar progressivamente peças desatualizadas ou comprometidas. gitnão pode realmente fazer isso por você - você teria que escrever suas próprias ferramentas para isso - e nunca se livrará das versões antigas da história.
• O conceito de "confirmação" não se aplica realmente a binários. Você precisa de operações como "upload" e "download", pois elas estão regularmente envolvidas nos processos de construção do seu software (ou seja, bundlerno mundo do ruby ​​ou mavenem Java). Esses construtores sabem como buscar facilmente suas bibliotecas de terceiros nos repositórios de artefatos e como fazer upload de novas versões. Eles podem ser convencidos a trabalhar com um gitrepositório para downloads, mas como gitnão possui informações sobre versão, você precisa novamente ter suas próprias ferramentas, especificar a confirmação na qual encontrar esse binário manualmente ou ter todos os binários em uso com check-out localmente. E o upload para um gitrepositório, novamente, usaria suas próprias ferramentas (criando confirmações espúrias também).

No total, usar gitpara isso é apenas a ferramenta errada. Se seus colegas têm medo de adicionar mais uma ferramenta complexa como o Nexus, convença-os a usar uma ferramenta simples em vez de git- como algum repositório (s)ftp/ arbitrário scpem uma VM em algum lugar, com httpsacesso por um servidor da web simples.

Se você deve usar git, pelo menos, verifique se os binários de construção não foram confirmados junto com o código-fonte, mas em sua própria parte do histórico. Confira esta resposta mais antiga para ver como criar uma filial órfã . Esses podem pelo menos ser excluídos mais tarde e os próprios binários removidos pela coleta de lixo; e nem todo cliente é forçado a baixar tudo isso o tempo todo.

Você pode usar um repositório Git (se ele está hospedado no Bitbucket ou não) como um repositório de artefato, mas você deve estar ciente de que:

• O Git foi originalmente criado como um sistema de controle de versão para código fonte , não para dados binários (grandes), e essa ainda é sua principal preocupação. Existem extensões que permitem trabalhar com arquivos grandes no Git com eficiência, por exemplo, Git LFS , mas ainda assim: ele não está embutido no núcleo do Git.
• Um repositório de artefato adequado possui recursos que um serviço baseado em Git não pode fornecer facilmente. Por exemplo, você provavelmente deseja excluir artefatos de captura instantânea mais antigos, uma operação para a qual o Git não foi projetado, mas qual é o principal recurso dos repositórios de artefatos. Alguns desses recursos estão descritos nas respostas à pergunta O que é um repositório de artefatos? .

Portanto, embora você possa usar o Git / Bitbucket como um repositório de artefatos, é como apertar um parafuso com um martelo, em vez de uma chave de fenda.

Se você armazenar arquivos apk dentro do repositório do Bitbucket, precisará usar o git ou enrolar para clonar. E se repo privado, você precisa ter acesso a ele, limitação de tamanho etc.

O repositório de software é mais confortável para armazenar arquivos binários. Você pode criar seu próprio espelho de maven, repositórios do google.

Você pode usar pipelines de bitbucket para implantar na seção de download e manter seus artefatos lá. Aqui está um exemplo de sua documentação

Como outros já disseram, você não verificaria os binários no git. Porém, o Bitbucket oferece uma área separada de "Downloads" por repo. Essa é uma área separada, não faz parte do repositório git. Se você estiver usando pipelines Bitbucket, poderá automatizar a implantação na área de downloads , se isso for adequado ao fluxo de trabalho.