¿Cómo puedo presentar un caso para la "gestión de dependencias"?

Actualmente estoy tratando de presentar un caso para adoptar la administración de dependencias para las compilaciones (ala Maven, Ivy, NuGet) y crear un repositorio interno para módulos compartidos, de los cuales tenemos más de una docena en toda la empresa. ¿Cuáles son los principales puntos de venta de esta técnica de construcción? Los que tengo hasta ahora:

Facilita el proceso de distribución e importación de módulos compartidos, especialmente actualizaciones de versiones.
Requiere que las dependencias de los módulos compartidos se documenten con precisión.
Elimina los módulos compartidos del control de origen, acelerando y simplificando los checkouts / check ins _{(cuando tienes aplicaciones con más de 20 bibliotecas, esto es un factor real)} .
Permite un mayor control o conocimiento de qué bibliotecas de terceros se utilizan en su organización.

¿Hay puntos de venta que me faltan? ¿Hay algún estudio o artículo que proporcione métricas de mejora?

dependency-management

— Cruzar
fuente

Creo que lo has clavado.

— Mike Partridge, el

Nunca recuperaré las muchas horas de mi vida desperdiciadas en configuraciones de Maven rotas. Me he convencido de que, independientemente de las buenas intenciones, en un cuerpo grande, eventualmente se convertirá en un desastre sin mantenimiento que te quitará la vida hasta que seas un caparazón hueco.

— MrFox

@suslik ¿Le gustaría explicar qué es una configuración de "Maven roto"?

— Andrew T Finnell el

@AndrewFinnell Digamos que hay 5 grupos trabajando en proyectos que necesita para que su compilación se compile, y debido a la falta de coordinación, todos terminan dependiendo de las diferentes versiones de las bibliotecas. Entonces resulta que uno de los proyectos no estaba destinado a ser 'lanzado' todavía pero (¡nadie le dijo a Maven!) Que tienes una dependencia que debes satisfacer. No se supone que esto suceda, pero la resolución automática lo hace demasiado fácil. Si todos tuvieran un directorio / libs para mantener en svn, obligaría a la gente a detenerse y hacer preguntas antes de que las cosas se salgan de control.

— MrFox

@MrFox Eso se debe a una mala coordinación, no a la resolución de dependencia de Maven. He experimentado las mismas situaciones y no soy fanático de Maven, pero creo que las herramientas no deben resolver problemas relacionados con los humanos, como las liberaciones prematuras, la falta de comunicación, la falta de pruebas, el mantenimiento deficiente, etc.

— scriptin

Respuestas:

No estoy 100% seguro de los aspectos positivos. Aquí hay algunos puntos negativos

A menudo terminas agregando dependencias a servidores / puntos finales de terceros que podrían no ser estables.

Me ha sucedido con Bower que el repositorio de algunas dependencias fue eliminado o movido. Entonces aparece un nuevo desarrollador, clona mi repositorio, escribe bower instally obtiene errores para repositorios inaccesibles. Si, en cambio, hubiera registrado el código de terceros en mi repositorio, ese problema desaparecerá.

Esto se resuelve como sugiere el OP si está sacando deps de las copias guardadas en un servidor que ejecuta.
Más difícil para los novatos.

Trabajo con estudiantes de arte con muy poca experiencia en línea de comandos. Hacen arte con Processing, arduino, Unity3D, y se las arreglan con muy poco conocimiento tecnológico. Querían usar algunos HTML5 / JavaScript que escribí. Pasos por la glorieta
1. Descargue Zip of repo de github (observe que está a la derecha de cada repositorio en github. Porque no conocen gitub)
2. Descargue e instale el nodo (para que podamos ejecutar npm para instalar Bower)
3. Instale git o msysgit (porque Bower lo requiere y no está instalado en las máquinas de muchos estudiantes)
4. Instalar la glorieta ( npm install -g bower)
5. bower install (finalmente para obtener nuestras dependencias)
Los pasos 2 a 5 se pueden eliminar si solo registramos los archivos en nuestro repositorio de github. Esos pasos probablemente suenen súper fáciles para ti y para mí. Para los estudiantes eran muy confusos y querían saber cuáles eran todos los pasos, dónde y para qué servían, lo que podría ser un buen aprendizaje, pero era completamente ortogonal al tema de la clase y probablemente se olvidó rápidamente.
Agrega otro paso al tirar.

Sucedió muchas veces que hago un git pull origin mastery luego pruebo mi código y me lleva de 5 a 10 minutos recordar que necesitaba escribir bower install para obtener las últimas versiones. Estoy seguro de que eso se resuelve fácilmente con algún gancho de script de extracción.
Hace que la ramificación de git sea más difícil

Si 2 ramas tienen diferentes deps, estás jodido. Supongo que puedes escribir bower installdespués de cada git checkout. Demasiado para la velocidad.

En cuanto a sus aspectos positivos, creo que hay ejemplos contrarios para cada uno de esos

Facilita el proceso de distribución e importación de módulos compartidos, especialmente actualizaciones de versiones.

vs que? Ciertamente no es más fácil de distribuir. Hacer un repositorio en lugar de 20 no es más fácil y es más probable que falle. Ver # 1 arriba

Elimina los módulos compartidos del control de origen, acelerando y simplificando los checkouts / check ins (cuando tienes aplicaciones con más de 20 bibliotecas, esto es un factor real).

Por el contrario, significa que depende de otros para arreglos. Lo que significa que si sus departamentos están extrayendo de una fuente de terceros y necesita un error corregido, debe esperar a que apliquen su parche. Peor aún, es probable que no pueda simplemente tomar la versión que desea más su parche, tendría que tomar la última versión que podría no ser compatible con su proyecto.

Puede resolver eso clonando sus repositorios por separado y luego apunta sus departamentos de proyecto a sus copias. Luego aplica cualquier corrección a sus copias. Por supuesto, también podría hacerlo si solo copia la fuente en su repositorio

Permite un mayor control o conocimiento de qué bibliotecas de terceros se utilizan en su organización.

Eso parece discutible. Solo requiere que los desarrolladores pongan bibliotecas de terceros en su propia carpeta <ProjectRoot>/3rdparty/<nameOfDep>. Es igual de fácil ver qué bibliotecas de terceros se utilizan.

No digo que no haya aspectos positivos. El último equipo en el que estuve tenía> 100 deps de terceros. Solo estoy señalando que no todas son rosas. Estoy evaluando si debería deshacerme de Bower para mis necesidades, por ejemplo.

— gman
fuente

Wow, muchos votos negativos y ni una sola justificación para ellos. ¡Buen trabajo! :(

— gman

Nunca he usado Bower, pero la necesidad de installpagar cada vez parece un defecto de diseño. Debe verificar su configuración cuando crea un proyecto: si hay cambios, debe reconstruir desde cero. Además, mover repositorios es irrelevante para Maven, ya que extrae artefactos del repositorio de Maven, que almacena artefactos, no los repositorios reales con código. Solo puede cambiar artifactIdy groupIden la próxima versión de su artefacto si lo publica en el repositorio de Maven. Entonces, sus puntos # 1 y # 4 son irrelevantes para Maven en particular. # 3 se puede reemplazar con mvn clean(a veces)

— scriptin

Si bien es cierto, el n. ° 2 no es una desventaja, es una compensación. ¡Por supuesto, tienes que aprender tus herramientas! Por ejemplo, Git es bastante difícil de entender, pero no me voy a dar por vencido debido a dem noobs.

— scriptin

Echa un vistazo a la aplicación The Twelve Factor

En particular, lea sobre lo que tienen que decir sobre las dependencias . Notarás que un buen diseño proporciona un mecanismo declarativo para localizar dependencias, en Java esto a menudo se realiza a través de Maven. Ivy y NuGet funcionan bien, pero Maven es actualmente el líder en el campo e Ivy es decididamente un trabajo duro.

Si se adhiere al proceso de lanzamiento de Maven (desarrolle instantáneas hasta que esté listo un lanzamiento formal, nunca intente sobrescribir un lanzamiento anterior, use un administrador de repositorio adecuado como Nexus o Artifactory), entonces debería tener un proceso de compilación que funcione bien.

Una vez que tenga un sólido proceso de construcción declarativa, abre la puerta a otras buenas prácticas como la Integración continua con Jenkins , el Análisis continuo de código con Sonar y se encontrará buscando una mejor estrategia de ramificación de control de versiones usando git .

Cada uno de los anteriores se basa en el núcleo que es Maven. En estos días, es prácticamente una decisión obvia.

— Gary Rowe
fuente

Miré la aplicación The Twelve Factor, pero es extremadamente polémica y solo un poco es relevante. También presionar a Maven no me ayuda a explicar por qué necesitamos la inyección de dependencia. En general, esta respuesta no me ayuda a vender la inyección de dependencia, solo me dice muchas cosas que debo hacer para mi proceso de compilación.

— C. Ross

La inyección de dependencias (el patrón de diseño) no es gestión de dependencias (el patrón de compilación). Ya ha cubierto todos los aspectos más importantes en su pregunta. Si su equipo aún necesita convencerse después de escucharlos, entonces ver lo que conducirá la Administración de dependencias debería ser el convencimiento final.

— Gary Rowe

Y el artículo número 1 en nuestra lista de los 10 principales es ...

(redoble de tambor)

Cada desarrollador construye con exactamente las mismas versiones de todas las dependencias, por lo que nunca tendrá que preguntarse qué implementar en producción.

— Ross Patterson
fuente

¿En qué se diferencia eso de registrar las dependencias? De hecho, si no registras las dependencias, corres el riesgo de que un tercero rompa tu distribución. Me ha sucedido esto más de una vez, cuando algunos dep de Bower apuntan a un repositorio que alguien eliminó o renombró. Si hubiera copiado la fuente en nuestro repositorio, ese problema desaparecerá.

— gman