Explicación simple de integración continua

¿Cómo definiría la integración continua y qué componentes específicos contiene un servidor de CI?

Quiero explicarle a alguien en el departamento de marketing qué es la integración continua. Entienden el control de la Fuente, es decir, usan Subversion. Pero me gustaría explicarles adecuadamente qué es CI. El artículo de Wikipedia nunca lo define correctamente, el artículo de Martin Fowler solo da lo siguiente, que es básicamente una tautología seguida de una vaga explicación de 'integración':

La integración continua es una práctica de desarrollo de software donde los miembros de un equipo integran su trabajo con frecuencia, generalmente cada persona se integra al menos diariamente, lo que lleva a múltiples integraciones por día. Cada integración se verifica mediante una compilación automatizada (incluida la prueba) para detectar errores de integración lo más rápido posible.

Actualización : les envié esta imagen, no pude encontrar una más simple.

Actualización 2 : retroalimentación del capítulo de marketing (para el momento en que había 3 preguntas):

De hecho, me gustan las 3 respuestas, por diferentes razones. ¡Tengo ganas de iniciar sesión solo para agradecerles a todos!

Obviamente no puede, así que gracias en su nombre :)

Actualización 3 : Me di cuenta al mirar el artículo de Wikipedia que contiene los principios que, cuando tomas solo los encabezados, es una lista bastante buena:

1. Mantener un repositorio de código
2. Automatiza la construcción
3. Realice la autocomprobación de la compilación
4. Todos se comprometen con la línea de base todos los días
5. Cada commit (a la línea de base) debe ser construido
6. Mantén la construcción rápida
7. Prueba en un clon del entorno de producción.
8. Facilite la obtención de los últimos entregables
9. Todos pueden ver los resultados de la última compilación
10. Automatizar el despliegue

Cuando alguien cambia los archivos que componen el producto de software y luego intenta incorporarlos (en otras palabras, intenta integrar los cambios en el código del producto principal), quiere asegurarse de que el producto de software todavía se pueda construir con éxito.

Por lo general, hay un sistema externo, llamado servidor CI , que periódicamente o en cada cambio, tomará los archivos fuente del control de versiones e intentará compilar el producto (compilar / probar / paquete). Si el servidor CI puede realizar una compilación con éxito, los cambios se han integrado con éxito.

El servidor CI también debe poder transmitir si la compilación falló o tuvo éxito, por lo que los sistemas como Jenkins (uno de los servidores CI más utilizados en la actualidad) tendrán formas de enviar correos electrónicos / mensajes de texto, así como una interfaz web similar a un tablero con un gran cantidad de información sobre compilaciones actuales y pasadas, quién registró el código, cuándo se rompieron las cosas, etc. (En su imagen de arriba, este sería el Mecanismo de retroalimentación ).

CI es importante porque garantiza que, de forma continua, tenga un producto que funcione. Esto es importante para todos los desarrolladores que trabajan en el producto de software, así como para todas las personas que desean tener acceso a versiones diarias del producto de software, como QA.

Supongo que para su departamento de marketing no es importante cómo funciona CI , sino qué significa CI para las nuevas versiones de su software .

Idealmente, CI significa que puede producir una nueva versión potencialmente liberable de su software todos los días, lista para ser presentada o vendida a su cliente, con algunas nuevas características, funcionalidades o correcciones de errores agregadas. Eso no significa que deba entregar la nueva versión todos los días, pero puede hacerlo si lo desea.

Por ejemplo, si tiene un nuevo conjunto de funciones planeado para ser lanzado oficialmente para la versión "2015" er de su software, y tiene partes de ese conjunto de funciones ya codificadas e integradas hoy, los encargados de marketing pueden tomar la versión actual de su software y mostrarlo, de manera más o menos segura, en la próxima conferencia ahora en 2013. Sin CI, tuvieron que pedirle a su equipo una congelación de código no planificada, cada miembro del equipo tuvo que integrar la función a medias en la que está trabajando en el producto, es posible que no tengan suficientes pruebas automáticas listas, y adivine lo que sucederá en la conferencia: la "versión alfa" de su versión 2015er tendrá un riesgo mucho mayor de fallar, especialmente cuando se demuestren las nuevas características.

No puede saber qué es CI a menos que sepa lo que solíamos hacer. Imagine un sistema con 3 partes. Hay una interfaz de usuario que recopila datos y los coloca en la base de datos. Hay un sistema de informes que realiza informes desde la base de datos. Y hay algún tipo de servidor que monitorea la base de datos y envía alertas por correo electrónico si se cumplen ciertos criterios.

Hace mucho tiempo esto se escribiría de la siguiente manera:

1. Acuerde el esquema de la base de datos y los requisitos: esto llevaría semanas porque tenía que ser perfecto, ya que pronto verá por qué
2. Asigna 3 desarrolladores, o 3 equipos independientes de desarrolladores, a las 3 piezas
3. Cada desarrollador trabajaría en su pieza y probaría su pieza usando su propia copia de la base de datos, durante semanas o meses.

Durante este tiempo, los desarrolladores no ejecutarían el código del otro, ni intentarían usar una versión de la base de datos que había sido creada por el código de otra persona. El redactor del informe solo agregaría a mano un montón de datos de muestra. El escritor de alertas agregaría manualmente registros que simularon eventos de informes. Y el escritor de la GUI miraría la base de datos para ver qué había agregado la GUI. Con el tiempo, los desarrolladores se darían cuenta de que la especificación era incorrecta de alguna manera, como no especificar un índice o tener una longitud de campo demasiado corta, y "arreglar" eso en su versión. Podrían decirle a los demás, quién podría actuar en consecuencia, pero por lo general estas cosas irían a una lista para más adelante.

Cuando las tres partes estaban completamente codificadas y probadas por sus desarrolladores, y a veces incluso probadas por los usuarios (mostrándoles un informe, una pantalla o una alerta de correo electrónico), entonces llegaba la fase de "integración". Esto a menudo se presupuestaba en varios meses, pero aún se repasaría. Ese cambio de longitud de campo por dev 1 se descubriría aquí, y requeriría que los desarrolladores 2 y 3 realicen grandes cambios de código y posiblemente también cambios en la interfaz de usuario. Ese índice adicional causaría estragos. Y así. Si un usuario le dijo a uno de los desarrolladores que agregue un campo, y lo hizo, ahora sería el momento en que los otros dos también lo deben agregar.

Esta fase fue brutalmente dolorosa y casi imposible de predecir. Entonces la gente comenzó a decir "tenemos que integrarnos más a menudo". "Tenemos que trabajar juntos desde el principio". "Cuando uno de nosotros plantea una solicitud de cambio [así hablamos], los demás deben saberlo". Algunos equipos comenzaron a hacer pruebas de integración antes mientras continuaban trabajando por separado. Y algunos equipos comenzaron a usar el código y la salida del otro todo el tiempo, desde el principio. Y eso se convirtió en Integración Continua.

Puedes pensar que estoy exagerando esa primera historia. Una vez trabajé para una compañía donde mi contacto me criticó por registrar un código que sufría de los siguientes defectos:

• una pantalla en la que no estaba trabajando tenía un botón que todavía no hacía nada
• ningún usuario había cerrado sesión en el diseño de la pantalla (colores y fuentes precisos; la existencia de la pantalla, sus capacidades y qué botones tenía en la especificación de 300 páginas).

En su opinión, no se ponen las cosas en el control de la fuente hasta que se HAGA. Normalmente hacía uno o dos registros al AÑO. Tuvimos una pequeña diferencia de filosofía :-)

Además, si le resulta difícil creer que los equipos estarían desconectados de un recurso compartido como una base de datos, realmente no creerá (pero es cierto) que se adoptó el mismo enfoque para codificar. ¿Vas a escribir una función que pueda llamar? Eso es genial, adelante y haz eso, mientras tanto codificaré lo que necesito. Meses después "integraré" mi código para que llame a su API y descubriremos que explota si paso nulo, exploto si devuelve nulo (y lo hace mucho) devuelve cosas que son demasiado grandes para mí, no puede manejar los años bisiestos y mil cosas más. Trabajar de forma independiente y luego tener una fase de integración era normal. Ahora suena a locura.