¿Cuál es el objetivo de un "servidor de compilación"? [cerrado]

No he trabajado para organizaciones muy grandes y nunca he trabajado para una empresa que tuviera un "servidor de compilación".

Cual es su proposito? ¿Por qué los desarrolladores no están construyendo el proyecto en sus máquinas locales, o lo están haciendo? ¿Son algunos proyectos tan grandes que se necesitan máquinas más potentes para construirlos en un tiempo razonable?

El único lugar en el que veo que un servidor de compilación es útil es para la integración continua con el servidor de compilación, creando constantemente lo que está comprometido con el repositorio. ¿Es que no he trabajado en proyectos lo suficientemente grandes?

Alguien, por favor, aclareme: ¿Cuál es el propósito de un servidor de compilación?

La razón dada es en realidad un gran beneficio. Las compilaciones que se someten a control de calidad solo deben provenir de un sistema que se compila solo desde el repositorio. De esta manera, los paquetes de compilación son reproducibles y rastreables. Los desarrolladores crear código manualmente para cualquier cosa, excepto para sus propias pruebas, es peligroso. Demasiado riesgo de que las cosas no se registren, estén desactualizadas con los cambios de otras personas, etc., etc.

Joel Spolsky sobre este asunto.

Los servidores de compilación son importantes por varias razones.

• Aíslan el entorno El desarrollador local de Code Monkey dice "Se compila en mi máquina" cuando no se compila en la suya. Esto puede significar registros no sincronizados o podría significar que falta una biblioteca dependiente. Jar hell no es tan malo como .dll hell; de cualquier manera, usar un servidor de compilación es una garantía barata de que sus compilaciones no fallarán misteriosamente ni empaquetarán las bibliotecas equivocadas por error.

• Enfocan las tareas asociadas con las construcciones. Esto incluye actualizar la etiqueta de compilación, crear cualquier paquete de distribución, ejecutar pruebas automatizadas, crear y distribuir informes de compilación. La automatización es la clave.

• Coordinan el desarrollo (distribuido). El caso estándar es donde varios desarrolladores están trabajando en la misma base de código. El sistema de control de versiones es el corazón de este tipo de desarrollo distribuido, pero dependiendo de la herramienta, es posible que los desarrolladores no interactúen mucho con el código de los demás. En lugar de obligar a los desarrolladores a arriesgarse a compilaciones incorrectas o preocuparse por fusionar código de manera demasiado agresiva, diseñe el proceso de compilación donde la compilación automatizada pueda ver el código apropiado y procese los artefactos de compilación de una manera predecible. De esa forma, cuando un desarrollador comete algo con un problema, como no registrar una nueva dependencia de archivo, se le puede notificar rápidamente. Hacer esto en un área preparada le permite marcar el código que se ha construido para que los desarrolladores no extraigan código que rompería su construcción local. PVCS hizo esto bastante bien usando la idea de grupos de promoción. Clearcase también podría hacerlo usando etiquetas, pero requeriría más administración de procesos de la que muchos talleres se preocupan por brindar.

Cual es su proposito?
Tome la carga de las máquinas de desarrollo, proporcione un entorno estable y reproducible para las compilaciones.

¿Por qué los desarrolladores no están construyendo el proyecto en sus máquinas locales, o lo están haciendo?
Porque con software complejo, sorprendentemente, muchas cosas pueden salir mal cuando simplemente se "compila". problemas que realmente he encontrado:

• Comprobaciones de dependencia incompletas de diferentes tipos, lo que provoca que los binarios no se actualicen.
• Los comandos de publicación fallan silenciosamente, se ignora el mensaje de error en el registro.
• Construya incluyendo fuentes locales que aún no estén comprometidas con el control de fuentes (afortunadamente, todavía no hay cuadros de mensaje de "malditos clientes" ...).
• Al intentar evitar el problema anterior construyendo desde otra carpeta, algunos archivos se seleccionaron de la carpeta incorrecta.
• La carpeta de destino donde se agregan los binarios contiene archivos de desarrollador obsoletos adicionales que no deberían incluirse en la versión

Tenemos un aumento de estabilidad asombroso ya que todas las versiones públicas comienzan con un get from source control en una carpeta vacía. Antes, había muchos "problemas divertidos" que "desaparecían cuando Joe me dio una nueva DLL".

¿Son algunos proyectos tan grandes que se necesitan máquinas más potentes para construirlos en un tiempo razonable?

¿Qué es "razonable"? Si ejecuto una compilación por lotes en mi máquina local, hay muchas cosas que no puedo hacer. En lugar de pagar a los desarrolladores para que se completen las compilaciones, pague a TI para que compre una máquina de compilación real.

¿Es que no he trabajado en proyectos lo suficientemente grandes?

El tamaño es ciertamente un factor, pero no el único.

Un servidor de compilación es un concepto distinto a un servidor de integración continua. El servidor CI existe para construir sus proyectos cuando se realizan cambios. Por el contrario, existe un servidor de compilación para compilar el proyecto (generalmente una versión, contra una revisión etiquetada) en un entorno limpio. Garantiza que ningún desarrollador hackeado, retocado, versión de configuración / artefacto no aprobada o código no comprometido se incluya en el código publicado.

El servidor de compilación se usa para compilar el código de todos cuando está registrado. Su código puede compilarse localmente, pero lo más probable es que todos los demás no realicen todos los cambios todo el tiempo.

Para agregar lo que ya se ha dicho:

Un ex colega trabajaba en el equipo de Microsoft Office y me dijo que una compilación completa a veces tomaba 9 horas. Sería una mierda hacerlo en SU máquina, ¿no?

Es necesario tener un entorno "limpio" libre de artefactos de versiones anteriores (y cambios de configuración) para garantizar que las compilaciones y las pruebas funcionen y no dependan de los artefactos. Una forma eficaz de aislar es crear un servidor de compilación independiente.

Estoy de acuerdo con las respuestas hasta ahora con respecto a la estabilidad, la trazabilidad y la reproducibilidad. (Muchos de ellos, ¿verdad?). Habiendo trabajado SOLAMENTE para grandes empresas (Salud, Finanzas) con MUCHOS servidores de compilación, agregaría que también se trata de seguridad. ¿Has visto la película Office Space? Si un desarrollador descontento crea una aplicación bancaria en su máquina local y nadie más la mira ni la prueba ... BOOM. Superman III.

Estas máquinas se utilizan por varias razones, todas tratando de ayudarlo a proporcionar un producto superior.

Un uso es simular una configuración típica de usuario final. El producto puede funcionar en su computadora, con todas sus herramientas de desarrollo y bibliotecas configuradas, pero el usuario final probablemente no tendrá la misma configuración que usted. De hecho, otros desarrolladores tampoco tendrán exactamente la misma configuración que tú. Si tiene una ruta codificada en algún lugar de su código, probablemente funcionará en su máquina, pero cuando Dev El O'per intente compilar el mismo código, no funcionará.

También se pueden usar para monitorear quién rompió el producto por última vez, con qué actualización y dónde retrocedió el producto. Siempre que se registra un nuevo código, el servidor de compilación lo construye y, si falla, está claro que algo anda mal y que el último usuario que cometió el error es el culpable.

Para obtener una calidad constante y obtener la compilación "fuera de su máquina" para detectar errores del entorno y para que cualquier archivo que olvide registrar en el control de código fuente también se muestre como errores de compilación.

También lo uso para crear instaladores, ya que requieren mucho tiempo para hacerlos en el escritorio con firma de código, etc.

Usamos uno para saber que las cajas de producción / prueba tienen las mismas bibliotecas y versiones de esas bibliotecas instaladas que las disponibles en el servidor de compilación.

Para nosotros, se trata de gestión y pruebas. Con un servidor de compilación siempre sabemos que podemos construir nuestra línea principal "troncal" desde el control de versiones. Podemos crear una instalación maestra con un clic y publicarla en la web. Podemos ejecutar todas nuestras pruebas unitarias cada vez que se registra el código para asegurarnos de que funciona. Al recopilar todas estas tareas en una sola máquina, es más fácil hacerlo bien repetidamente.

Tiene razón en que los desarrolladores podrían construir en sus propias máquinas.

Pero estas son algunas de las cosas que nos compra nuestro servidor de compilación, y no somos creadores de compilación sofisticados:

• Problemas de control de versiones (algunos se han mencionado en respuestas anteriores)
• Eficiencia. Los desarrolladores no tienen que detenerse para hacer compilaciones localmente. Pueden iniciarlo en el servidor y pasar a la siguiente tarea. Si las compilaciones son grandes, entonces es aún más tiempo que la máquina del desarrollador no está ocupada. Para aquellos que realizan una integración continua y pruebas automatizadas, incluso mejor.
• Centralización. Nuestra máquina de compilación tiene scripts que hacen la compilación, la distribuyen a entornos UAT e incluso a la etapa de producción. Mantenerlos en un solo lugar reduce la molestia de mantenerlos sincronizados.
• Seguridad. No hacemos mucho especial aquí, pero estoy seguro de que un administrador de sistemas puede hacer que las herramientas de migración de producción solo puedan ser accedidas en un servidor de compilación por ciertas entidades autorizadas.

Tal vez soy el único ...

Creo que todos están de acuerdo en que uno debería

• usar un repositorio de archivos
• hacer compilaciones desde el repositorio (y en un entorno limpio)
• use un servidor de prueba continuo (por ejemplo, control de crucero) para ver si algo está roto después de sus "arreglos"

Pero a nadie le importan las versiones creadas automáticamente. Cuando algo se rompió en una construcción automática, pero ya no lo es, ¿a quién le importa? Es un trabajo en progreso. Alguien lo arregló.

Cuando desee hacer una versión de lanzamiento, ejecute una compilación desde el repositorio. Y estoy bastante seguro de que desea etiquetar la versión en el repositorio en ese momento y no cada seis horas cuando el servidor funciona.

Entonces, tal vez un "servidor de compilación" es un nombre inapropiado y en realidad es un "servidor de prueba continua". De lo contrario, suena bastante inútil.

Un servidor de compilación le brinda una especie de segunda opinión de su código. Cuando lo registra, se verifica el código. Si funciona, el código tiene una calidad mínima.

Además, recuerde que los lenguajes de bajo nivel tardan mucho más en compilarse que los lenguajes de alto nivel. Es fácil pensar: "¡Mira, mi proyecto .Net se compila en un par de segundos! ¿Cuál es el problema?" Hace un tiempo tuve que meterme con un poco de código C y había olvidado cuánto tiempo se tarda en compilar.

Un servidor de compilación se utiliza para programar tareas de compilación (por ejemplo, compilaciones nocturnas) de proyectos generalmente grandes ubicados en un repositorio que a veces puede llevar más de un par de horas.

Un servidor de compilación también le brinda una base para la custodia, pudiendo capturar todas las partes necesarias para reproducir una compilación en el caso de que otros puedan tener derechos para tomar posesión.