En esta entrega queremos prevenirte de algunos errores al realizar la transición a CI / CD (Integración Continua / Entrega Continua).

Si tu organización es nueva en DevOps o está dando los primeros pasos para implementar prácticas de CI (Integración Continua) / CD (Entrega Continua), aquí te queremos compartir algunos errores comunes que puedes evitar durante la transición.

Si has asistido últimamente a un webinar, charla o evento virtual de la industria, habrás notado que la temática generalmente deriva hacia enfoques de desarrollo.

Algo de lo que se escucha hablar bastante son las dificultades en la adopción de pruebas automatizadas, integración continua, entrega continua, pruebas ágiles, automatización de pruebas, entre otros, todos estos elementos claves de una adopción de prácticas DevOps. Si bien, estos pueden parecer palabras de moda para los no iniciados, las organizaciones de hoy están adoptando muchos de estos enfoques con éxito para impulsar ciclos de desarrollo y entrega de soluciones más rápidos, junto con software de alta calidad.

Si tu organización es nueva en DevOps, o está dando sus primeros pasos en la implementación de prácticas de CI / CD, ten siempre en mente que un cambio de este tipo no es meramente un cambio técnico, sino un proceso y una realineación cultural. Por eso, a continuación, te compartimos algunos de los errores más comunes relacionados con la cultura, los equipos, las herramientas y los procesos que puedes evitar. Es importante destacar que esta recopilación surge en base a nuestra experiencia apoyando a diversas organizaciones a implementar estas capacidades.

 

1. No adoptar un Cambio de cultura y actitud

Si has notado el diagrama de bucle infinito de DevOps, es posible que hayas visto que no hay un momento específico para realizar pruebas en él (contrario a la práctica común de probar luego de desarrollar). Esto se debe a que, a la manera de DevOps, las pruebas son una actividad continua, una parte fundamental de cada resultado.

Las pruebas dentro de un proceso de CI / CD y la garantía de calidad son parte integral de todo lo que hacen los desarrolladores. Ahora bien, esto requiere un cambio de mentalidad para incluir las pruebas como parte integral de cada tarea. Las pruebas se convierten en algo que todos los miembros del equipo están haciendo todo el tiempo como parte de sus actividades de rutina, y no la función de un rol específico en un momento determinado de tiempo.

Esta propiedad compartida de la calidad no es fácil.

Es difícil romper los paradigmas tradicionales, y para ello hay que preparar el terreno para facilitar la transición.

Las sesiones de Retrospectiva son una excelente práctica, que se debe realizar con una cadencia adecuada, para promover la colaboración, comunicación y mejora continua en el equipo.

Otra forma sencilla de ayudar a reflejar el cambio en la visión de las pruebas es cambiar los títulos de los probadores de QA a Software Tester o, mejor aún, a ingeniero de calidad. Si bien este cambio puede parecer superficial, si alguien tiene el título de «garantía de calidad del software (QA)», transmite el mensaje equivocado sobre quién tiene la responsabilidad de garantizar la calidad del producto (que, en Agile, CI / CD y DevOps son todos los miembros del equipo).

 

2. La definición de Listo

Si la calidad es un proceso continuo y compartido, entonces debe haber una comprensión compartida de la definición de listo.

¿Qué constituye como Listo? ¿Qué sucede cuando un elemento se marca como listo en el tablero Kanban? Esta Definición de Listo (DoD) es una herramienta bastante poderosa en el contexto de CI / CD. Ayuda a crear una comprensión más amplia de los estándares de calidad de lo que el equipo construye y cómo.

El DoD mejora la visibilidad del proyecto y facilita el proceso de CI / CD siempre que tenga un DoD transparente y de mutuo acuerdo.

 

3. No establecer metas realistas y bien definidas

Para el éxito de cualquier cambio importante, como CI / CD o DevOps, es necesario establecer objetivos tangibles y medir el rendimiento en función de ellos.

Este es uno de los consejos más citados, pero vale la pena repetirlo.

¿Qué es lo que está tratando de lograr con CI / CD? ¿Está reduciendo el tiempo de lanzamiento con mejor calidad? Cualquier objetivo que se establezca no solo debe ser transparente y realista, sino que también debe ajustarse al contexto actual de tu empresa. Por ejemplo, ¿con qué frecuencia necesitan tus clientes nuevas correcciones o versiones? No es necesario sobre-diseñar los procesos y lanzarlos más rápido si no hay un beneficio adicional en la experiencia del cliente.

Además, no siempre es necesario implementar tanto CD como CI. Por ejemplo, los sectores altamente regulados como los bancos y las empresas de atención médica pueden funcionar bien solo con CI. En estos sectores, como en muchas organizaciones puntuales, la CI por sí sola será suficiente y la CD solo debe implementarse si aporta un valor adicional.

 

Hasta aquí compartimos contigo esta primer entrega de nuestro listado de errores al realizar la transición a CI / CD. No te pierdas la próxima y última entrega para completar la lista.

¡Esperamos que te haya gustado y te invitamos a dejarnos tu comentario! ¡Si conoces de algún error que quieras compartir en nuestra comunidad y que no hayamos mencionado o quieras que profundicemos, por favor déjanos saber!

 

Te puede interesar:

Integración continua + Build Deploy = Agilidad en la fase de pruebas

La Automatización de Pruebas de Software en etapas tempranas del Ciclo de Vida de las Aplicaciones