Un artículo para entender qué problemas resuelve la integración continua de Jenkins

1. Definición de integración continua

El maestro Martin Fowler define la integración continua de la siguiente manera: La integración continua es una práctica de desarrollo de software, es decir, los miembros del equipo de desarrollo a menudo integran su trabajo. Por lo general, cada miembro integra al menos una vez al día, lo que significa que la integración puede ocurrir varias veces al día.

La integración continua no elimina los errores, pero los hace muy fáciles de encontrar y corregir.
De acuerdo con la comprensión real del proyecto, "continuo" en integración continua se refiere a ininterrumpido; "integración" se puede dividir en sentido amplio y estrecho, integración amplia Se refiere a la integración de varios procesos de software, incluido el desarrollo, la implementación, las pruebas, etc. En un sentido estricto, la integración es la integración entre código y código, para garantizar que el código se fusione sin conflicto.

Cada integración se verifica a través de compilaciones automatizadas (incluidas la compilación, el lanzamiento y las pruebas automatizadas), de modo que los errores de integración se puedan encontrar lo antes posible. Muchos equipos han descubierto que este proceso puede reducir en gran medida los problemas de integración de código, lo que permite que el equipo desarrolle software más rápido.

Tenga en cuenta que la integración continua no es igual a la compilación continua.

2. Problemas en el proceso de desarrollo de software actual

Antes de que se aplicara la integración continua, el modelo de desarrollo tradicional se veía así:

Al inicio del proyecto, los módulos se dividen y asignan a los desarrolladores correspondientes;

Después de que un desarrollador desarrolla un módulo, realiza pruebas unitarias;

Una vez desarrollados todos los módulos, el director del proyecto integrará todos los códigos;

El administrador del proyecto implementa el proyecto integrado en el servidor de prueba y lo entrega al probador para la prueba de integración;

Si ocurre un error durante la prueba, registre el problema en la lista de errores;

El jefe de proyecto asigna el Bug al responsable correspondiente para su modificación;

Una vez completada la modificación, el administrador del proyecto integra el proyecto nuevamente y lo implementa en el servidor de prueba;

Los evaluadores realizan pruebas de regresión en la siguiente prueba de integración;

Implementar en el entorno de producción después de pasar;

Si la prueba falla, repita el trabajo anterior de "asignar error -> modificar error -> integrar código -> implementar en servidor de prueba -> prueba de integración".

Los siguientes problemas pueden surgir durante este proceso:

Los errores siempre se descubren al final.
Con el desarrollo de la tecnología de software, la escala del software también se está expandiendo y los requisitos del software se vuelven cada vez más complejos. El software ya no se puede desarrollar simplemente dividiendo módulos. A menudo requiere la cooperación mutua dentro de el proyecto Existe cierta dependencia entre ellos, por lo que los errores que existían en la etapa inicial a menudo no se descubren hasta la integración final.

Cuanto más tarde en el proyecto, más difícil es resolver el problema.
Muchos desarrolladores necesitan pasar mucho tiempo en la etapa de integración para encontrar la raíz del error. Junto con la complejidad del software, es difícil localizar la raíz del problema Y todos sabemos que cuanto más largo es el intervalo, el costo de las correcciones de errores es mayor, porque incluso los propios desarrolladores olvidan qué tipo de código escribieron en primer lugar, por lo que tienen que leer y comprender el código. desde cero

El momento de la entrega del software no se puede garantizar
precisamente porque no podemos corregir los errores a tiempo, o no podemos corregir los errores en una etapa temprana, lo que prolonga el ciclo completo de corrección de errores. En cualquier caso, es imposible para nosotros entregar el software que saber tener errores al cliente.

Además, se generó mucho trabajo que no se estimó en la etapa inicial: los desarrolladores tuvieron que dedicar mucho tiempo a encontrar errores; los evaluadores debían realizar constantemente pruebas de regresión; los gerentes de proyecto tenían que estar cansados ​​​​de integrar el maldito código, Implementar estas tareas repetitivas conduce finalmente a la prolongación de todo el ciclo del proyecto y el tiempo de entrega se retrasa.

Los programas a menudo necesitan cambiar
ciertos elementos, y los programas a menudo necesitan ser cambiados Dado que los gerentes de producto a menudo se comunican con los clientes, el software real suele ser el mejor prototipo, por lo que el software se utilizará como prototipo como una herramienta para comunicarse con los clientes. Por supuesto, lo que más esperan los clientes es, por supuesto, que las ideas del cliente se puedan reflejar en el prototipo inmediatamente, lo que hará que el programa se modifique con frecuencia. Entonces significa "asignar error -> modificar error -> integrar código -> implementar en el El trabajo del servidor de pruebas- >Pruebas de integración" ha explotado de forma invisible.

La espera ineficaz aumenta.
Es posible que el desarrollador esté esperando para integrar los módulos de otras personas; el probador está esperando que el desarrollador corrija el error; el gerente de producto está esperando que la nueva versión esté en línea para poder demostrárselo al cliente; el gerente del proyecto está esperando que otros envíen el código. Pase lo que pase, esperar significa ineficiencia.

Baja satisfacción del usuario
El usuario aquí es amplio y puede referirse al cliente final, gerente de producto, líder de la empresa, probador o incluso al desarrollador mismo Piénselo, el proyecto que originalmente se completó en tres meses se ha extendido a nueve meses o incluso un año, los usuarios pueden estar satisfechos! el proyecto no se puede iniciar y no se puede acceder, esto es muy vergonzoso.

3. Qué constituye "sostenido"

No existe una definición clara de cuántas veces al día debe integrarse. Generalmente, se establece una cierta frecuencia de acuerdo con las necesidades reales de su proyecto, que van desde unas pocas veces hasta docenas de veces. Se puede configurar para que se active de acuerdo con el código cambia la integración, o establece un período de tiempo fijo para integrar, o haga clic manualmente en el botón de integración para "integración con un solo clic".

Flujo de trabajo de integración continua
Cuando se inicia un cambio de código, el desarrollador obtiene una copia del código base actual del código base (como SVN, Git, etc.).

A medida que otros desarrolladores envíen código modificado a la base de código, esta copia dejará de reflejar gradualmente el código en la base de código. Cuanto más tiempo permanezca desprotegida la rama de código, más conflictos de integración cuando la rama del desarrollador se reintegre a la línea principal y mayor será el riesgo de falla.

Cuando los desarrolladores envían código a la base de código, primero deben actualizar su código para reflejar los últimos cambios en la base de código.

Cuando el repositorio difiere de la copia del desarrollador, primero deben tomarse el tiempo para resolver el conflicto.

4. Los beneficios de la integración continua

Liberación del trabajo repetitivo
El trabajo de implementación automatizado puede liberar el trabajo repetitivo, como la integración, las pruebas y el despliegue, y la frecuencia de integración de la máquina puede ser significativamente mayor que la del trabajo manual.

Solucionar problemas más rápido
Debido a que la integración continua adquiere los cambios antes y entra antes en las pruebas, los problemas se pueden encontrar antes y el costo de resolverlos se reduce significativamente.

Entrega de resultados más rápida
La integración temprana y las pruebas tempranas reducen las posibilidades de que los defectos se transfieran a la implementación. En algunos casos, encontrar errores antes también reduce el esfuerzo requerido para resolverlos.

Si el servidor de integración encuentra un error en el proceso de creación del código, puede enviar de inmediato un correo electrónico o un mensaje de texto al desarrollador para su reparación.

Si el servidor de integración encuentra que la versión actual no está disponible durante el proceso de implementación, el servidor de integración revertirá la implementación a la versión anterior. De esta manera, siempre habrá una versión disponible en el servidor.

Reduzca los errores manuales
Una de las mayores diferencias entre humanos y máquinas es que en acciones repetitivas, los humanos son propensos a cometer errores, mientras que la probabilidad de que las máquinas cometan errores es casi cero. Por lo tanto, después de construir el servidor de integración, el resto será entregado. paso a la integración Deje que el servidor se encargue de ello.

Reducción del tiempo de espera
La integración continua acorta el tiempo de desarrollo, integración, prueba e implementación, lo que acorta el tiempo de espera que puede ocurrir en el medio La integración continua significa que el desarrollo, la integración, la prueba y la implementación también pueden continuar.

Los servidores de integración de mayor calidad del producto
a menudo brindan revisión de código, inspección de calidad de código y otras funciones. Marcará irregularidades o errores en el código, y también puede configurar correos electrónicos, SMS, etc. para alertar. Los desarrolladores también pueden continuar usando Revisión de código Mejorar la programación habilidades.

Por último, me gustaría agradecer a todos los que han leído detenidamente mi artículo. La reciprocidad siempre es necesaria. Aunque no es algo muy valioso, si puede usarlo, puede llevárselo directamente: [Recopilado al final del artículo ]


     [El siguiente es el diagrama de sistema de arquitectura de conocimiento de aprendizaje de ingeniero de prueba de software más completo + conjunto completo de materiales que compilé en 2023]


1. De la entrada al dominio de la programación en Python

2. Proyecto de automatización de interfaz de combate real.

3. Combate real del proyecto de automatización web


4. Combate real del proyecto de automatización de aplicaciones

5. Hoja de vida de los fabricantes de primer nivel


6. Probar y desarrollar el sistema DevOps

7. Herramientas de prueba automatizadas de uso común


Ocho, prueba de rendimiento JMeter

9. Resumen (pequeña sorpresa al final)

la vida es larga así que agregue aceite. Cada esfuerzo no será defraudado, mientras perseveres, habrá recompensas al final. Valora tu tiempo y persigue tus sueños. No olvides la intención original, sigue adelante. ¡Tu futuro está en tus manos!

La vida es corta, el tiempo es precioso, no podemos predecir lo que sucederá en el futuro, pero podemos captar el momento presente. Aprecia cada día y trabaja duro para hacerte más fuerte y mejor. Creencia firme, búsqueda persistente, ¡el éxito eventualmente te pertenecerá!

Solo desafiándote constantemente a ti mismo puedes superarte constantemente. Persista en perseguir sus sueños y avance con valentía, y descubrirá que el proceso de lucha es tan hermoso y valioso. ¡Cree en ti mismo, puedes hacerlo! 

Supongo que te gusta

Origin blog.csdn.net/nhb687096/article/details/132275646
Recomendado
Clasificación