¿Cuáles son las ventajas de construir scripts?

Automatización.

Cuando está desarrollando, solo en los proyectos más simples, el botón «construir» por defecto hará todo lo que necesite; es posible que deba crear WS a partir de API, generar documentos, vincular con recursos externos, implementar los cambios en un servidor, etc. Algunos IDE le permiten personalizar el proceso de compilación agregando pasos o constructores adicionales, pero eso solo significa que está generando su script de construcción a través de los productos IDE.

Pero desarrollar un sistema no es solo escribir código. Hay varios pasos involucrados. Una secuencia de comandos independiente del IDE se puede ejecutar automáticamente, lo que significa que:

• Cuando confirma un cambio en el control de versiones, el servidor puede lanzar una nueva compilación automáticamente. Se asegurará de que no se haya olvidado de enviar todo lo necesario para la compilación.

• De manera similar, una vez finalizada la compilación, las pruebas se pueden ejecutar automáticamente para ver si rompió algo.

• Ahora el resto de la organización (QA, sysadmins) tiene un producto construido que

  a) es perfectamente reproducible solo desde la versión de control.

  b) es común a todos ellos.

Incluso cuando he estado trabajando como un solo hombre, he usado scripts para ese propósito; cuando había desarrollado la solución, me comprometía con SVN, exportaba el SVN de nuevo a otro directorio y usaba el script de compilación para generar la solución, que luego iría a los sistemas de preproducción y luego a la producción. Si unas semanas más tarde (con mi base de código local ya cambiada) alguien se quejara de un error, sabría exactamente qué revisión de SVN debería verificar para depurar correctamente el sistema.

Comentarios

• Esta es la mejor respuesta en mi humilde opinión. Todo el mundo tiene razón con su idea, pero esta realmente muestra por qué quiere crear scripts. Debido a que admiten la automatización que avanza a medida que su proyecto se expande, le ahorrará mucho tiempo.
• @Alexus No solo tiempo, sino también errores tontos. 😉 » La repetición conduce al aburrimiento. El aburrimiento conduce a errores horribles. Errores horribles llevan a ‘ Desearía estar todavía aburrido.’ » (También podrías medir errores tontos en el tiempo, pero ‘ s Es importante darse cuenta de que ‘ le ahorra tiempo debido a varias causas).
• Incluso para proyectos de un solo hombre, ejecutar un servidor Jenkins local para automatizar el » compilar en un directorio separado » puede ayudar. Estoy ‘ trabajando en algo en Windows que necesito confirmar también compilaciones cruzadas, por lo que hacer que Jenkins compile y ejecute pruebas, luego compile la versión compilada cruzada me da mucha más confianza ( y eficiente, ¡por supuesto!) cuando necesito lanzar correcciones de errores.
• No ‘ no estoy de acuerdo con el argumento de las compilaciones reproducibles. Hay tantas variables no controladas en los sistemas de compilación actuales que es bastante difícil obtener compilaciones reproducibles. Su argumento suena como que lo obtendrá de inmediato, lo cual no es totalmente cierto.
• @JonasGr ö ger Automation elimina uno de los variables más grandes: humanos.

Al igual que el código, la computadora ejecuta un script de compilación. Las computadoras son excepcionalmente buenas para seguir un conjunto de instrucciones. De hecho, (fuera del código de modificación automática), las computadoras ejecutarán la misma secuencia de instrucciones exactamente de la misma manera, dada la misma entrada. Esto brinda un nivel de consistencia que, bueno, solo una computadora puede igualar.

Por el contrario, las bolsas de carne llenas de agua somos simplemente despreciables cuando se trata de seguir los pasos. Ese molesto cerebro analítico tiende a cuestionar todo lo que encuentra. «Oh … no necesito hacer eso», o «¿Realmente debo usar esta bandera? Eh … Lo ignoraré. Además, tenemos la tendencia a volvernos complacientes. Una vez que hemos hecho algo varias veces, empezamos a creer que conocemos las instrucciones y no tenemos que mirar la hoja de instrucciones.

De «El Programador Pragmático»:

Además, queremos garantizar la coherencia y la repetibilidad del proyecto. Los procedimientos manuales dejan la coherencia para cambiar; la repetibilidad no está garantizada, especialmente si los aspectos del procedimiento están abiertos a la interpretación de diferentes personas.

Además, somos MUY lentos en la ejecución de instrucciones ( En un proyecto grande, con cientos de archivos y configuraciones, llevaría años ejecutar manualmente todos los pasos en un proceso de compilación.

Le daré un ejemplo del mundo real. Estaba trabajando en un software integrado, donde la mayor parte del código se compartía en algunas plataformas de hardware diferentes. Cada plataforma tenía hardware diferente, pero la mayor parte del software era el mismo. Pero había pequeñas piezas específicas para cada hardware. Idealmente, las piezas comunes se colocarían en una biblioteca y se vincularían a cada versión. Sin embargo, las piezas comunes no se pudieron compilar en una biblioteca compartida. Tuvo que compilarse con cada configuración diferente.

Al principio, compilé manualmente cada configuración. Solo tomó unos segundos cambiar entre configuraciones, y no fue un dolor tan grande. Hacia el final del proyecto, se descubrió un defecto crítico en la parte compartida del código, donde un dispositivo esencialmente se haría cargo del bus de comunicación. ¡Esto fue MALO! Muy mal. Encontré el error en el código, lo arreglé y volví a compilar cada versión. Excepto uno. Durante el proceso de construcción, me distraí y olvidé uno. Se lanzaron los binarios, se construyó la máquina y un día después recibí una llamada telefónica que decía que la máquina dejó de responder. Lo revisé y descubrí que un dispositivo había bloqueado el autobús. «¡Pero arreglé ese error!».

Puede que lo haya arreglado, pero nunca llegó a ese tablero. ¿Por qué? Porque no tenía un proceso de compilación automatizado que creara cada versión con un solo clic.

Comentarios

• Y puedes ir a tomar un café mientras ¡La secuencia de comandos de compilación se está ejecutando!

Si todo lo que quiere hacer es <compiler> **/*.<extension>, los scripts de compilación tienen poco propósito (aunque se puede argumentar que si ve un Makefile en el proyecto, sabe que puede compilarlo con make). La cuestión es que, los proyectos no triviales suelen requerir más que eso, como mínimo, normalmente necesitarás agregar bibliotecas y (a medida que el proyecto madura) configurar los parámetros de compilación.

Los IDE suelen ser al menos así de configurables, pero ahora el proceso de construcción se basa en opciones específicas de IDE.Si está utilizando Eclipse , Alice prefiere NetBeans y Bob quiere utilizar IntelliJ IDEA , no puede «compartir la configuración, y cuando uno de ustedes empuja un cambio en el control de fuente, necesita editar manualmente los archivos de configuración creados por IDE de los otros desarrolladores, o notificar a los otros desarrolladores para que lo hagan ellos mismos (lo que significa que habrá confirmaciones donde la configuración del IDE es incorrecta para algunos de los IDE …).

También necesita averigüe cómo hacer ese cambio en todos y cada uno de los IDE utilizados por el equipo, y si uno de ellos no es compatible con esa configuración en particular …

Ahora, este problema depende de la cultura – sus desarrolladores pueden encontrar aceptable no tener la opción de IDE. Pero los desarrolladores que tienen experiencia con un IDE suelen ser más felices y más eficientes al usarlo, y los usuarios de los editores de texto tienden a ser fanáticos religiosos de su favorito para ols, por lo que este es uno de los lugares donde desea dar libertad a los desarrolladores, y los sistemas de compilación le permiten hacer precisamente eso. Algunas personas pueden tener una preferencia por el sistema de compilación, pero no es tan fanático como las preferencias de IDE / editor …

Incluso si logras que todos los desarrolladores usen el mismo IDE, buena suerte para convencer a la compilación servidor para usarlo …

Ahora, eso es para las personalizaciones simples del proceso de compilación, para las que los IDE tienden a proporcionar una buena GUI. Si desea cosas más complejas, como preprocesamiento / generación automática de archivos fuente antes de la compilación, por lo general tendrá que escribir un script preconstruido en algún área de texto básica dentro de la configuración del IDE. En qué sistemas de compilación todavía tendría que codificar esa parte, pero puede hacerlo en el editor real en el que escribe el código y, lo que es más importante: el marco del sistema de compilación en sí mismo generalmente proporciona algo de soporte para organizar estos scripts.

Por último, los sistemas de compilación son buenos para algo más que compilar el proyecto; puede programarlos para realizar otras tareas que todos los miembros del equipo podrían necesitar. En Ruby en Rails , por ejemplo, existen tareas del sistema de compilación para ejecutar migraciones de bases de datos, para limpiar los archivos temporales, etc. Poner estas tareas en el sistema de compilación garantiza que todos los miembros del equipo puedan realizarlas de manera coherente.

Comentarios

• No es ‘ solo una cuestión de IDE diferentes. Algunos desarrolladores odian y detestan los IDE de todo tipo.
• @DavidHammen Yo ‘ soy uno de estos desarrolladores (aunque ‘ he configurado mi Vim tan difícilmente ‘ es posible que lo haya convertido en un IDE …), y mientras escribía ese párrafo estaba escribiendo automáticamente » editors » y tuve que arreglarlo en IDE, porque creo que el accesorio en IDE es una parte importante de mi respuesta. El autor de la pregunta claramente proviene del mundo de los IDE, y la pregunta habla del desarrollo sin IDE como algo que se ve obligado a hacer cuando no hay un IDE adecuado disponible. El objetivo de esta respuesta es mostrar cómo los sistemas de compilación son beneficiosos incluso para equipos compuestos exclusivamente por usuarios de IDE.
• Yo también soy uno de esos desarrolladores. No ‘ no quiero que mis dedos tengan que salir del teclado. Hacerlo interrumpe mis procesos de pensamiento.
• No estoy de acuerdo. Prefiero IDE. Me permiten no preocuparme por los nombres, búsquedas fáciles, refactorización, interfaz de usuario agradable. Quiero decir, si un IDE puede hacer algo por mí que de otro modo haría con sed ack, etc., lo uso.
• El punto es que con los scripts de compilación, cada desarrollador del equipo puede usar lo que prefiera, mientras que con la funcionalidad de compilación del IDE ‘ s, está obligando a todos no solo a usar un IDE, sino a usar el IDE muy específico para el que está configurado el proyecto (a menos que lo tenga configurado para múltiples IDE, y buena suerte sincronizando eso …)

Muchos IDE simplemente empaquetan los comandos utilizados para construir algo y luego generar un script y llamarlo.

Por ejemplo, en Visual Studio, puede ver los parámetros de la línea de comandos para una compilación de C ++ en el cuadro «línea de comandos». Si observa detenidamente el resultado de la compilación, verá el archivo temporal que contiene el script de compilación que se utilizó para ejecutar la compilación.

Hoy en día, es todo MSBuild , pero aún lo ejecuta directamente el IDE.

Entonces, la razón por la que usa la línea de comando es que va directamente a la fuente y se salta el intermediario, un intermediario que podría haberse actualizado o requerir un montón de dependencias que simplemente no desea o necesita en un servidor sin cabeza que actúa como su integración continua (CI) servidor.

Además, sus scripts hacen más que los pasos habituales orientados al desarrollador para los que están diseñados.Por ejemplo, después de una compilación, es posible que desee empaquetar sus binarios y copiarlos en una ubicación especial, o crear un paquete de instalación, o ejecutar una herramienta de documentación en ellos. Un servidor CI realiza muchas tareas diferentes que no tienen sentido en una máquina de desarrollo, por lo que si bien podría crear un proyecto IDE que realizara todos estos pasos, tendría que mantener dos de ellos: un proyecto para desarrolladores y otro para compilaciones. Algunas tareas de compilación (análisis estático, por ejemplo) pueden llevar mucho tiempo que no desearía para proyectos de desarrollador.

Sin embargo, en resumen, es más fácil: cree un script para hacer todas las cosas que desee. desea y es rápido y simple iniciarlo en la línea de comandos o en una configuración de servidor de compilación.

make 

es mucho más fácil de recordar y escribir que

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h 

Y los proyectos pueden tener comandos de compilación muy complejos. Un script de compilación también tiene la capacidad de recompilar solo las cosas que cambiaron. Si desea hacer una compilación limpia,

make clean 

es más fácil y más confiable una vez configurado correctamente que intentar recordar todos y cada uno de los lugares que puede tener un archivo intermedio

Por supuesto, si usa un IDE, hacer clic en un botón de compilación o limpieza también es fácil. Sin embargo, es mucho más difícil automatizar el movimiento del cursor a un lugar específico en la pantalla, especialmente cuando ese lugar puede moverse si la ventana se mueve, que automatizar un comando de texto simple.

¿De qué otra manera lo haría? La única otra forma es especificar un comando de línea de comandos largo.

Otra razón es que Los makefiles permiten la compilación incremental, lo que acelera mucho el tiempo de compilación.

Los Makefiles también pueden hacer que un proceso de compilación sea multiplataforma. CMake genera diferentes scripts de compilación basados en la plataforma.

Editar:

Con un IDE, estás atado a una forma particular de hacer las cosas. Muchas personas usan vim o emacs aunque no tienen muchas características similares a las de IDE. Lo hacen porque quieren el poder de estas los editores proporcionan. Los scripts de compilación son necesarios para aquellos que no usan un IDE.

Incluso para aquellos que usan un IDE, es posible que desee saber realmente qué está pasando, por lo que el script de compilación le ofrece los detalles más bajos de implementación que un enfoque de GUI no tiene.

Los propios IDE a menudo también usan scripts de compilación internamente; el botón Ejecutar es solo otra forma de ejecutar el comando make.

Las respuestas anteriores cubren una gran cantidad de terreno bueno, pero un ejemplo del mundo real que me gustaría agregar (que no puedo agregar como comentario debido a que no hay karma) es de la programación de Android.

Soy un profesional de Android / iOS / Windows Desarrollador de teléfonos, y yo utilizamos las API de servicios de Google (principalmente Google Maps) un lot .

En Android , estos servicios requieren que agregue un almacén de claves , o un tipo de archivo de ID de desarrollador que le dice a Google que soy quien digo ser, a una consola de desarrollador. Si mi aplicación está compilada con un almacén de claves diferente, la sección de Google Maps de la aplicación no funcionará.

En lugar de agregar y administrar una docena de almacenes de claves a la consola del desarrollador, de los cuales solo uno se puede usar para actualizar la aplicación de todos modos, incluyo este almacén de claves en nuestro repositorio seguro y use Gradle para decirle a Android Studio exactamente qué almacén de claves usar al compilar para «depurar» o «liberar». Ahora, solo tengo que agregar dos almacenes de claves a mi consola de desarrollador de Google, uno para «depurar» y otro para «liberar», y todos los miembros de mi equipo pueden clonar el repositorio y comenzar a desarrollar sin tener que ingresar al desarrollador. consola y agregue el hash SHA de su almacén de claves particular, o peor, haciéndome administrarlos . Esto tiene el beneficio adicional de darle a cada miembro del equipo una copia del almacén de claves de firma, lo que significa que si estoy fuera de la oficina y hay una actualización programada, un miembro del equipo solo necesita seguir una lista muy corta de instrucciones para enviar una actualizar.

La automatización de compilaciones como esta mantiene las compilaciones consistentes y reduce la deuda técnica al reducir el tiempo de configuración cuando obtenemos un nuevo desarrollador, una nueva máquina o cuando tenemos que volver a crear una imagen máquina.

Ventajas del script de compilación:

• los cambios parecen código (para ejemplo, en un comando git diff), no como diferentes opciones marcadas en un diálogo

• creando más resultados que una simple compilación

En algunos de mis proyectos anteriores, he utilizado los scripts de compilación para:

• generar la documentación del proyecto (basada en Doxygen)
• compilar
• ejecutar pruebas unitarias
• generar informes de cobertura de pruebas unitarias
• empaquetar binarios en un archivo de lanzamiento
• generar notas de lanzamiento internas (basadas en mensajes «git log» )
• pruebas automatizadas

A menudo, puede llamar al botón «construir» de forma automatizada (Visual Studio acepta argumentos de línea de comandos, por ejemplo). La gente escribe scripts de compilación tan pronto como necesitan algo que el botón de compilación no puede proporcionar.

Por ejemplo, la mayoría de los IDE solo le permitirán compilar una plataforma a la vez. O solo una idioma a la vez. Luego está lo que hace con las salidas integradas: ¿puede su IDE incluirlas todas en un paquete de instalación?