Si su empresa está comenzando a implementar DevOps o herramientas de CI/CD, puede ser útil familiarizarse con los errores más comunes para no repetirlos y no caer en trampas ajenas.
Comando traducido el artículo .
Falta de preparación para el cambio de cultura y procesos
Si observamos el diagrama cíclico , se puede ver que en las prácticas de DevOps, la prueba es una tarea continua, una parte fundamental de cada implementación individual.
Diagrama cíclico infinito de DevOps
La prueba y la garantía de calidad en el proceso de desarrollo y entrega son partes obligatorias de todo lo que hacen los desarrolladores. Esto requiere un cambio de mentalidad para incluir pruebas en cada tarea.
La prueba se convierte en parte del trabajo diario de cada miembro del equipo. La transición a la prueba continua no es fácil; hay que estar preparado para ello.
Falta de retroalimentación
La efectividad de DevOps depende de la retroalimentación continua. La mejora continua es imposible sin un espacio para la colaboración y la comunicación.
A las empresas que no organizan reuniones retrospectivas les resulta difícil implementar una cultura de retroalimentación continua en CI/CD. Las reuniones retrospectivas se realizan al final de cada iteración, donde los participantes del grupo discuten lo que salió bien y lo que salió mal. Las reuniones retrospectivas son fundamentales en Scrum/Agile, pero también son necesarias para DevOps.
Esto se debe a que las reuniones retrospectivas fomentan el hábito de intercambiar comentarios y opiniones. Uno de los aspectos más importantes al inicio es organizar reuniones retrospectivas recurrentes para que sean claras y habituales para todo el equipo.
Cuando se trata de la calidad del software, todos los miembros del equipo son responsables de su mantenimiento. Por ejemplo, los desarrolladores pueden escribir pruebas modulares, así como escribir código teniendo en cuenta la capacidad de prueba, ayudando a reducir riesgos desde el principio.
Una de las formas más sencillas de reflejar el cambio en la percepción sobre las pruebas es llamar a los testers no QA, sino probadores de software o ingenieros de calidad. Este cambio puede parecer demasiado simple o incluso tonto. Pero si se llama a alguien "especialista en aseguramiento de calidad de software", se da una impresión errónea de quién es responsable de la calidad del producto. En las prácticas de Agile, CI/CD y DevOps, todos son responsables de la calidad del software.
Otro aspecto importante es entender qué significa calidad para todo el equipo y cada uno de sus miembros, así como para la organización y las partes interesadas.
Una comprensión incorrecta de la finalización de una etapa
Si la calidad es un proceso continuo y común, debe haber un entendimiento compartido de la finalización de la etapa. ¿Cómo sabemos que una etapa ha terminado? ¿Qué ocurre cuando una etapa se marca como completada en Trello o en otro tablero Kanban?
La definición de completado (DoD) es una herramienta poderosa en el contexto de CI/CD DevOps. Ayuda a entender mejor los estándares de calidad de lo que y cómo construye el equipo.
El equipo de desarrollo debe decidir qué significa "Listo". Necesitan sentarse y elaborar una lista de características que deben cumplirse en cada etapa para que se pueda considerar completada.
El DoD hace que el proceso sea más transparente y facilita la implementación de CI/CD, siempre y cuando sea comprendido por todos los miembros del equipo y acordado mutuamente.
Falta de metas realistas y claramente definidas
Este es uno de los consejos más citados, pero vale la pena repetirlo. Para el éxito de cualquier iniciativa seria, incluyendo la implementación de CI/CD o DevOps, es necesario establecer metas reales y medir el rendimiento en relación con ellas. ¿Qué intentas lograr con CI/CD? ¿Permite lanzar versiones más rápido y con mejor calidad?
Cualquier meta establecida debe ser no solo transparente y realista, sino también alinearse con las actividades actuales de la empresa. Por ejemplo, ¿con qué frecuencia necesitan sus clientes nuevas correcciones o versiones? No hay necesidad de sobrecargar los procesos y lanzar versiones más rápido si no hay beneficios adicionales para los usuarios.
Además, no siempre es necesario implementar tanto CD como CI. Por ejemplo, empresas con un alto grado de regulación, como bancos y clínicas médicas, pueden operar únicamente con CI.
CI es un buen punto de partida para cualquier empresa que implemente DevOps. Su adopción transforma significativamente los enfoques de entrega de software. Una vez dominado el CI, se puede pensar en mejorar todo el proceso, aumentar la velocidad de lanzamiento y otros cambios.
Para muchas organizaciones, un solo CI es suficiente, y el CD debe implementarse solo si aporta un valor adicional.
Falta de paneles de monitoreo y métricas adecuadas
Una vez que se han establecido los objetivos, el equipo de desarrollo puede crear un panel de control para medir los KPI. Antes de su desarrollo, vale la pena evaluar los parámetros que se van a rastrear.
Diferentes informes y aplicaciones son útiles para distintos miembros del equipo. A los Scrum Masters les interesa más el estado y la cobertura, mientras que a la alta dirección puede interesarle la velocidad de agotamiento de los especialistas.
Algunos equipos también utilizan tableros con indicadores rojos, amarillos y verdes para evaluar el estado del CI/CD, para entender si están haciendo todo correctamente o si ha habido un error. Rojo significa que debe prestarse atención a lo que está sucediendo.
Sin embargo, si los paneles no están estandarizados, pueden ser confusos. Analice qué datos necesita cada uno y luego cree una descripción estandarizada de lo que significan. Averigüe qué tiene más sentido para las partes interesadas: gráficos, texto o números.
Falta de pruebas manuales
La automatización de pruebas establece la base para un buen proceso de CI/CD. Pero las pruebas automatizadas en todas las etapas no significan que no deba realizarse pruebas manuales.
Para construir un proceso efectivo de CI/CD, se requieren también pruebas manuales. Siempre habrá ciertos aspectos de las pruebas que requieren análisis humano.
Vale la pena considerar la integración de los esfuerzos de pruebas manuales en el proceso. Después de que se completen las pruebas manuales de ciertos ejemplos de pruebas, puede avanzar a la fase de despliegue.
No intentar mejorar las pruebas
Un pipeline CI/CD efectivo requiere acceso a las herramientas adecuadas, ya sea gestión de pruebas, integración o monitoreo constante.
La creación de una cultura sólida orientada a la calidad se centra en , el monitoreo de la interacción con los clientes después del despliegue y el seguimiento de mejoras.
Aquí hay algunos consejos prácticos que puede implementar fácilmente:
- Asegúrese de que las pruebas sean fáciles de escribir y lo suficientemente flexibles para no fallar durante el refactorizado del código.
- Los equipos de desarrollo deben estar involucrados en el proceso de pruebas, viendo la lista de problemas y solicitudes de los usuarios que son importantes para verificar durante los pipelines de CI.
- Es posible que no tenga una cobertura total de pruebas, pero siempre asegúrese de que los flujos críticos para la experiencia del usuario y la interacción con los clientes estén probados.
El último, pero no menos importante punto
La transición a CI/CD suele iniciarse de abajo hacia arriba, pero, al final, es una transformación que requiere la participación de la dirección, así como una inversión de tiempo y recursos por parte de la empresa. Después de todo, CI/CD es un conjunto de habilidades, procesos, herramientas y un cambio cultural, y tales cambios solo se pueden implementar de manera sistemática.
Lecturas adicionales sobre el tema:
- .
- .
- .
Fuente: habr.com
