software integración integracion implica etapa esquema entrega despliegue desarrollo continuo continua aws continuous-integration build-automation

continuous integration - integración - ¿Por qué mi equipo de desarrollo debe tener un servidor de compilación?



integracion continua pdf (8)

Conocimiento de ASAP sobre qué pruebas de unidad están funcionando actualmente y cuáles no; además, también sabrás si una prueba de unidad que pasa una vez comienza a fallar.

Sabemos que es bueno tenerlo, pero me lo estoy justificando a mi empleador. Por favor, explique por qué un equipo de desarrollo necesita un servidor de compilación.


Dos razones principales por las que las personas no técnicas pueden relacionarse con:

  • Mejora la productividad del equipo de desarrollo porque los problemas se identifican antes.

  • Hace que el estado del proyecto sea muy obvio. Le he mostrado a mi administración el panel de estado de compilación y ahora lo miran todo el tiempo.

Una cosa más. Algo así como Hudson es muy simple de configurar: es posible que desee simplemente ejecutarlo en un rincón de la esquina por un tiempo y luego mostrarlo más tarde.


Es un tablero de prueba de calidad continua; le muestra estadísticas sobre la calidad de su software y las muestra a usted ahora. (JUnit, Cobertura)

Se asegura de que los desarrolladores no estén paralizados por otros desarrolladores que rompen la compilación, y los alienta a escribir mejor código. (FindBugs, PMD)

Le ahorra tiempo y dinero durante todo el año al obtener un mejor código de los desarrolladores la primera vez (menos dinero en pruebas y reevaluaciones) y al obtener más código de los mismos desarrolladores, porque es menos probable que se tropiecen entre sí.


Este es mi principal argumento:

  • Todos los lanzamientos oficiales deben ser construidos en un ambiente controlado. Sin excepción.

simplemente porque nunca se sabe cómo los desarrolladores crean sus lanzamientos personales.

Tampoco necesita hablar del servidor de compilación como en "blade que cuesta un brazo a una pierna". El primer servidor de compilación que configuré fue una máquina de escritorio que se encontraba desenchufada en una esquina. Nos sirvió muy bien durante más de 3 años.

Una vez que tenga su máquina de compilación, puede comenzar a agregar algunas características (Hudson es genial) e implementar todo lo que se menciona en los otros carteles.

Una vez que su máquina de compilación se vuelva indispensable para su organización (y todos vean sus beneficios), podrá solicitar una nueva hoja brillante si lo desea :-)



Hay varias razones para usar servidores de compilación. Sin ningún orden en particular y fuera de mi cabeza:

  1. Usted simplifica el flujo de trabajo de los desarrolladores y reduce la posibilidad de errores. Su servidor de compilación puede ocuparse de varios pasos, como verificar el código más reciente, tener el software requerido instalado, etc. No hay posibilidad de que un desarrollador tenga algunas DLL extraviadas en su máquina que puedan hacer que la compilación pase o falle de forma aleatoria.

    Su servidor de compilación puede replicar su entorno de destino (sistema operativo, etc.) y hay menos posibilidades de que algo funcione en los escritorios de los desarrolladores y se interrumpa la producción.

  2. Si bien es una buena práctica para los desarrolladores probar todo lo que verifican, a veces simplemente no lo hacen. Entonces es bueno tener el servidor de compilación allí para detectar errores de prueba y avisar al equipo que el producto no funciona.

  3. Las compilaciones centralizadas brindan un fácil acceso a las métricas del código: qué pruebas se aprobaron, qué fallaron, con qué frecuencia, qué tan bien está cubierto su código en sus pruebas, etc. Tener una comprensión sólida del estado de la calidad del código base reduce los costos de mantenimiento y pruebas al proporcionar Retroalimentación oportuna que permite corregir errores rápida y fácilmente.

  4. La implementación del producto es simplificada: el desarrollador o el control de calidad no tienen que recordar varios pasos manuales. Se puede automatizar fácilmente.

  5. El enlace entre los desarrolladores y QA se simplifica. El personal de control de calidad puede ir a una ubicación conocida para obtener las últimas compilaciones con versiones correctas.

  6. Es fácil configurar compilaciones para las sucursales de lanzamiento, proporcionando una red de seguridad adicional para los productos en su etapa de lanzamiento, cuando los cambios de código se deben realizar con mucho cuidado.


Lo más simple que puede hacer para convencer a su empleador de tener un servidor de compilación es decirles que podrán lanzar más rápido y con mejor calidad .

Los lanzamientos más rápidos provienen de los comentarios inmediatos sobre la calidad de la construcción. Si alguien rompe la compilación, puede corregir la compilación rota inmediatamente, evitando así un retraso en el cronograma de compilación y lanzamiento. Sin un servidor de compilación, el equipo tendrá que dedicar tiempo a tratar de encontrar qué y cuándo ocurrió y cómo solucionarlo.

El servidor de compilación ejecuta automáticamente mejores herramientas de detección de errores cada vez que alguien verifica los cambios en un sistema de control de versiones. No menciona cuál es el lenguaje de desarrollo principal en su organización, pero tales herramientas, avanzadas pero comerciales y sencillas pero gratuitas, existen prácticamente para todos los idiomas. Lint, FxCop, FindBugs y PMD vienen a la mente.

También puede consultar esta presentación sobre los beneficios de la integración continua para una discusión más extensa.


Para evitar el problema "pero funciona en mi caja".

Tenga un entorno conocido y coherente donde el software está diseñado para evitar dependencias en las cajas de desarrollo locales.

Puede usar un servidor virtual para evitar (mucho) costo adicional si lo necesita.