Si su empresa recién está implementando herramientas DevOps o CI/CD, puede ser útil que se familiarice con los errores más comunes para no repetirlos y pisar el rastrillo de otra persona.
Equipo tradujo el artículo .
Falta de voluntad para cambiar la cultura y los procesos.
Mirando el diagrama del ciclo , es claro que en las prácticas de DevOps, el testing es un trabajo continuo, parte fundamental de cada deployment individual.
Diagrama de ciclo sin fin de DevOps
Las pruebas y la garantía de calidad durante el desarrollo y la entrega son una parte esencial de todo lo que hacen los desarrolladores. Esto requiere un cambio de mentalidad para incluir pruebas en cada tarea.
Las pruebas se convierten en parte del trabajo diario de cada miembro del equipo. La transición a las pruebas continuas no es fácil, debe estar preparado para ello.
Falta de retroalimentación
La efectividad de DevOps depende de la retroalimentación constante. La mejora continua no es posible si no hay espacio para la colaboración y la comunicación.
Las empresas que no organizan reuniones retrospectivas tienen dificultades para implementar una cultura de retroalimentación continua en CI/CD. Las reuniones retrospectivas se llevan a cabo al final de cada iteración, donde los miembros del grupo discuten qué salió bien y qué salió mal. Las reuniones retrospectivas son la base de Scrum/Agile, pero también son esenciales para DevOps.
Esto se debe a que las reuniones retrospectivas inculcan el hábito de intercambiar comentarios y opiniones. Uno de los momentos más importantes en el inicio es la organización de reuniones retro recurrentes para que sean comprensibles y familiares 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 unitarias y código teniendo en cuenta la capacidad de prueba, lo que ayuda a mitigar el riesgo desde el principio.
Una manera fácil de reflejar las percepciones cambiantes de las pruebas es llamar a los probadores no QA sino probadores de software o ingenieros de calidad. Este cambio puede parecer demasiado simple o incluso estúpido. Pero llamar a alguien "especialista en aseguramiento de la calidad del software" da una idea equivocada de quién es responsable de la calidad del producto. En las prácticas Agile, CI/CD y DevOps, todos son responsables de la calidad del software.
Otro punto importante es comprender lo que significa la calidad para todo el equipo y cada uno de sus miembros, organización, partes interesadas.
Malentendido de finalización de etapa
Si la calidad es un proceso continuo y compartido, se necesita un entendimiento común de la finalización de una etapa. ¿Cómo entender que la etapa ha terminado? ¿Qué sucede cuando un hito se marca como completado en un tablero de Trello u otro tablero kanban?
Determinar un hito completado (DoD) es una herramienta poderosa en el contexto de CD DevOps/CI. Ayuda a comprender mejor los estándares de calidad de qué y cómo construye el equipo.
El equipo de desarrollo debe decidir qué significa "Terminado". Deben sentarse y hacer una lista de las características que se deben cumplir en cada etapa para que pueda considerarse completa.
DoD hace que el proceso sea más transparente y facilita la implementación de CI/CD, si está claro para todos los miembros del equipo y se acuerda mutuamente.
Falta de objetivos realistas y claramente definidos.
Este es uno de los consejos más citados, pero vale la pena repetirlo. Para que cualquier empresa seria tenga éxito, incluida la implementación de CI/CD o DevOps, debe establecer objetivos realistas y medir el rendimiento con respecto a ellos. ¿Qué está tratando de lograr con CI/CD? ¿Permite lanzamientos más rápidos con mejor calidad?
Cualquier objetivo establecido debe ser no solo transparente y realista, sino también coherente con las actividades actuales de la empresa. Por ejemplo, ¿con qué frecuencia sus clientes necesitan nuevos parches o versiones? No hay necesidad de sobrecargar los procesos y liberar más rápido si no hay un beneficio adicional para los usuarios.
Además, no siempre es necesario implementar CD y CI. Por ejemplo, las empresas altamente reguladas, como bancos y clínicas médicas, solo pueden trabajar con CI.
CI es un buen punto de partida para cualquier empresa que implemente DevOps. Cuando se implementa en una empresa, los enfoques de entrega de software cambian significativamente. Una vez que se domina la IC, puede pensar en mejorar todo el proceso, aumentar la velocidad de implementación y otros cambios.
Para muchas organizaciones, un CI es suficiente y el CD solo debe implementarse si agrega valor.
Falta de paneles y métricas relevantes
Una vez que haya establecido objetivos, el equipo de desarrollo puede crear un tablero para medir los KPI. Previo a su desarrollo, vale la pena evaluar los parámetros que serán monitoreados.
Diferentes informes y aplicaciones son útiles para diferentes miembros del equipo. Los maestros de Scrum están más preocupados por el estado y el alcance. Mientras que la alta dirección puede estar interesada en la tasa de agotamiento de los especialistas.
Algunos equipos también usan tableros con indicadores rojos, amarillos y verdes para evaluar el estado de CI / CD, para comprender si están haciendo todo bien o si se ha producido un error. Rojo significa que debes prestar atención a lo que está sucediendo.
Sin embargo, si los tableros no están estandarizados, pueden ser engañosos. Analice qué datos necesitan todos y luego cree una descripción estandarizada de lo que significa. Descubra qué tiene más sentido para sus partes interesadas: gráficos, texto o números.
Falta de pruebas manuales.
La automatización de pruebas sienta las bases para una buena canalización de CI/CD. Pero las pruebas automatizadas en todas las etapas no significan que no debas hacer pruebas manuales.
Para construir una canalización de CI/CD eficiente, también se necesitan pruebas manuales. Siempre habrá algunos aspectos de las pruebas que requieran análisis humano.
Vale la pena considerar integrar los esfuerzos de prueba manual en la canalización. Una vez que se completa la prueba manual de algunos casos de prueba, puede pasar a la fase de implementación.
No intentes mejorar las pruebas.
Una canalización de CI/CD efectiva requiere acceso a las herramientas adecuadas, ya sea gestión de pruebas o integración y monitoreo continuo.
La creación de una cultura fuerte y orientada a la calidad tiene como objetivo , supervise la experiencia del cliente después de la implementación y realice un seguimiento de las 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 romperse cuando se refactorice el código.
- Los equipos de desarrollo deben incluirse en el proceso de prueba: vea una lista de problemas y solicitudes de los usuarios que es importante probar durante las canalizaciones de CI.
- Es posible que no tenga una cobertura de prueba completa, pero siempre asegúrese de que se prueben los flujos que son importantes para UX y la experiencia del cliente.
Último pero no menos importante punto
La transición a CI/CD generalmente se inicia de abajo hacia arriba, pero al final es una transformación que requiere la participación de la administración, tiempo y recursos por parte de la empresa. Después de todo, CI/CD es un conjunto de habilidades, procesos, herramientas y reestructuración cultural, tales cambios solo pueden implementarse sistemáticamente.
¿Qué más leer sobre el tema?:
- .
- .
- .
Fuente: habr.com