Cómo tratar las bibliotecas internas

7

Tengo problemas para estructurar proyectos y bibliotecas.

En la empresa en la que trabajo, a menudo veo que las cosas serían más fáciles de mantener y menos propensas a errores, si pudiéramos extraer código común y construir bibliotecas con ese código.

Un ejemplo simple puede ser el uso de una biblioteca de registro personalizada en lugar de copiar código de otros proyectos o, lo que es peor, escribir todo nuevamente desde cero.

¿Así que querer exponer cosas en las bibliotecas surge la pregunta de cómo hacerlo? Mi idea es colocar cada lib (o conjunto de bibliotecas relacionadas) en su propio repositorio. Pero esto significaría que, para construir el proyecto, definitivamente necesitas revisar al menos dos repositorios. Debido a que he trabajado en un proyecto con dependencias a un lote de otros repositorios, tuve mucho cuidado al crear dependencias para otros proyectos.

Así que mi pregunta es: ¿hay otra buena solución para esto? ¿Qué es lo que hacen?

Hay más de 150 repositorios, que no todos están relacionados, por supuesto. La mayoría de los proyectos tienen su propio repositorio. Para proporcionar un escenario, asumamos lo siguiente:

  • Solicitud A
  • La aplicación B (ya hace referencia a otros 30 repositorios internos)
  • LibXYZ

Ambas aplicaciones necesitan usar LibXYZ.

Versioning:

La versión depende del proyecto. Los proyectos anteriores simplemente tomaron el número de revisión de SVN. Ahora nos estamos moviendo a la versión con números fijos como 1.2 o 1.2.5, así que asumamos esto como un enfoque de versión. Cada lanzamiento está etiquetado en SVN.

Plataforma :

Estamos utilizando Qt targetting principalmente Windows. Pero aprecio mucho un enfoque multiplataforma.

¿Qué me impide crear un repositorio para código común?

El problema que veo es que agrega mucha complejidad a un proyecto. Para poder compilar y ejecutar una aplicación, necesito:

  • revisa múltiples repositorios
  • compilar todas las dependencias
  • copie todas las DLL compiladas en el directorio de compilación de la aplicación

Una vez más, todo esto tiene que estar documentado y tal vez también debe incluirse en los scripts de compilación. Además, esto obliga a los otros miembros del equipo a tener la misma configuración que yo.

No estoy diciendo que esto sea imposible, solo estoy buscando un mejor enfoque.

    
pregunta exilit 09.01.2017 - 14:39

2 respuestas

4

Para abordar estos problemas uno por uno:

  

revisa múltiples repositorios

Usando SVN, puede utilizar la función "externos" para esto. Esto le permitirá definir dependencias entre diferentes repositorios de una manera en la que diga "la aplicación A depende de la lib B etiquetada con la versión X", o "la aplicación A depende de la lib B, siempre la versión más reciente". Para otros sistemas de control de código fuente sin una característica como "externos" (o si "externos" no proporciona la solución que está buscando), puede implementar un comportamiento similar escribiendo algunos scripts de verificación.

  

compilar todas las dependencias

Su sistema de compilación debería manejar esto por usted, una vez que definió las dependencias allí correctamente. No hay ninguna diferencia en la situación cuando usas librerías de terceros. Puede reducir los tiempos de compilación al proporcionar binarios precompilados de cada versión de la biblioteca y colocar los binarios compilados en el repositorio, también.

  

copie todas las DLL compiladas en el directorio de compilación de la aplicación

Sí, esto debería suceder automáticamente en el paso anterior.

En general, la clave para esto es la automatización. Cada vez que encuentre una tarea manual recurrente que podría volverse propensa a errores (como retirar de los repositorios "correctos", copiar el archivo X a la carpeta Y, establecer una etiqueta con un número de versión aumentado aquí, etc.),

  • escriba los pasos del manual en algo así como un archivo "readme"
  • descubra cómo automatizar esos pasos a través de secuencias de comandos
  • asegúrese de que los scripts hagan un registro adecuado y control de errores. La verificación de las condiciones previas y la tolerancia a fallos también son útiles en mi experiencia.

Al tratar con múltiples aplicaciones, repositorios y bibliotecas, también podría ser una buena idea configurar un servidor de compilación que verifique todo por la noche y haga una compilación completa de todo.

  

Además, esto obliga a los otros miembros del equipo a tener la misma configuración que yo.

Hasta cierto punto, sí, pero esto no es necesariamente algo malo. Para cada herramienta de desarrollo, recomiendo agregar un archivo Léame que describa los requisitos de configuración específicos en su entorno interno. Sus scripts de compilación deben basarse tanto en las rutas relativas como sea posible, no utilice ninguna ruta absoluta cuando no sea necesario. Y si es necesario, haga que un script de inicialización central descubra cosas como las rutas de instalación para las herramientas requeridas en la máquina actual y configure algunas variables de entorno en consecuencia.

    
respondido por el Doc Brown 10.01.2017 - 08:43
3

No haga referencia a otros repositorios. No tiene ningún requisito para crear las dependencias cada vez que construye la aplicación principal.

Construye cada repositorio de biblioteca en una dll por separado y la versión que dll

agregue el dll binario compilado a un repositorio de paquetes (nuget npm)

agregue una referencia al paquete en el repositorio de paquetes al proyecto principal

cuando creas el proyecto principal, el primer paso es descargar las dlls versionadas

(si no tiene un administrador de paquetes, agregue la dll al control de origen en su repositorio principal)

    
respondido por el Ewan 10.01.2017 - 16:09

Lea otras preguntas en las etiquetas