Niñera de su sistema de integración continua

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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".

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.