¿Cuál es la forma correcta de administrar scripts de desarrollador?

Los desarrolladores crean scripts para ayudar en su trabajo. Por ejemplo, para ejecutar Maven con ciertos parámetros, para eliminar tareas en segundo plano innecesarias que surgen en el desarrollo o para conectarse a un determinado servidor. Los scripts no son scripts de compilación centrales ni se utilizan en nuestro servidor de Integración continua.

¿Cuál es la mejor manera de gestionarlos? Para ponerlos en un directorio (tal vez /scripts) y registrarlos en Git? ¿Para mantenerlos por separado en algún servidor de archivos?

El argumento para tratarlos como código fuente es que son fuente y pueden cambiar. El argumento para no hacerlo es que son solo herramientas auxiliares y que no todos los desarrolladores necesitan un script determinado (por ejemplo, scripts específicos de Linux donde algunos desarrolladores trabajan en Windows).

Los scripts de desarrollador también entran en el control de versiones, porque generalmente estos scripts también dependen de los elementos en el control de versiones, por ejemplo, rutas de archivos.

Si estos scripts están versionados, también deberían funcionar para todos los desarrolladores para evitar que cada desarrollador escriba su propio conjunto de scripts, lo que se convierte en un infierno de mantenimiento.

Además, las correcciones de errores o las mejoras de estos scripts se implementan automáticamente para cada desarrollador a través del control de versiones.

Además de la respuesta de @ Simon.

No todo en la ingeniería de software se trata de programación, diseño o modelado. Hay una gran cantidad de tareas que realizamos continuamente durante la jornada laboral. Ya mencionaste uno: construir el proyecto fuera del IDE , pero hay muchos más.

Los desarrolladores experimentados / proactivos tienden a automatizar estas tareas. Algunos, incluso crean herramientas cuando estas tareas se vuelven parte del SDLC y son tediosas, y propensas a errores , que se pueden hacer a mano. Los programas son buenos para hacer trabajos repetitivos, no importa cuán tediosos sean. Nosotros - humanos , no somos tan buenos.

Estas herramientas / scripts tienen otros efectos secundarios positivos

1. Productividad
2. Transferencia de conocimiento
3. Autonomía (para recién llegados)

Entonces, sí, los scripts deberían estar en SCM y deberían ser una herramienta más en la caja de herramientas del desarrollador.

En cuanto a la carpeta /scripts, diría que no importa. Por simplicidad, los dejo en el directorio raíz del proyecto para que todas las rutas declaradas en los scripts sean relativas a la carpeta del proyecto. Si necesito acceso a carpetas o archivos externos, creo enlaces suaves .

Cosas a tener en cuenta antes de registrar los scripts en el SCM.

• Por seguridad, asegúrese de que los scripts no tengan credenciales codificadas ( idealmente, los scripts deben estar bien parametrizados )

• Asegúrese de que las secuencias de comandos no hagan cosas extrañas al sistema, como por ejemplo, para ejecutar comandos que no se pueden deshacer (lo más típico rm -rf).

• Dado que estos se convierten en parte de la fuente del proyecto, la documentación es muy apreciada.

• Las secuencias de comandos no son ciencia espacial. Hacer guiones concisos. En lugar de uno para gobernarlos a todos ... y en la oscuridad átalos , haz más, más pequeño y conciso. Como si estuvieras aplicando SRP.

Voy a ofrecer una opinión algo más negativa. Por un lado, los scripts de desarrollador que son genéricos, efectivos y útiles, por supuesto, deberían compartirse con otros desarrolladores, y la mejor manera de hacerlo es hacer que se sientan con el código en el mismo repositorio.

Sin embargo , establecería una barra alta de entrada para que se confirmen los scripts. Las secuencias de comandos son código, al igual que el software en sí. Eso significa que deben tratarse de manera similar a otras piezas de código:

• Pasando por la revisión de código
• Probado y automatizado si es posible
• Considerado cuando se realizan cambios en la base de código (específicamente, si muchos desarrolladores usan un script, hacer un cambio que rompa el script causará mucho conflicto)
• Mantenido (con todo lo que conlleva: priorización, tiempo, documentación, etc.).

Hay una serie de consideraciones adicionales que se aplican más a los scripts que al software en sí:

• En primer lugar, es mucho más difícil convencer a la propia organización y a las partes interesadas para que inviertan en el mantenimiento de scripts que faciliten la vida de los desarrolladores. Eso significa que es más difícil obtener el tiempo para cumplir con los criterios anteriores: es fácil escribir un script que funcione para usted en su entorno, pero parametrizarlo, hacerlo estable y documentarlo lleva mucho más tiempo. Esto significa que las secuencias de comandos pueden y se convertirán en código muerto a menos que un desarrollador pueda justificar mantener la secuencia de comandos actualizada.
• Es mucho menos probable que múltiples desarrolladores estén lo suficientemente familiarizados con un script complicado para mantenerlo, o que múltiples desarrolladores sientan la propiedad del código. Cuando el desarrollador original se va, encontrar a otra persona de quien tomar posesión puede ser difícil (y encontrar y justificar el tiempo para que aprendan cómo funciona el script puede ser aún más difícil).
• Es mucho más probable que un script interactúe con la máquina del desarrollador y el entorno de compilación de alguna manera. También es muy probable que tenga múltiples desarrolladores con múltiples entornos diferentes. Si un script desordena un entorno porque no se mantuvo correctamente o no se consideró un caso de esquina, no solo está rompiendo una compilación nocturna de su software, potencialmente le está costando a un desarrollador un día o más de trabajo para obtener su ambiente de vuelta a la normalidad. Esto puede causar una gran cantidad de sangre y una pérdida de confianza.
• Debido a que los scripts a menudo son externos al software en sí, mantenerlos puede ser un desafío. Si los scripts no se ejecutan a través de automatizaciones, es fácil para ellos quedarse obsoletos u olvidarse, en ese momento se han convertido en un código muerto y son solo una deuda tecnológica que alguien necesitará tomarse el tiempo para limpiar.

Para resumir, los scripts pueden ser muy útiles para un desarrollador individual, pero compartirlos como parte de la base de código en sí puede ser una tarea mucho más difícil y potencialmente puede causar más problemas de los que se resuelven.