¿Por qué debería uno usar un sistema de compilación sobre el que se incluye como parte de un IDE?

Question

He escuchado a más de una persona decir que si su proceso de compilación está haciendo clic en el botón de compilación, entonces su proceso de compilación está roto. Con frecuencia esto va acompañado de consejos para usar cosas como make, cmake, nmake, MSBuild, etc. ¿Qué ofrecen exactamente estas herramientas que justifiquen el mantenimiento manual de un archivo de configuración separado?

EDIT: Me interesan más las respuestas que se aplicarían a un único desarrollador que trabaja en un proyecto de línea ~ 20k C++, pero también me interesa el caso general.

EDIT2: Parece que no hay una buena respuesta a esta pregunta, por lo que he seguido adelante y la convertí en CW. En respuesta a aquellos que hablan de Integración Continua, sí, entiendo completamente cuando tienes muchos desarrolladores en un proyecto que tiene CI es bueno. Sin embargo, esa es una ventaja de CI, no de mantener scripts de compilación separados. Son ortogonales: por ejemplo, Team Foundation Build es una solución de CI que utiliza los archivos de proyecto de Visual Studio como su configuración.

Answer 1

Además de las necesidades de integración continua que todos los demás ya han abordado, también es posible que simplemente desee automatizar algunos otros aspectos de su proceso de compilación.Tal vez sea algo tan simple como incrementar un número de versión en una compilación de producción, o ejecutar las pruebas unitarias, o restablecer y verificar su entorno de prueba, o ejecutar FxCop o un script personalizado que automatice una revisión de código para el cumplimiento de estándares corporativos. Un script de compilación es solo una forma de automatizar algo además de su simple compilación de código. Sin embargo, la mayoría de estos tipos de cosas también se pueden lograr a través de acciones de precompilación/post compilación que casi todos los IDE modernos le permiten configurar.

A decir verdad, a menos que tenga una gran cantidad de desarrolladores que cometen a su sistema de control de código fuente, o tienen un montón de sistemas o aplicaciones que dependen de las bibliotecas compartidas y la necesidad de hacer CI, usando un script de construcción está algo excesivo en comparación con alternativas más sencillas. Pero si usted está en una de esas situaciones antes mencionadas, un servidor de construcción dedicado que tira de control de código fuente y no automatizado construye debe ser una parte esencial del arsenal de su equipo, y la forma más fácil de configurar uno es utilizar make, MSBuild, Ant , etc.

Answer 2

Si tiene un proceso de compilación de integración continuo y sin intervención, lo impulsará un script Ant o make-style. Su proceso de CI verificará el código fuera del control de la versión cuando se detecten cambios en una máquina de compilación separada, compile, pruebe, empaquete, implemente y cree un informe de resumen.

Answer 3

Digamos que tiene 5 personas trabajando en el mismo conjunto de códigos. Cada una de esas 5 personas está realizando actualizaciones en el mismo conjunto de archivos. Ahora puede hacer clic en el botón de compilación y sabe que su código funciona, pero qué ocurre cuando lo integra con los demás. Lo único que sabrás es que si obtienes lo de los demás y lo intentas. Esto es fácil de vez en cuando, pero rápidamente se vuelve tedioso hacer esto una y otra vez.

Con un servidor de compilación que lo hace automáticamente, comprueba si el código se compila para todo el mundo todo el tiempo. Todos saben siempre si algo está mal con la compilación, y cuál es el problema, y ​​nadie tiene que hacer ningún trabajo para resolverlo. Las cosas pequeñas se suman, puede llevar un par de minutos extraer el código más reciente e intentar compilarlo, pero hacerlo de 10 a 20 veces al día rápidamente se convierte en una pérdida de tiempo, especialmente si hay varias personas que lo hacen. Seguro que puede vivir sin eso, pero es mucho más fácil permitir que un proceso automatizado haga lo mismo una y otra vez, y luego hacer que una persona real lo haga.

Aquí hay otra cosa genial también. Nuestro proceso está configurado para probar todos los scripts sql también. No se puede hacer eso presionando el botón de compilación. Recarga instantáneas de todas las bases de datos que necesita para aplicar parches y ejecutarlas para asegurarse de que todas funcionen y se ejecuten en el orden en que se supone que deben hacerlo. El servidor de compilación también es lo suficientemente inteligente como para ejecutar todas las pruebas unitarias/pruebas de automatización y devolver los resultados. Asegurarse de que pueda compilarse está bien, pero con un servidor de automatización, puede manejar muchos muchos pasos automáticamente que le tomarían a una persona tal vez una hora en hacerlo.

Llevando esto un paso más allá, si tiene un proceso de implementación automatizado junto con el servidor de compilación, la implementación es automática. Cualquiera que pueda presionar un botón para ejecutar el proceso e implementar puede mover el código a qa o producción. Esto significa que un programador no tiene que perder tiempo en hacerlo manualmente, lo cual es propenso a errores. Cuando no teníamos el proceso, siempre era una trampa sobre si todo se instalaría correctamente o no, y generalmente era un administrador de red o un programador el que tenía que hacerlo, porque tenían que saber cómo configurarlo. IIS y mueve los archivos. Ahora, incluso nuestra persona qa más pequeña puede actualizar el servidor, porque todo lo que necesitan saber es qué botón presionar.

Answer 4

los sistemas de construcción IDE que he usado son todos utilizable a partir de cosas como construir herramientas Automatizado/CI lo que no hay necesidad de tener una escritura de la estructura separada como tal.

Sin embargo en la parte superior de ese sistema de construcción que necesita para automatizar las pruebas, control de versiones, el etiquetado de control de código fuente, y el despliegue (y todo lo que necesita para liberar su producto).

Así crear scripts que se extienden a su construcción IDE y hacen los extras.

Answer 5

Una razón práctica por las descripciones de construcción IDE gestionados no siempre son ideal tiene que ver con el control de versiones y la necesidad de integrar con los cambios realizados por otros desarrolladores (es decir. Fusionar).

Si el IDE utiliza un único archivo plano, puede ser muy difícil (si no imposible) para combinar dos archivos de proyecto en una sola. Puede estar utilizando un formato basado en texto, como XML, pero XML es notoriamente difícil con las herramientas estándar de diff/merge. El solo hecho de que las personas estén usando una GUI para realizar ediciones hace que sea más probable que termine con cambios innecesarios en los archivos del proyecto.

Con scripts de compilación más pequeños y distribuidos (archivos CMake, Makefiles, etc.), puede ser más fácil conciliar los cambios en la estructura del proyecto al igual que combinaría dos archivos de origen. Algunas personas prefieren la generación de proyectos IDE (usando CMake, por ejemplo) por esta razón, incluso si todos trabajan con las mismas herramientas en la misma plataforma.

Answer 6

Una razón para usar un sistema de construcción que me sorprende que nadie más haya mencionado es la flexibilidad. En el pasado, también usé el sistema de compilación incorporado de mi IDE para compilar mi código. Me encontré con un gran problema, sin embargo, cuando el IDE que estaba utilizando se suspendió. Mi capacidad para compilar mi código estaba ligada a mi IDE, por lo que me vi obligado a volver a hacer todo mi sistema de compilación. La segunda vez, sin embargo, no cometí el mismo error. Implementé mi sistema de compilación a través de makefiles para poder cambiar compiladores e IDE a voluntad sin necesidad de volver a implementar el sistema de compilación una vez más.

Encontré un problema similar en el trabajo. Teníamos una utilidad interna que fue construida como un proyecto de Visual Studio. Es una utilidad bastante simple y no ha necesitado actualización durante años, pero recientemente encontramos un raro error que debía corregirse. Para nuestra sorpresa, descubrimos que la utilidad se creó utilizando una versión de Visual Studio que tenía 5-6 versiones anteriores a las que tenemos actualmente. El nuevo VS no leería correctamente el archivo de proyecto de la versión anterior, y tuvimos que volver a crear el proyecto desde cero. A pesar de que todavía estábamos usando el mismo IDE, las diferencias de versión rompieron nuestro sistema de compilación.

Cuando utiliza un sistema de compilación por separado, tiene completamente bajo su control. Cambiar IDEs o versiones de IDEs no romperá nada.Si su sistema de compilación está basado en una herramienta de código abierto como make, tampoco debe preocuparse por la interrupción o el abandono de sus herramientas de compilación, ya que siempre puede volver a compilarlas desde el origen (más corregir errores) si es necesario. Confiar en el sistema de compilación de su IDE introduce un único punto de falla (especialmente en plataformas como Visual Studio que también integran el compilador ), y en mi opinión esa ha sido una razón suficiente para separar mi sistema de compilación e IDE.

En un nivel más filosófico, soy un firme creyente de que no es bueno automatizar algo que no entiende. Es bueno usar la automatización para ser más productivo, pero solo si tiene una comprensión sólida de lo que sucede debajo del capó (para que no se quede atascado cuando se rompe la automatización, por ninguna otra razón). Utilicé el sistema de compilación incorporado de mi IDE cuando comencé a programar porque era fácil y automático. Más tarde comencé a ser más consciente de que realmente no entendía lo que estaba sucediendo cuando hice clic en el botón "compilar". Hice un poco de lectura y comencé a armar un simple script de compilación desde cero, comparando mi salida con la del sistema de compilación del IDE. Después de un tiempo me di cuenta de que ahora tenía el poder de hacer todo tipo de cosas que eran difíciles o imposibles a través del IDE. Al personalizar las opciones de la línea de comandos del compilador más allá de lo que proporcionaba el IDE, pude producir un resultado más pequeño y ligeramente más rápido. Más importante aún, me convertí en un mejor programador al tener un conocimiento real de todo el proceso de desarrollo, desde escribir código hasta la generación de lenguaje de máquina. Comprender y controlar todo el proceso de punta a punta me permite optimizarlo y personalizarlo a la medida de cualquier proyecto en el que esté trabajando actualmente.