¿Cuáles son las razones para no usar Bitbucket-server para almacenar artefactos?

Estoy trabajando con una empresa que está creando un nuevo proyecto y estamos hablando de qué herramientas usar para qué. Estaba hablando de Artifactory o Nexus para almacenar artefactos construidos (APK en este caso), y me preguntaron por qué no pueden simplemente usar Bitbucket como usarán para el software, para reducir la cantidad de herramientas que necesitan instalar y mantener.

Mi respuesta inicial fue "La fuente va en el repositorio de fuente y los artefactos van en el repositorio de artefacto", pero esa no es realmente una respuesta de por qué o por qué no. De hecho, buscar en Google tampoco ofrecía ningún razonamiento.

AGREGANDO A ESTO: Este producto es para una industria regulada. Eso significa que necesitamos un registro completo, versionado y auditable de los artefactos construidos. Esta es una de las razones por las que estamos investigando esto. Además, como dije en algunos comentarios, pero agregaré aquí, instalaremos Bitbucket en un GCP privado al que no puede acceder el público, por lo que no hay preocupaciones de que otros accedan a él.

¿Alguna aportación a esto? ¿Algo que nos muerda más adelante si los almacenamos en Bitbucket?

Razones para no almacenar grandes binarios en un gitrepositorio:

• Cualquiera que clone su repositorio descargará todos esos binarios, por defecto. Los binarios, si se crean regularmente, tienden a consumir grandes cantidades de almacenamiento, en comparación con el código fuente, gitno pueden comprimirlos ni calcular deltas para reducir su tamaño.
• githace todo lo posible para asegurarse de que el historial no se pierda, nunca eliminará nada que sea parte del historial de ninguno ref(ramas o etiquetas). Eso también significa que si luego decide eliminar los archivos binarios viejos e inútiles debido a la falta de espacio, encontrará que, si bien no es imposible, es muy difícil.
• Un punto de las tiendas de artefactos adecuados es que ayudan a eliminar las partes obsoletas o comprometidas. gitRealmente no puede hacer eso por usted, tendría que escribir sus propias herramientas para eso, y nunca se deshará de las versiones antiguas de la historia.
• El concepto de "commit" no se aplica realmente a los binarios. Necesita operaciones como "cargar" y "descargar", ya que participan regularmente en los procesos de compilación de su software (es decir, bundleren el mundo de Ruby o mavenen Java). Esos constructores saben cómo obtener fácilmente sus bibliotecas de terceros de los repositorios de artefactos y cómo cargar nuevas versiones. Es posible que estén convencidos de trabajar con un gitrepositorio para descargas, pero como gitno tiene información sobre el control de versiones, nuevamente necesita tener sus propias herramientas, especificar la confirmación para encontrar ese binario manualmente o hacer que todos los binarios en uso se verifiquen localmente. Y subir a un gitrepositorio, de nuevo, usaría sus propias herramientas (también crea confirmaciones espurias).

En total, usar gitpara eso es simplemente la herramienta incorrecta. Si sus colegas tienen miedo de agregar otra herramienta compleja como Nexus, entonces al menos convencerlos de que usen una herramienta simple en lugar de git, como algún repositorio (s)ftp/ arbitrario scpen una máquina virtual en algún lugar, con httpsacceso a través de un servidor web simple.

Si debe usar git, al menos asegúrese de que los archivos binarios de compilación no estén confirmados junto con el código fuente, sino en su propia parte del historial. Mira esta respuesta anterior para ver cómo crear una rama huérfana . Esos al menos se pueden eliminar más tarde, y los binarios se eliminan mediante la recolección de basura; y no todos los clientes se ven obligados a descargarlo todo el tiempo.

Puede usar un repositorio de Git (ya sea que esté alojado en Bitbucket o no) como un repositorio de artefactos, pero debe tener en cuenta que:

• Git se creó originalmente como un sistema de control de versiones para el código fuente , no para datos binarios (grandes), y esta sigue siendo su principal preocupación. Hay extensiones que permiten trabajar con archivos grandes en Git de manera eficiente, por ejemplo, Git LFS , pero aún así: no está integrado en el núcleo de Git.
• Un repositorio de artefactos adecuado tiene características que un servicio basado en Git no puede proporcionar fácilmente. Por ejemplo, es probable que desee eliminar los artefactos de instantáneas más antiguos, una operación para la que Git no está diseñada, pero cuál es la característica principal de los repositorios de artefactos. Algunas de estas características se describen en las respuestas a la pregunta ¿Qué es un repositorio de artefactos? .

Entonces, si bien puede usar Git / Bitbucket como un repositorio de artefactos, es un poco como clavar un tornillo con un martillo en lugar de un destornillador.

Si va a almacenar archivos apk dentro del repositorio de Bitbucket, necesita usar git o curllo para clonar. Y si el repositorio privado necesita tener acceso a él, limitación de tamaño, etc.

El repositorio de software es más cómodo para almacenar archivos binarios. Puede crear su propio espejo de Maven, Google repos.

Puede usar tuberías de bitbucket para implementar en la sección de descarga y mantener sus artefactos allí. Aquí hay un ejemplo de su documentación

Como otros han dicho, no verificaría los binarios en git. Pero, Bitbucket ofrece un área de "Descargas" separada por repo. Esta es un área separada, no parte del repositorio de git. Si usa Bitbucket Pipelines, incluso podría automatizar la implementación en el área de descargas , si eso se adapta al flujo de trabajo.