Integración continua: reducción de riesgos
Hay posibilidades de que las cosas salgan mal en un proyecto. Al practicar la IC de forma eficaz, descubrirá lo que sucede en cada paso del camino, en lugar de más tarde, cuando el proyecto está en el ciclo de desarrollo. CI lo ayuda a identificar y mitigar los riesgos cuando ocurren, lo que facilita la evaluación y el informe sobre la salud del proyecto en función de evidencia concreta.
Esta sección se concentrará en los riesgos que se pueden evitar mediante la integración continua.
En cualquier proyecto, existen muchos riesgos que deben gestionarse. Al eliminar los riesgos al principio del ciclo de vida del desarrollo, hay menos posibilidades de que estos riesgos se conviertan en problemas más adelante, cuando el sistema se active.
Riesgo 1: falta de software implementable
“It works on my machine but does not work on another”- Esta es probablemente una de las frases más comunes que se encuentran en cualquier organización de software. Debido a la cantidad de cambios que se realizan a diario en las compilaciones de software, a veces hay poca confianza en si la compilación del software realmente funciona o no. Esta preocupación tiene los siguientes tres efectos secundarios.
Poca o ninguna confianza en si podríamos construir el software.
Fases de integración prolongadas antes de entregar el software internamente (es decir, el equipo de prueba) o externamente (es decir, el cliente), durante las cuales no se hace nada más.
Incapacidad para producir y reproducir construcciones comprobables.
Solución
Eliminando el acoplamiento estrecho entre el IDE y los procesos de construcción. Utilice una máquina separada únicamente para integrar el software. Asegúrese de que todo lo que necesita para construir el software esté contenido en el repositorio de control de versiones. Finalmente, cree un sistema de Integración Continua.
El servidor de integración continua puede observar los cambios en el repositorio de control de versiones y ejecutar el script de creación del proyecto cuando detecta un cambio en el repositorio. La capacidad del sistema de Integración Continua se puede aumentar para incluir la ejecución de pruebas, realizar inspecciones e implementar el software en los entornos de desarrollo y prueba; de esta manera siempre tendrá un software en funcionamiento.
“Inability to synchronize with the database”- A veces, los desarrolladores no pueden volver a crear la base de datos rápidamente durante el desarrollo y, por lo tanto, les resulta difícil realizar cambios. A menudo, esto se debe a una separación entre el equipo de base de datos y el equipo de desarrollo. Cada equipo se centrará en sus propias responsabilidades y tendrá poca colaboración entre ellos. Esta preocupación tiene los siguientes tres efectos secundarios:
Miedo a realizar cambios o refactorizar la base de datos o el código fuente.
Dificultad para llenar la base de datos con diferentes conjuntos de datos de prueba.
Dificultad para mantener los entornos de desarrollo y prueba (por ejemplo, desarrollo, integración, control de calidad y prueba).
Solución
La solución al problema anterior es asegurarse de que se lleve a cabo la ubicación de todos los artefactos de la base de datos en el repositorio de control de versiones. Esto significa todo lo que se requiere para recrear el esquema y los datos de la base de datos: se necesitan secuencias de comandos de creación de base de datos, secuencias de comandos de manipulación de datos, procedimientos almacenados, activadores y cualquier otro activo de la base de datos.
Reconstruya la base de datos y los datos de su secuencia de comandos de compilación, soltando y recreando su base de datos y tablas. A continuación, aplique los procedimientos almacenados y los desencadenadores y, finalmente, inserte los datos de prueba.
Pruebe (e inspeccione) su base de datos. Normalmente, utilizará las pruebas de componentes para probar la base de datos y los datos. En algunos casos, deberá escribir pruebas específicas de la base de datos.
Riesgo 2: descubrir defectos al final del ciclo de vida
Dado que hay tantos cambios que ocurren con frecuencia por parte de varios desarrolladores en el código fuente, siempre existe la posibilidad de que se introduzca un defecto en el código que solo podría detectarse en una etapa posterior. En tales casos, esto puede causar un gran impacto porque cuanto más tarde se detecta el defecto en el software, más caro resulta eliminar el defecto.
Solución
Regression Testing- Este es el aspecto más importante de cualquier ciclo de desarrollo de software, prueba y prueba nuevamente. Si hay algún cambio importante en el código del software, es absolutamente obligatorio asegurarse de que se ejecuten todas las pruebas. Y esto se puede automatizar con la ayuda del servidor de Integración Continua.
Test Coverage- No tiene sentido realizar pruebas si los casos de prueba no cubren toda la funcionalidad del código. Es importante asegurarse de que los casos de prueba creados para probar la aplicación estén completos y que se prueben todas las rutas de código.
Por ejemplo, si tiene una pantalla de inicio de sesión que debe probarse, simplemente no puede tener un caso de prueba que tenga el escenario de un inicio de sesión exitoso. Debe tener un caso de prueba negativo en el que un usuario ingrese una combinación diferente de nombres de usuario y contraseñas y luego se requiere ver qué sucede en tales escenarios.
Riesgo 3: falta de visibilidad del proyecto
Los mecanismos de comunicación manual requieren mucha coordinación para garantizar la difusión de la información del proyecto a las personas adecuadas de manera oportuna. Inclinarse hacia el desarrollador que está a su lado y hacerle saber que la última versión está en la unidad compartida es bastante efectivo, pero no se escala muy bien.
¿Qué pasa si hay otros desarrolladores que necesitan esta información y se encuentran en un descanso o no están disponibles? Si un servidor falla, ¿cómo se le notifica? Algunos creen que pueden mitigar este riesgo enviando manualmente un correo electrónico. Sin embargo, esto no puede garantizar que la información se comunique a las personas adecuadas en el momento adecuado porque puede omitir accidentalmente a las partes interesadas y es posible que algunas no tengan acceso a su correo electrónico en ese momento.
Solución
La solución a este problema es nuevamente el servidor de integración continua. Todos los servidores de CI tienen la posibilidad de tener correos electrónicos automatizados que se activan cada vez que fallan las compilaciones. Mediante esta notificación automática a todas las partes interesadas clave, también se garantiza que todos estén a bordo sobre cuál es el estado actual del software.
Riesgo 4: software de baja calidad
Hay defectos y luego hay defectos potenciales. Puede tener defectos potenciales cuando su software no está bien diseñado o si no sigue los estándares del proyecto, o es complejo de mantener. A veces, las personas se refieren a esto como olores de código o de diseño: "un síntoma de que algo puede estar mal".
Algunos creen que el software de menor calidad es únicamente un costo del proyecto diferido (después de la entrega). Puede ser un costo de proyecto diferido, pero también genera muchos otros problemas antes de entregar el software a los usuarios. El código demasiado complejo, el código que no sigue la arquitectura y el código duplicado, todos suelen provocar defectos en el software. Encontrar estos olores de código y diseño antes de que se manifiesten en defectos puede ahorrar tiempo y dinero, y puede conducir a un software de mayor calidad.
Solución
Hay componentes de software para realizar un control de calidad del código que se pueden integrar con el software CI. Esto se puede ejecutar después de que se haya creado el código para garantizar que el código realmente se ajuste a las pautas de codificación adecuadas.