Quali sono i motivi per non usare Bitbucket-server per archiviare artefatti?

Sto lavorando con un'azienda che sta creando un nuovo progetto e stiamo parlando di quali strumenti usare per cosa. Stavo parlando di Artifactory o Nexus per l'archiviazione di artefatti costruiti (APK in questo caso), e mi hanno chiesto perché non possono semplicemente usare Bitbucket come useranno per il software, per ridurre il numero di strumenti necessari per l'installazione e la manutenzione.

La mia risposta iniziale è stata "La fonte va nel repository sorgente e gli artefatti vanno nel repository artefatto", ma questa non è in realtà una risposta perché o perché no. In effetti, googling in giro non ha offerto alcun ragionamento.

AGGIUNGI A QUESTO: Questo prodotto è per un settore regolamentato. Ciò significa che abbiamo bisogno di una versione completa e verificabile dei manufatti creati. Questo è uno dei motivi per cui stiamo esaminando questo. Inoltre, come ho detto in alcuni commenti, ma lo aggiungeremo qui, installeremo Bitbucket in un GCP privato non accessibile al pubblico, quindi non ci sono dubbi sul fatto che altri possano accedervi.

Qualche input in questo? Qualcosa che ci morderebbe in seguito se li memorizziamo in Bitbucket?

Motivi per non archiviare file binari di grandi dimensioni in un gitrepository:

• Chiunque clonerà il tuo repository scaricherà tutti quei file binari, per impostazione predefinita. I binari, se costruiti regolarmente, tendono a consumare enormi quantità di spazio di archiviazione, rispetto al codice sorgente - gitnon possono comprimerli o calcolare delta, per ridurne le dimensioni.
• gitfa di tutto per assicurarsi che la cronologia non vada persa, non cancellerà mai nulla di ciò che fa parte della cronologia di nessuno ref(rami o tag). Ciò significa anche che se in seguito deciderai di eliminare vecchi binari inutili a causa della mancanza di spazio, scoprirai che, sebbene non impossibile, è davvero molto difficile.
• Un punto dei negozi di manufatti adeguati è che aiutano a eliminare gradualmente le parti obsolete o compromesse. gitnon puoi davvero farlo per te - dovresti scrivere i tuoi strumenti per quello - e non ti libererai mai delle vecchie versioni nella storia.
• Il concetto di "commit" non si applica realmente ai binari. Sono necessarie operazioni come "upload" e "download", poiché sono regolarmente coinvolte nei processi di compilazione del software (ad esempio, bundlernel mondo ruby ​​o mavenin Java). Quei costruttori sanno come recuperare facilmente le loro librerie di terze parti dai repository di artefatti e come caricare nuove versioni. Potrebbero essere convinti di lavorare con un gitrepository per i download, ma poiché gitnon ha informazioni sul controllo delle versioni, è necessario disporre di nuovo i propri strumenti, specificare il commit in cui trovare quel binario manualmente o fare in modo che tutti i binari siano mai stati utilizzati localmente. E il caricamento su un gitrepository, di nuovo, userebbe i tuoi strumenti (creando anche commit spuri).

In totale, usare gitper quello è solo lo strumento sbagliato. Se i tuoi colleghi hanno paura di aggiungere un altro strumento complesso come Nexus, almeno convincili a usare uno strumento semplice invece di git- come qualche arbitrario (s)ftp/ scprepository in una VM da qualche parte, con httpsaccesso tramite un semplice server web.

Se è necessario utilizzarlo git, assicurarsi almeno che i binari di compilazione non siano sottoposti a commit insieme al codice sorgente, ma nella loro parte della cronologia. Dai un'occhiata a questa risposta precedente per vedere come creare un ramo orfano . Questi possono almeno essere eliminati in un secondo momento e gli stessi binari rimossi dalla garbage collection; e non tutti i client sono costretti a scaricarlo tutto il tempo.

Puoi usare un repository Git (sia che sia ospitato su Bitbucket o meno) come repository di artefatti, ma dovresti essere consapevole che:

• Git è stato originariamente creato come sistema di controllo versione per codice sorgente , non per dati binari (di grandi dimensioni), e questa è ancora la sua principale preoccupazione. Esistono estensioni che consentono di lavorare con file di grandi dimensioni in Git in modo efficiente, ad esempio Git LFS , ma ancora: non è integrato nel nucleo di Git.
• Un repository di artefatti adeguato ha funzionalità che un servizio basato su Git non può fornire facilmente. Ad esempio, probabilmente si desidera eliminare artefatti di snapshot meno recenti, un'operazione per cui Git non è progettata, ma quale è una caratteristica principale dei repository di artefatti. Alcune di queste funzionalità sono descritte nelle risposte alla domanda Cos'è un repository di artefatti? .

Quindi mentre puoi usare Git / Bitbucket come repository di artefatti, è un po 'come guidare una vite con un martello anziché un cacciavite.

Se memorizzi i file apk all'interno del repository di Bitbucket devi usare git o arricciarlo per clonarlo. E se il repository privato è necessario accedervi, limitare le dimensioni ecc.

Il repository software è più comodo per archiviare file binari. Puoi creare il tuo mirror di Maven, repository di Google.

È possibile utilizzare le pipeline di bitbucket per distribuire nella sezione download e conservare lì i tuoi artefatti. Ecco un esempio dalla loro documentazione

Come altri hanno già detto, non dovresti controllare i binari in git. Ma Bitbucket offre un'area "Download" separata per repository. Questa è un'area separata, non parte del repository git. Se si utilizzano pipeline di Bitbucket, è anche possibile automatizzare la distribuzione nell'area dei download , se adatta al flusso di lavoro.