¿Es malo usar TFVC como repository de artefactos para versiones completas?

Trabajo para una empresa donde almacenamos los resultados de compilation (artefactos, cada uno de diferentes tecnologías) de una gran cantidad de aplicaciones diferentes en TFVC, luego de nuestro repository a nuestros serveres de entorno. He estado investigando repositorys de artefactos para sacarnos de usar TFVC para estos resultados. Mientras reunía los requisitos, me preguntaron por qué estaba buscando alternativas. Leyendo la documentation de TFVC encontré esto:

Puede usar Team Foundation Version Control (TFVC) para escalar de proyectos pequeños a grandes, y al usar áreas de trabajo del server, puede escalar a bases de código muy grandes con millones de files por bifurcación y files binarys grandes.

Honestamente, no puedo responder la pregunta de por qué deberíamos usar un repository de artefactos sobre TFVC. Se llama Team Foundation Server Version Control , no Source Control . Parte de nuestro requisito es el control de versiones y copys de security. Una vez que estemos completamente automatizados, no tendremos un requisito para estos repositorys, sin embargo, tal como están las cosas, necesitamos alguna forma de repository versionado para nuestros artefactos. Entonces mis preguntas son:

  • ¿Es malo usar TFVC para almacenar una gran cantidad de files binarys (generar resultados)?
  • ¿Por qué querría usar un repository de artefactos sobre TFVC?

Cuando copys resultados de compilation para soltar / compartir carpetas. Esto almacenará el resultado de compilation fuera del control de versión, pero en la database del server tfs.

En cuanto a, es malo usar TFVC para almacenar una gran cantidad de files binarys (compilation de salidas). En términos generales, independientemente de lo bueno o malo, es de acuerdo a sus necesidades.

En TFS2012, aún puede copyr las salidas de compilation en la carpeta de control de origen. Entonces esto definitivamente es soporte en TFVC. enter image description here

Algunas limitaciones: si pone el resultado de compilation en control de código fuente, también significa que obstruyó el repository de control de versiones con files y, a veces, files grandes. Cuando se agregan files a un repository versionado, hay una gran cantidad de poder de cómputo utilizado para descubrir versiones y deltas y otras necesidades, pero para una carpeta desplegable no las necesitamos.

Peor aún cuando quiere eliminar cosas viejas, necesita llamar a un command " destruir " para asegurarse de que no deje todos esos files ocupando espacio para siempre.

También eche un vistazo a este blog: Nuevo repository sin versión en TFS 2012

Aparte de las preocupaciones de hinchamiento de espacio / depósito, la razón key es el control de versiones. Si crea (por ejemplo) packages NuGet para sus binarys, puede hacer reference de forma segura a diferentes versiones para diferentes aplicaciones, y no tener que preocuparse por los cambios que introducen problemas (ya sean errores o errores de compilation) en aplicaciones que no han sido probadas última versión de la dependencia. Como ejemplo:

Tienes DependencyFoo que conviertes en un package NuGet.

Aplicación A references versión 1.0.

La aplicación B hace reference a la versión 1.0.

Para soportar la Aplicación A, usted realiza algunos cambios en su package DependencyFoo. Luego puede actualizar la versión a la que hace reference la Aplicación A sin afectar la Aplicación B en absoluto .

Más allá de eso, si alguna vez decides hacer la transición a Git desde TFVC, Git no maneja bien los binarys, y como es natural, nunca debería includese en el control de versiones.

    Intereting Posts