2010-03-02 9 views
24

Sabemos que es bueno tener esto, pero justifica esto para mi empleador. Por favor, inclúyanse sobre por qué un equipo de desarrollo necesita un servidor de compilación.¿Por qué mi equipo de desarrollo debe tener un servidor de compilación?

+1

Gracias por las excelentes respuestas chicos, aquí hay un giro en la pregunta original. Mi empleador está de acuerdo con tener una máquina haciendo tareas de CI. Mi desafío ahora es justificar por qué esta máquina debería ser independiente. He estado usando un servidor que toda la compañía usa para las pruebas, lo que significa que todo el mundo está jugando con eso. Mi argumento es que necesitamos un entorno controlado (tal como señaló Vladimir). ¿Cuáles son sus pensamientos? y ¿Prefiere una máquina virtual o una máquina dedicada? –

+1

@H. Abraham Chavez: Esa es una pregunta diferente. Debes preguntarlo como una nueva pregunta, no aquí en un comentario. –

Respuesta

18

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

  1. Simplifica el flujo de trabajo de los desarrolladores y reduce las posibilidades de errores. Su servidor de compilación puede encargarse de varios pasos, como verificar el código más reciente, tener instalado el software requerido, etc. No hay posibilidad de que un desarrollador tenga algunos DLL perdidos en su máquina que pueden hacer que la compilación pase o falle aparentemente 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 e interrumpa la producción.

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

  3. Las construcciones centralizadas brindan fácil acceso a las métricas de código, que pasaron las pruebas, que fallaron, con qué frecuencia, qué tan bien cubren sus pruebas el código, etc. Tener una comprensión sólida del estado de calidad de la base de código reduce el mantenimiento y probar los costos al proporcionar retroalimentación oportuna que permite que los errores se solucionen rápida y fácilmente.

  4. La implementación de productos se simplifica: el desarrollador o QA no tiene que recordar múltiples pasos manuales. Se puede automatizar fácilmente.

  5. El vínculo entre los desarrolladores y el control de calidad se simplifica. El personal de control de calidad puede ir a una ubicación conocida para obtener las compilaciones actualizadas más recientes.

  6. Es fácil configurar versiones para las ramas de liberación, proporcionando una red de seguridad adicional para los productos en su etapa de liberación, cuando los cambios de código se deben hacer con especial cuidado.

20

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

Disponer de un entorno coherente y conocido en el que el software esté construido para evitar dependencias en las cajas dev locales.

Puede utilizar un servidor virtual para evitar (mucho) el costo adicional si es necesario.

4

CUANTO ANTES sepa en qué pruebas unitarias están trabajando actualmente y cuáles no; Además, también sabrá si las pruebas de unidad que pasan una vez comienzan a fallar.

3

Es un tablero de instrumentos de prueba continua de la calidad; le muestra estadísticas sobre cómo está funcionando la calidad de su software, y se lo muestra ahora. (JUnit, Cobertura)

Se asegura de que los desarrolladores no se vean obstaculizados por otros desarrolladores que rompan la compilación, y alienta a los desarrolladores a escribir mejores códigos. (FindBugs, PMD)

Le ahorra tiempo y dinero durante todo el año obteniendo mejor código de los desarrolladores la primera vez -menos dinero en pruebas y nuevas pruebas- y obteniendo más código de los mismos desarrolladores, porque son menos es probable que se tropiecen entre sí.

3

Dos razones principales que la gente no técnicos pueden estar relacionados con:

  • mejora la productividad del equipo de desarrollo, porque los problemas son identificados anteriormente.

  • 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 ven todo el tiempo.

Una cosa más. Algo como Hudson es muy simple de configurar; es posible que desee simplemente ejecutarlo en algún rincón por un tiempo y luego mostrarlo más tarde.

2

Ésta es mi principal argumento:

  • todo release oficial de se deben construir en un entorno controlado. Sin excepción.

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

Tampoco necesita hablar sobre el servidor de compilación como en "hoja que cuesta un brazo a una pierna". El primer servidor de compilación que configuré fue una máquina de escritorio que estaba desconectada en una esquina. Nos sirvió muy bien por más de 3 años.

Uno tiene su máquina de construcción, puede comenzar a agregar algunas características (Hudson es genial) e implementar todo lo que los otros carteles mencionaron.

Una vez que su máquina de construcción se convierte en indispensable para su organización (y todo el mundo ve sus beneficios), usted será capaz de pedir una nueva cuchilla brillante si lo desea :-)

0

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

Las versiones más rápidas provienen de los comentarios inmediatos sobre la calidad de la compilación. Si alguien rompe la compilación, él o ella puede arreglar 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 perder tiempo tratando de encontrar qué y cuándo sucedió y cómo solucionarlo.

Mejor calidad se logra mediante el servidor de compilación ejecutando automáticamente las herramientas de detección de errores cada vez que alguien pasa a un sistema de control de versiones. No menciona cuál es el idioma principal de desarrollo en su organización, pero esas herramientas, avanzadas pero comerciales y simples pero gratuitas, existen prácticamente para todos los idiomas. Lint, FxCop, FindBugs y PMD vienen a la mente.

También puede consultar este presentation on benefits of continuous integration para una discusión más extensa.

Cuestiones relacionadas