¿Cuáles son las ventajas de los scripts de compilación?

Durante la mayor parte de mi carrera de programación, he usado el comando "compilar / compilar / ejecutar" en cualquier IDE con el que estoy trabajando para producir un programa ejecutable. Este es un botón, bastante fácil. Sin embargo, a medida que aprendo más sobre diferentes lenguajes y marcos, veo más y más charlas sobre "compilar scripts" (ANT, Maven, Gradle, etc.) para poner en marcha un proyecto. Según tengo entendido, son instrucciones para el compilador / enlazador / creador de programas mágicos que especifican detalles de configuración: minucias.

Recuerdo haber escrito makefiles en la escuela, pero no vi ninguna ventaja especial en ese momento (solo los usábamos cuando escribíamos en un terminal Unix, donde no había un IDE con su práctico botón "build"). Más allá de eso, he visto otras preguntas aquí que discuten cómo los scripts de compilación pueden hacer más que solo crear su programa: pueden ejecutar pruebas unitarias y recursos seguros independientemente de la máquina host .

No puedo evitar la sensación de que los scripts de compilación son importantes de entender como desarrollador, pero me gustaría una explicación significativa; ¿Por qué debería usar / escribir scripts de compilación?

Las responsabilidades de Build Script y Build Server discuten el papel que desempeña dentro de un alcance más amplio. Estoy buscando las ventajas específicas que ofrece un script de compilación frente al comando "compilar / ejecutar" de un IDE o métodos similares similares.

Automatización.

Cuando esté desarrollando, solo en los proyectos más simples el botón de "compilación" predeterminado hará todo lo que necesita hacer; Es posible que necesite crear WS a partir de API, generar documentos, vincularse 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 usted es generar su script de compilación a través de los productos IDE.

Pero desarrollar un sistema no es solo escribir código. Hay múltiples pasos involucrados. Un script independiente de IDE se puede ejecutar automáticamente, lo que significa que:

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

• Del mismo modo, después de que se realiza la compilación, las pruebas se pueden ejecutar automáticamente para ver si rompió algo.

• Ahora el resto de la organización (QA, sysadmins) ha creado un producto 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 equipo de un solo hombre, he usado guiones para ese propósito; cuando había desarrollado la solución, me comprometería con SVN, exportaba el SVN nuevamente en 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 Producción. Si algunas semanas después (con mi base de código local ya cambiada) alguien se quejó de un error, sabría exactamente qué revisión de SVN tendría que verificar para depurar correctamente el sistema.

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 auto-modificación), las computadoras ejecutarán la misma secuencia de instrucciones exactamente de la misma manera, dada la misma entrada. Esto ofrece un nivel de consistencia que, bueno, solo una computadora puede igualar.

Por el contrario, las bolsas de carne llenas de agua son simplemente despreciables cuando se trata de seguir los pasos. Ese molesto cerebro analítico tiene una tendencia a cuestionar todo lo que encuentra. "Oh ... no necesito eso", o "¿Realmente debo usar esta bandera? Eh ... simplemente la ignoraré". Además, tenemos una tendencia a ser complacientes. Una vez que hayamos hecho algo varias veces, comenzamos 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 consistencia al cambio; la repetibilidad no está garantizada, especialmente si los aspectos del procedimiento están abiertos a la interpretación de diferentes personas.

Además, HILARAMENTE somos lentos en la ejecución de instrucciones (en comparación con una computadora). 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.

Te 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 un hardware diferente, pero la mayoría del software era el mismo. Pero había pequeñas piezas que eran específicas de cada hardware. Idealmente, las piezas comunes se colocarían en una biblioteca y se vincularían en cada versión. Sin embargo, las piezas comunes no se pueden compilar en una biblioteca compartida. Tenía que ser compilado con cada configuración diferente.

Al principio, compilé manualmente cada configuración. Solo tomó unos segundos para cambiar entre configuraciones, y no fue tan difícil. 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 distraje y olvidé uno. Los binarios fueron liberados, la máquina fue construida, y un día después recibí una llamada telefónica diciendo 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 esa placa. ¿Por qué? Porque no tenía un proceso de compilación automatizado que construyera cada versión con 1 clic.

Si todo lo que quiere hacer es <compiler> **/*.<extension>construir scripts, tiene poco propósito (aunque uno puede argumentar que si ve un Makefileproyecto en el que sabe que puede construirlo make). La cuestión es que los proyectos no triviales generalmente requieren más que eso, por lo menos, generalmente necesitará agregar bibliotecas y (a medida que el proyecto madure) configurar los parámetros de compilación.

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

También debe descubrir 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 generalmente son más felices y más eficientes cuando lo usan, y los usuarios de editores de texto tienden a ser fanáticos de sus herramientas favoritas, por lo que este es uno de los lugares donde desea dar libertad a los desarrolladores - y los sistemas de construcción te permiten hacer exactamente eso. Algunas personas pueden tener una preferencia de sistema de compilación, pero no es tan fanático como las preferencias de IDE / editor ...

Incluso si logra que todos los desarrolladores usen el mismo IDE, buena suerte convenciendo al servidor de compilación para que lo use ...

Ahora, eso es para las personalizaciones simples del proceso de construcción, para las que los IDE tienden a proporcionar una GUI agradable. Si desea cosas más complejas, como preprocesar / generar automáticamente archivos fuente antes de la compilación, generalmente tendrá que escribir un script de precompilación en un área de texto básica dentro de la configuración del IDE. En qué sistemas de compilación aún 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 algún soporte para organizar estos scripts.

Finalmente, los sistemas de compilación son buenos para algo más que construir el proyecto: puede programarlos para realizar otras tareas que todos los miembros del equipo podrían necesitar realizar. En Ruby on Rails , por ejemplo, hay tareas del sistema de compilación para ejecutar migraciones de bases de datos, para limpiar los archivos temporales, etc. Al poner estas tareas en el sistema de compilación se garantiza que todos los miembros del equipo puedan realizarlas de manera consistente.

¡Muchos IDEs simplemente empaquetan los comandos utilizados para construir algo y luego generan un script y lo llaman!

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, todo es MSBuild , pero el IDE todavía lo ejecuta directamente.

Entonces, la razón por la que usa la línea de comando es que va directamente a la fuente y omite al 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 servidor de integración continua (CI).

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 que sus binarios se empaqueten y copien en una ubicación especial, o que se cree un paquete de instalación o que se ejecute una herramienta de documentación en ellos. Un servidor de CI realiza muchas tareas diferentes que no tienen sentido en una máquina de desarrollador, 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.

En resumen, es simplemente más fácil: cree un script para hacer todas las cosas que desee y es rápido y sencillo iniciarlo en la línea de comandos o en la configuración de un 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 quieres 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 en los que puede haberse producido un archivo intermedio.

Por supuesto, si usa un IDE, también es fácil hacer clic en un botón de compilación o limpieza. 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ías? La única otra forma es especificar un comando de línea de comando largo.

Otra razón es que los archivos MAKE permiten una compilación incremental, lo que acelera mucho el tiempo de compilación.

Los Makefiles también pueden hacer un proceso de construcción 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 a pesar de que no tienen muchas características similares a IDE. Lo hacen porque quieren el poder que proporcionan estos editores. 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á sucediendo, por lo que el script de compilación le ofrece los detalles de implementación que un enfoque de GUI no tiene.

Los IDE también usan scripts de construcción internamente; el botón ejecutar es solo otra forma de ejecutar el comando make.

Las respuestas anteriores cubren mucho 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 desarrollador teléfono Android / iOS / Windows profesional, y utilizar los servicios de las API de Google (Google Maps) en su mayoría un montón .

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 que soy, a una consola de desarrollador. Si mi aplicación está compilada con un almacén de claves diferente, la sección 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 todos modos solo uno de los cuales se puede usar para actualizar la aplicación, incluyo este almacén de claves en nuestro repositorio seguro y uso 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 ir 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 dar 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 se programa una actualización, un miembro del equipo solo necesita seguir una lista muy breve de instrucciones para impulsar un actualizar.

La automatización de construcciones como esta mantiene las construcciones 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 de una máquina.

Ventajas del script de construcción:

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

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

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

• generar la documentación del proyecto (basada en doxygen)
• construir
• ejecutar pruebas unitarias
• generar informes de cobertura de pruebas unitarias
• empacar 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 "compilar" de forma automatizada (Visual Studio acepta argumentos de línea de comandos, por ejemplo). Las personas escriben 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 construir una plataforma a la vez. O solo un idioma a la vez. Luego está lo que hace con las salidas integradas: ¿puede su IDE agruparlas en un paquete de instalación?