Quelles sont les raisons de ne pas utiliser Bitbucket-server pour stocker des artefacts?

Je travaille avec une entreprise qui met en place un tout nouveau projet, et nous parlons des outils à utiliser pour quoi. Je parlais d'Artifactory ou Nexus pour le stockage des artefacts construits (APK dans ce cas), et ils ont demandé pourquoi ils ne pouvaient pas simplement utiliser Bitbucket comme ils utiliseront pour le logiciel, afin de réduire le nombre d'outils dont ils ont besoin pour installer et entretenir.

Ma réponse initiale était "La source va dans le dépôt source et les artefacts vont dans le dépôt d'artefact", mais ce n'est pas vraiment une réponse pourquoi ou pourquoi pas. En fait, googler ne proposait aucun raisonnement non plus.

AJOUTER À CELA: Ce produit est destiné à une industrie réglementée. Cela signifie que nous avons besoin d'un enregistrement complet et vérifiable des artefacts construits. C'est l'une des raisons pour lesquelles nous examinons cela. De plus, comme je l'ai dit dans certains commentaires, mais que j'ajouterai ici, nous installerons Bitbucket dans un GCP privé non accessible au public, il n'y a donc aucune inquiétude quant à l'accès des autres.

Avez-vous quelque chose à dire à ce sujet? Quelque chose qui nous mordrait plus tard si nous les stockions dans Bitbucket?

Raisons de ne pas stocker de gros fichiers binaires dans un gitréférentiel:

• Tout le monde clonant votre référentiel téléchargera tous ces fichiers binaires, par défaut. Les binaires, s'ils sont construits régulièrement, ont tendance à consommer d' énormes quantités de stockage, par rapport au code source - gitne peuvent pas les compresser ou calculer des deltas pour réduire leur taille.
• gitfait de grands efforts pour s'assurer que l'historique n'est pas perdu, il ne supprimera jamais rien qui fait partie de l'historique ref(branches ou balises). Cela signifie également que si vous décidez plus tard de supprimer d'anciens fichiers binaires inutiles depuis longtemps en raison d'un manque d'espace, vous constaterez que, bien que cela ne soit pas impossible, très difficile en effet.
• Un point des magasins d'artefacts appropriés est qu'ils aident à éliminer progressivement les pièces obsolètes ou compromises. gitne peut pas vraiment faire cela pour vous - vous devez écrire votre propre outillage pour cela - et vous ne vous débarrasserez jamais des anciennes versions de l'histoire.
• Le concept de "commit" ne s'applique pas vraiment aux binaires. Vous avez besoin d'opérations comme "upload" et "download", car elles sont régulièrement impliquées dans les processus de construction de votre logiciel (ie, bundlerdans le monde rubis, ou mavenen Java). Ces constructeurs savent comment récupérer facilement leurs bibliothèques tierces à partir de référentiels d'artefacts et comment télécharger de nouvelles versions. Ils peuvent être convaincus de travailler avec un gitréférentiel pour les téléchargements, mais comme gitil n'y a pas d'informations de version, vous devez à nouveau disposer de votre propre outil, spécifier le commit dans lequel rechercher ce binaire manuellement ou faire vérifier localement tous les binaires jamais utilisés. Et le téléchargement vers un gitréférentiel, encore une fois, utiliserait votre propre outil (créant également des commits parasites).

Au total, utiliser gitpour cela n'est pas le bon outil. Si vos collègues ont peur d'ajouter un autre outil complexe comme Nexus, convainquez-les au moins d'utiliser un outil simple au lieu de git- comme un arbitraire (s)ftp/ scpréférentiel dans une machine virtuelle quelque part, avec httpsaccès via un simple serveur Web.

Si vous devez utiliser git, assurez-vous au moins que les binaires de génération ne sont pas validés avec le code source, mais dans leur propre partie de l'historique. Consultez cette ancienne réponse pour voir comment créer une branche orpheline . Ceux-ci peuvent au moins être supprimés plus tard, et les fichiers binaires eux-mêmes supprimés par la récupération de place; et tous les clients ne sont pas obligés de tout télécharger tout le temps.

Vous pouvez utiliser un référentiel Git (qu'il soit hébergé sur Bitbucket ou non) comme référentiel d'artefacts, mais vous devez savoir que:

• Git a été initialement conçu comme un système de contrôle de version pour le code source , pas pour les (grandes) données binaires, et c'est toujours sa principale préoccupation. Il existe des extensions qui permettent de travailler efficacement avec de gros fichiers dans Git, par exemple Git LFS , mais quand même: Il n'est pas intégré au cœur de Git.
• Un référentiel d'artefacts approprié possède des fonctionnalités qu'un service basé sur Git ne peut pas facilement fournir. Par exemple, vous souhaitez probablement supprimer les anciens artefacts d'instantanés, une opération pour laquelle Git n'est pas conçu, mais ce qui est une fonctionnalité essentielle des référentiels d'artefacts. D'autres fonctionnalités de ce type sont décrites dans les réponses à la question Qu'est-ce qu'un référentiel d'artefacts? .

Ainsi, même si vous pouvez utiliser Git / Bitbucket comme référentiel d'artefacts, c'est un peu comme enfoncer une vis avec un marteau au lieu d'un tournevis.

Si vous stockez des fichiers apk dans le référentiel de Bitbucket, vous devez utiliser git ou le boucler pour cloner. Et si le repo privé vous avez besoin d'y avoir accès, de limiter la taille, etc.

Le référentiel logiciel est plus confortable pour stocker des fichiers binaires. Vous pouvez créer votre propre miroir de maven, google repos.

Vous pouvez utiliser des pipelines bitbucket pour déployer dans la section de téléchargement et y conserver vos artefacts. Voici un exemple de leur documentation

Comme d'autres l'ont dit, vous ne voudriez pas archiver les binaires dans git. Mais, Bitbucket propose une zone "Téléchargements" séparée par repo. Il s'agit d'une zone distincte, qui ne fait pas partie du dépôt git. Si vous utilisez Bitbucket Pipelines, vous pouvez même automatiser le déploiement dans la zone de téléchargement , si cela convient au flux de travail.