Niñera de su sistema de integración continua

22

Uno de mis roles en mi equipo es la persona de construcción . Soy responsable de mantener / actualizar nuestros scripts de compilación y asegurarme de que estamos construyendo 'sin problemas' en el servidor de integración continua. Por lo general, no me importa este trabajo, aunque a menudo parece que estoy constantemente cuidando niños del servidor de CI.

Este trabajo puede ser molesto a veces porque si la compilación se rompe, tengo que abandonar la historia en la que estoy trabajando e investigar el error de compilación. Las fallas de construcción ocurren diariamente en nuestro equipo. A veces, los desarrolladores simplemente no compilan localmente antes de comprometerse, por lo que las pruebas fallan en el servidor CI. En esta situación, me gusta llegar rápidamente a la persona que tuvo el 'mal compromiso' para que la construcción no se rompa demasiado tiempo. A veces (con mucha menos frecuencia) existe una condición extraña en el servidor de CI que debe depurarse.

Sé que muchos equipos maduros usan la integración continua, pero no hay mucho material sobre buenas prácticas.

¿Mis problemas señalan que nuestra integración continua no es muy madura o es simplemente parte del trabajo?

¿Cuáles son algunas buenas prácticas a seguir? ¿Cuáles son las características de la integración continua madura ?

Actualizar

En lugar de responder algunos comentarios, voy a hacer una actualización. Tenemos un comando único y simple que hace exactamente lo que hará el servidor de compilación al compilar la aplicación. Compilará, ejecutará todas las unidades / integración y algunas pruebas rápidas basadas en la interfaz de usuario.

Al leer las respuestas de todos, parece que podríamos tener dos problemas principales.

  1. El servidor CI no se queja lo suficientemente alto cuando falla una compilación.
  2. Los desarrolladores no sienten que es responsabilidad de todos asegurarse de que su compromiso se realice con éxito.

Lo que hace las cosas más difíciles en mi equipo es que tenemos un equipo grande (más de 10 desarrolladores) Y tenemos un par de miembros del equipo off-shore comprometidos cuando ni siquiera estamos en el trabajo. Debido a que el equipo es grande y establecimos que se prefieren pequeños compromisos frecuentes, a veces tenemos mucha actividad en un día.

c_maker
fuente
16
Vaya, he oído hablar de los desarrolladores no pruebas de código en su máquina local antes de comprometerse, pero no la construcción de ella? Eso es prácticamente criminal .
Aaronaught
2
@Alison: Tal vez sea así, aunque "romper la compilación" para mí significa cometer código que no se compila . Una prueba fallida es un tema mucho menos crítico; Por lo general, no evitará que otros desarrolladores realicen su trabajo.
Aaronaught
1
@Aaronaught personalmente lo vería como lo contrario: el código que se compila podría fallar en las pruebas automatizadas y, por lo tanto, "romper la compilación".
Armand
2
Para citar un fragmento de sonido de Martin Fowler: si te duele, hazlo con más frecuencia.
rwong
1
Alguien (si no recuerdo mal, fue Ward Cunningham) durante una conferencia me contó la práctica de su equipo: el que rompió la construcción tuvo que usar una camiseta por el día, con las palabras "Rompí la construcción". . También mencionó que la camiseta nunca se lavó.
Doc Brown,

Respuestas:

29

Primero y principal: cada persona es responsable del proceso de construcción . Parece que los miembros de su equipo no son maduros ... Nadie se salga con la suya escribiendo código y enviándolo al servidor de CI con la esperanza de que funcione. Antes de confirmar el código, debe probarse en su máquina local. Debes estar seguro de que el código que estás registrando no va a romper la compilación. Por supuesto, hay casos en los que la compilación se rompe involuntariamente (por ejemplo, si se ha cambiado un archivo de configuración o se ha realizado un descuido de confirmación sin darse cuenta).

La mayoría de los servidores de CI (solo he usado Hudson) enviarán un correo electrónico automatizado que detallará las confirmaciones realizadas que causaron la ruptura de la compilación. La única parte de su rol es mantenerse detrás de ellos luciendo duros hasta que el sospechoso arregle lo que quieran.

JK
fuente
3
¿Qué pasa si es tarde en el día y dejan el trabajo? ¿Debería haber una regla que no pueda cometer a menos que pueda asegurarse de que resultó una compilación exitosa?
c_maker
44
Me temo que amenazar fomentará grandes compromisos generales en lugar de pequeños enfocados que son preferidos.
c_maker
3
@c_maker: ¿No sería menos probable que las pequeñas confirmaciones centradas rompan la compilación? A mí me parece un problema de disciplina, no un problema de proceso.
Aaronaught
66
Cualquiera que rompa la construcción debe tomar café / pastel / lo que sea el dulce preferido de su equipo para todos. O conseguir café para todo el mundo durante todo el día, o ... Hay muchas medidas que se te ocurren que hacen que romper la construcción no sea bienvenido, sin ser tan amenazante como para evitar que las personas se sometan. Esto último también puede abordarse de alguna manera exigiendo que todos al menos presenten sus cambios una vez por semana. (Una vez al día es muy frecuente cuando se trabaja en algo más sustancial.)
Marjan Venema
55
¿A quién le importa quién rompe la construcción, siempre que la FIJEN?
21

Su equipo tiene una cosa equivocada:

Ser responsable del servidor de compilación no es lo mismo que ser responsable de la compilación .

Es responsabilidad de la persona que registra el código hacer que "funcione" (por algún valor de trabajo). La única razón para tener un servidor de compilación es detectar descuidos en este proceso. Cualquier servidor de compilación que valga la pena puede notificar a la (s) persona (s) que han registrado el código desde la última compilación (así como a cualquier otra persona interesada) con la siguiente información:

  • ¡La construcción se rompió!
  • ¡Qué salió mal al construir!
  • ¡Qué ha cambiado desde la última compilación!

Esto sucede con mucha frecuencia por correo electrónico. Es importante que esto suceda bastante rápido después de cada registro.

La persona puede ver qué salió mal y solucionarlo, y el servidor de compilación notifica a cualquier persona interesada que la compilación ha vuelto a la normalidad. Esto debería suceder por sí solo sin la participación de otros, excepto los culpables del check-in.

Entonces, para responder a su pregunta: Un entorno de CI maduro NO requiere la participación de un conserje en su funcionamiento normal.

Además, si ocurren "condiciones extrañas" con mucha frecuencia, averigüe qué la causa y haga que el sistema sea más robusto.


fuente
9

Cambia el proceso. Si un commit rompe la compilación, revierta automáticamente ese commit y notifique al desarrollador que lo rompió. Es una tontería permitir que un error de un miembro del equipo desacelere al resto del equipo. O en lugar de que las compilaciones de integración se realicen automáticamente, haga que los desarrolladores revisen la máquina de integración, y si la compilación tiene éxito, entonces pueden comprometerse. La integración continua no significa "verifique cualquier basura que desee y alguien lo solucionará por usted".

La estrategia de "rama dorada" no funciona a menos que haya un guardián para la rama dorada.

Un DVCS como Git podría ayudar; en lugar de comprometerse, el desarrollador puede enviar un conjunto de cambios para su integración al servidor de CI, y el servidor puede intentar integrar el conjunto de cambios. Si la integración tiene éxito, el conjunto de cambios se fusiona y, si no, se rechaza.

Kevin Cline
fuente
8

Un problema que veo a menudo es que los desarrolladores no pueden realizar una compilación local que tenga exactamente los mismos pasos que una compilación de CI. Es decir, el servidor CI está configurado para incluir pasos adicionales como pruebas de unidad / integración, cobertura, etc. que no se pueden realizar localmente. Inevitablemente, los desarrolladores serán mordidos por uno de los pasos que no pueden realizar localmente y comenzarán a preguntarse por qué se molestan en crear una versión local antes de registrarse.

Mantengo toda mi compilación autónoma y hago que el servidor CI simplemente inicie una compilación de lanzamiento sin configuración / pasos extraños definidos. Los desarrolladores pueden ejecutar una versión de lanzamiento localmente antes del check-in que incluye todos los pasos que realizará la compilación de CI y tienen mucha más confianza de que nada se romperá cuando hagan el check-in.

Los beneficios adicionales de este enfoque incluyen:

  • es fácil cambiar entre servidores CI porque no ha invertido mucho tiempo configurando pasos extraños
  • todas las herramientas de tiempo de compilación están bajo control de origen, lo que significa que todos los desarrolladores están utilizando exactamente el mismo conjunto de herramientas para construir su sistema
  • Además del punto anterior, es simple alterar las herramientas de construcción de manera controlada

PD. todo el concepto de niñera es ridículo, pero otros lo han cubierto.

Kent Boogaart
fuente
Amén. solo porque se pueda hacer algo , no significa que siempre se deba hacer.
gbjbaanb
7

En primer lugar, los desarrolladores no deberían romper las compilaciones regularmente, sino que deberían estar compilando y ejecutando las pruebas localmente antes de comprometerse con la rama CI. Debería ser una señal de vergüenza romper la construcción, y es importante hacer cumplir eso. Lo hice publicando estadísticas, y he visto a otros equipos tener una "bolsa de construcción" donde pones un dólar cada vez que rompes la construcción. Al final del proyecto, ese dinero se destina a la cerveza.

Si la vergüenza / orgullo personal no funciona, es posible que tenga que pasar a cosas más pesadas (por ejemplo, terminación amenazante). Romper la construcción antes de partir para el día debería ser una ofensa importante. Y cada desarrollador debe tener una notificación de estado de compilación en su escritorio. La mejor parte de todo esto es que fomenta los commits más pequeños, que se prefieren de todos modos.

Dicho esto, la compilación a veces se romperá (razones de configuración de CI, por ejemplo). Y a veces la gente se equivoca y se va por el día con la construcción rota. Es por eso que debe apuntar a un proceso que permita retrocesos rápidos y fáciles a buenas versiones conocidas. Si siempre puede retroceder a la última compilación correcta (y hacer que la versión revertida se implemente en todos los lugares necesarios), entonces, en el peor de los casos de una compilación rota donde el culpable se ha ido por la noche, puede continuar volver a la última buena versión y gritarle por la mañana.

No puedo recomendar el libro de entrega continua lo suficiente. Si está buscando una guía sobre cómo madurar su proceso de CI, inténtelo.

EZ Hart
fuente
2
Acordó romper la construcción antes de partir. Confirmas un cambio, esperas a que termine la compilación para que sepas que funcionó. No funciono? Revierta su cambio o corríjalo antes de irse. ¿No quieres hacer eso? No cometer cambios a última hora del día.
Carson63000
1
"debería" es bueno, pero cualquier factor humano es una probabilidad distinta de cero de suceder. Si la compilación es crucial, tenga uno o más servidores de compilación provisional.
3

Escuché sobre algo que Microsoft (¿tal vez?) Hacer, que es hacer que la niñera de build se mueva alrededor del equipo. La forma en que hacen esto es que cuando alguien interrumpe la compilación (lo que probablemente debería incluir el ingreso de algo que falla en sus pruebas), asumen el rol. Esto hace a las personas responsables de las consecuencias de sus acciones de una manera muy directa. Y dado que es un trabajo algo molesto, los alienta a no romper la construcción nuevamente.

La persona que actualmente es responsable de la construcción podría tener un sombrero especial. Podría haber una ceremonia para entregarlo.

Tenga en cuenta que, como dice Thorbjørn, ser responsable de la compilación no es lo mismo que ser responsable del servidor de compilación. La responsabilidad del servidor podría recaer permanentemente en uno o más miembros del equipo inclinados a la infraestructura, mientras que la responsabilidad de la construcción se mueve.

Ahora, dejando a un lado los detalles del proceso, me uniré al coro de personas que expresan consternación por los desarrolladores que se registran sin haber ejecutado una compilación y una prueba. ¡Inaceptable!

Si tiene algunos miembros del equipo que tienen más probabilidades de romper la compilación (y según mi propia experiencia, estoy pensando principalmente en los miembros de otro país), y si está utilizando un control de fuente moderno y agradable como Mercurial o Git, podría hacer que se registren en una rama diferente al resto del equipo, ejecutar un proceso de CI por separado y fusionar automáticamente los cambios de esa rama al tronco después de una compilación exitosa (tenga en cuenta que tendría que ejecuta una segunda compilación y prueba después de la fusión antes de registrar la fusión. Dado que la fusión automática no siempre es exitosa, esto eventualmente dejaría a la sucursal requiriendo atención manual, lo que podría ser un verdadero dolor. Sin embargo, podría ser menos doloroso que tener un código roto registrado para el resto del equipo.

Tom Anderson
fuente
2

Como dijo Jonathan Khoo, todos deberían ser responsables del servidor de compilación y del script de compilación. Hay tres razones:

  1. En este momento tiene un caso de un "Bus de 1", lo que significa que si un autobús lo atropella, se pierde todo el conocimiento del servidor de compilación y los scripts de compilación.
  2. Los guiones que usted ha escrito (correcta o incorrectamente) solo han tenido su aporte. Al igual que cualquier código, mientras más personas estén involucradas, más amplia será la base de conocimiento que se le puede aplicar.
  3. Finalmente, cuando algo sale mal, solo estás sintiendo el dolor. El dolor es algo bueno, pero no cuando está aislado. En este momento está lidiando con el dolor, pero si todos los demás lo sufrieran, descubriría que eventualmente serían más estrictos al probar el código antes de comprometerse.

Estoy muy involucrado con CI y caigo en la trampa de ser el que mantiene los scripts, pero aquí hay un par de cosas que puede hacer para mitigar eso.

  1. Los scripts de compilación no solo deben ejecutarse en los servidores de CI sino también en las máquinas de desarrollo local. Deben producir los mismos resultados, ejecutar las mismas pruebas y fallar por los mismos motivos. Esto permite a los desarrolladores ejecutar el script antes de confirmar su código.
  2. Si alguien rompe la construcción, hágalo público mediante el uso de ventanas emergentes de la bandeja de tareas, correos electrónicos, luces intermitentes, ruidos, etc. ayudar.
  3. Por un tiempo evite arreglar la construcción. Haz que alguien más lo haga. Si nadie más salta, espere a que sucedan cosas malas y úselo como un punto de aprendizaje para que todo el equipo comprenda por qué el servidor de CI es importante.
  4. Intente mantener el servidor de compilación y las máquinas de desarrollo tan desprovistas de componentes de terceros instalados como sea posible, especialmente mantenga limpio el GAC. Confíe en que los componentes de terceros estén en la carpeta de la biblioteca de proyectos. Esto ayuda a identificar los componentes faltantes más rápidamente.
Bronumski
fuente
Estoy totalmente en desacuerdo con avergonzar a alguien. ¿Desea que su compilador emita una alarma cuando tiene un error de sintaxis?
@ Thorbjørn Este es un servidor de CI no su caja de desarrollo local. El punto es que el equipo debe hacer todo lo que esté a su alcance para evitar registrar el código que interrumpe la compilación. Esperemos que la gente trabaje en un ambiente divertido y amigable y que la vergüenza de la que estoy hablando no sea enérgica, pero hace que la gente piense la próxima vez antes de comprometerse. Pero tenemos un sonido divertido que se reproduce cuando se rompe el servidor de compilación.
Bronumski
Todavía no estoy de acuerdo. Un servidor de construcción es solo un servidor de construcción y todos pueden cometer errores. Simplemente notifique al culpable y deje que lo arregle. Si no lo arregla, entonces podemos comenzar a considerar si alguien más debería saberlo.
@ Thorbjørn Perfectamente tener derecho a estar en desacuerdo y desacuerdo hasta cierto punto es bueno, ya que nos permite discutir diferentes ideas. Estoy deseando volver a estar en desacuerdo contigo, ahora debo volver a menospreciar a los desarrolladores junior :)
Bronumski
1

La visibilidad te ayudará. Todos los miembros del equipo deben saber que hay un problema activo que deberían solucionar. Las notificaciones por correo electrónico son útiles, pero si un desarrollador está ocupado y no reacciona de inmediato, probablemente lo olvidará y el correo electrónico terminará en una enorme pila de notificaciones.

Puede intentar usar herramientas como Catlight o BuildNotify . Muestran el estado actual de las compilaciones importantes en el área de la bandeja. Cada vez que el desarrollador mira el reloj verá que hay una compilación rota que necesita ser reparada.

Estado de advertencia de construcción de Catlight en la bandeja

Catlight también mostrará quién rompió la construcción primero, ejerciendo presión social sobre esta persona, ya que todo el equipo lo verá en cada falla de construcción consecutiva.

ingrese la descripción de la imagen aquí

alex
fuente
0

Una estrategia es utilizar muchas sucursales pequeñas para muchos proyectos pequeños. Luego, cuando alguien rompe la construcción, solo están rompiendo la construcción por sí mismos. Entonces reciben el correo electrónico molesto del servidor de compilación y les corresponde preocuparse por eso.

Otra es mejorar el nivel de responsabilidad de las personas. Por ejemplo, si usa algo como Rietveld , la gente no puede comprometerse sin pasar la revisión por pares. (El proceso en la práctica es mucho más liviano de lo que piensas que es. Pero obliga a las personas a "canalizar" y trabajar en varias cosas a la vez). Preservar la compilación es responsabilidad tanto del responsable como de los revisores. Si alguien está rompiendo regularmente la compilación o está aprobando cosas que la rompen, entonces no permita que den las aprobaciones finales para las confirmaciones. Combine con un proceso en el que cualquiera pueda deshacer fácilmente cualquier cambio, y la compilación no se romperá con tanta frecuencia, y no se mantendrá rota una vez que se realice el cambio.

btilly
fuente
Las 'muchas ramas pequeñas' no funcionan bien cuando tienes una aplicación grande a la que todos contribuyen.
c_maker
2
No, funciona bien. Sin embargo, cambia el dolor del tiempo de desarrollo al tiempo de fusión. Si fusiona pequeños paquetes de trabajo regularmente, esto no hace mucho daño.
gbjbaanb
@gbjbaanb: Correcto, es por eso que especifiqué pequeñas sucursales y pequeños proyectos. Como beneficio adicional, si la construcción principal se rompe durante una hora, lo más probable es que otras personas puedan continuar trabajando porque sus construcciones no se han roto.
btilly
@c_maker: cada estrategia viene con un conjunto de compensaciones, y ninguna es adecuada para todas las situaciones. Sin embargo, los dos que le di se están utilizando en este momento con considerable éxito en múltiples organizaciones.
btilly
0

Voy a romper con el coro aquí, y decir que en realidad, romper la compilación de vez en cuando no es tan malo, ya que muestra que se está haciendo un trabajo real. Sí, los desarrolladores deben construir y probar antes de comprometerse, pero la carga principal de la prueba debe ser asumida por las herramientas de automatización del desarrollo, incluido el servidor de integración continua. Las herramientas están ahí para ser utilizadas, y a menos que la compilación se rompa de vez en cuando, entonces no está claro que esté presionando tanto como pueda. Sin embargo, creo que la compilación nunca debería permanecer rota durante un período de tiempo significativo, e incluso favorecería las reversiones automáticas o un proceso de confirmación de múltiples etapas si eso ayuda a respaldar los objetivos gemelos de la retroalimentación rápida de las instalaciones de prueba centralizadas y automatizadas, más un baúl "verde".

William Payne
fuente
0

Parejas cosas a tener en cuenta:

  1. Su equipo necesita un conjunto de estándares a seguir.
  2. Debe tener la administración a bordo con la idea de un código limpio y esforzarse por mejorar las prácticas de código.
  3. Prueba prueba prueba! Siempre pruebe antes de registrarse.
  4. Aunque estoy de acuerdo en que está bien romper la compilación, eso es raro y me refiero a una ocasión extremadamente rara que sería aceptable. Si esto es a diario, estaría buscando la puerta o hablando con mi jefe sobre las normas.

En general, ustedes deben establecer, escribir estándares basados ​​en las mejores prácticas y no en sus prácticas individualmente (obviamente, eso no está funcionando). Una vez que todos estén de acuerdo con los estándares, comience el proceso de revisión del código y haga cumplir los estándares. Casi parece que la gerencia se fue de vacaciones y nunca regresó. Estas son cosas que honestamente son bastante básicas para cualquier tienda. La base de un buen código comienza con buenos estándares para dictar el código de los equipos y cómo está escrito. Solo mis pensamientos. Recientemente me encontré con una situación similar en mi nuevo trabajo y hablé con mi jefe. Explicado a él, necesitamos que se complete XYZ porque afecta a ABC. Dos semanas después escribí una lista de estándares de código a seguir y la presenté. Seguido por mis compañeros de trabajo dando su opinión y aproximadamente 2 meses después tuvimos normas establecidas que resolvieron toneladas de problemas.

Holmes
fuente