¿Puede alguien explicarme el concepto de Integración Continua, cómo funciona de una manera fácil de entender? ¿Y por qué una empresa debería adoptar CI en su flujo de trabajo de entrega de código? Soy desarrollador y mi empresa (principalmente el equipo de construcción) usa Team City. Como desarrollador, siempre pago, actualizo y confirmo el código a SVN, pero nunca tuve que preocuparme por TeamCity o CI en general. Entonces, ¿me gustaría entender cuál es la utilidad de CI? ¿Es CI parte de las metodologías ágiles?
11
Respuestas:
La integración continua en pocas palabras significa que guarda su trabajo, lo empuja al sistema de gestión de documentos (SVN en su caso), todas las pruebas se ejecutan automáticamente (pruebas unitarias, de integración, funcionales, etc.) y la aplicación se compila y prepara para entrega (es decir, se crea una imagen ISO). La integración continua no es lo mismo con la entrega continua. La entrega aún se realiza en diferentes momentos. CI garantiza que el producto se pueda entregar si es necesario, nada más.
Cada vez que algo sale mal, el equipo recibe una notificación. Por lo general, en ese punto, todo el trabajo se detiene y todos los esfuerzos se concentran en asegurarse de que el producto sea estable. No hay empujes y confirmaciones en el repositorio mientras el sistema no es verde.
CI garantiza que el producto esté siempre en un estado estable y que pueda entregarse en cualquier momento. Tenga en cuenta que estable no significa que la función esté completa. También puede haber características implementadas a medias, pero el sistema puede ser estable.
CI generalmente se asocia con metodologías ágiles, sin embargo, personalmente no conozco el historial exacto de CI.
fuente
Integración continua significa: integrar el código en un producto que realmente se ejecuta y puede probarse ocurre todo el tiempo , no (como era el caso anteriormente) como una actividad separada al final del ciclo de vida del desarrollo.
Requiere que el proceso de compilación de la aplicación esté completamente automatizado, y un conjunto de pruebas automatizadas, y un servidor que construya el estado actual del código y ejecute el conjunto de pruebas en él. Esto debería suceder diariamente, o incluso después de cada registro de código.
La ventaja es que hay comentarios inmediatos sobre los cambios en el código que causan errores de compilación (por ejemplo, porque el desarrollador no pudo registrar todos los cambios o utiliza algún componente que no está presente en el sistema de compilación) o fallas en los casos de prueba. Esto hace que tales errores sean mucho más fáciles de corregir, ya que sabe qué cambio los causó y la persona responsable todavía tiene nuevos recuerdos de lo que hicieron.
Sin CI, todos estos errores surgen juntos al mismo tiempo durante la etapa de integración, lo que los hace extremadamente difíciles de solucionar.
fuente
Es posible que tenga un cierto estilo en el desarrollo: pago, codificación, compilación, verificación, maldición, cambio, compilación, alegría, confirmación. Solo confirma el código de trabajo, tal vez incluso de una manera menos granular, como al final de su día de trabajo, o cuando se completa una función. Usted verifica sus dependencias cada vez que importa bibliotecas API.
Cuando comienza a codificar junto con otros y cuando hay dependencias mutuas, tiene sentido adoptar una integración continua. Simplemente porque no puede conocer el impacto de los cambios en las personas que dependen de su código, y no recibe ninguna señal cada vez que necesita actualizar sus importaciones.
Entonces, cuando cualquiera de ustedes hace un cambio, ambos proyectos deben construirse y probarse juntos, es decir, ejecutarse contra la API del otro, construirse y probarse con la nueva biblioteca, etc. Tales pruebas, su código y el de otra persona, se llaman pruebas de integración.
¿Por qué continuo? Porque es más fácil delegar la coordinación de integración a un sistema que prueba una compilación limpia cada vez que hay un cambio en cualquiera de las bases de código que organizar todo eso para un humano. El sistema puede escalar.
fuente
Hay dos aspectos para la integración continua.
El punto 1 es crítico. Es el movimiento para hacer que las fusiones que los desarrolladores realizan en realidad sean frecuentes y de naturaleza pequeña, lo que hace que las fusiones sean mucho más probables.
El punto 2 son las herramientas y el marco necesarios para permitir que el punto 1 ocurra de manera segura, identificando rápidamente las fusiones que han fallado al romper el código existente.
¿Qué tan útil es?
Increíblemente. Como desarrollador que trabaja en un proyecto, le permite pasar la mayor parte de su tiempo enfocándose en lo que está haciendo, y no preocuparse por el trabajo concurrente del resto del equipo. Cuando finaliza su trabajo actual, publica sus cambios en el resto del equipo y en las próximas horas todos fusionan sus cambios en su trabajo actual.
Sin ella, los desarrolladores están haciendo fusiones de Big Bang. Por lo general, toman varios días de su trabajo y tienen que fusionarlo con todos los cambios realizados por el resto del equipo de una sola vez. Cuando una fusión sale notablemente mal, el otro desarrollador probablemente se habrá movido a otro trabajo y comenzará a olvidar los detalles para ayudar a eliminar el desastre de la fusión. Peor aún, sin la construcción y las pruebas continuas, siempre que el código se compile, pueden aparecer errores de fusión en el código y no se eliminarán hasta que las pruebas (o los clientes) los encuentren.
fuente
CI es útil cuando tienes:
La lista puede continuar.
fuente