¿Qué significa el control de calidad para DevOps?
¿Qué es el aseguramiento de la calidad?
Bueno, de manera honrada, citaré directamente de Wikipedia:
El aseguramiento de la calidad (QA) se refiere a las actividades de ingeniería implementadas en un sistema de calidad para que se cumplan los requisitos de un producto o servicio.
Sin embargo, ¿qué significa esto para DevOps? Bueno, el producto final es el software o la aplicación que se proporciona, por lo que la mayoría de las personas se centran en sus requisitos cuando se habla de control de calidad y DevOps.
El desarrollo de software basado en TDD/BDD y las estrictas prácticas de integración continua se plantean con frecuencia.
Sin embargo, ¿estas cosas (TDD/BDD) suelen involucrar tanto al personal de desarrollo como al de operaciones?
De acuerdo. Eso suena razonable. Sin duda, son cosas que esperaría que ocurrieran dentro de un equipo de TI que profesa practicar DevOps. Sin embargo, ¿estas cosas suelen involucrar tanto al personal de desarrollo como al de operaciones? No, no lo hacen. ¿Se practicaban dentro de los equipos de desarrollo antes de que DevOps se generalizara? Sí, a menudo lo eran (aunque quizás no lo suficiente).
Si bien estas prácticas de desarrollo son parte del rompecabezas de DevOps, convertirlas en su único enfoque cuando se trata de QA y DevOps es un descuido masivo. Como se mencionó en la definición anterior, el control de calidad consiste en asegurarse de que se cumplan los requisitos (funcionales y no funcionales) de su producto o servicio. En el caso de las pruebas de código, o la aplicación final, se refiere a los requisitos del cliente. Crucial, pero no la historia completa.
¿De qué se ocupa fundamentalmente DevOps?
La relación entre el personal de desarrollo y el personal de operaciones. Con esto en mente, consideremos por un momento que el desarrollo es cliente de operaciones. El producto que necesitan es una infraestructura estable y eficiente sobre la que construir y alojar sus aplicaciones. En este caso, el control de calidad debe asegurarse de que se cumplen los requisitos de los desarrolladores (y sus aplicaciones).
Esto es algo importante que hay que entender, y la apreciación de ello por parte de las operaciones contribuirá en gran medida a resolver la tensión entre los dos equipos para la que nació el movimiento DevOps. No es necesario indagar mucho en la historia de un departamento de TI típico para encontrar ejemplos de infraestructura de calidad (a los ojos del equipo de operaciones) que no cumple con los requisitos de los desarrolladores y su aplicación. Por supuesto, con frecuencia hay buenas razones para esto (por ejemplo: seguridad), pero la conclusión es que el grado en que la infraestructura es adecuada para el propósito de los desarrolladores y su aplicación afecta directamente el grado en que la aplicación es adecuada para el propósito del cliente.
... Podemos automatizar. Sin embargo, eso no garantiza la calidad, solo garantiza la consistencia.
Entonces, ¿cómo podemos garantizar la calidad en la infraestructura y la configuración?
Bueno, podemos automatizar. Sin embargo, eso no garantiza la calidad, solo garantiza la consistencia. En el espacio de desarrollo, BDD es algo tan poderoso porque prueba en función de los requisitos del usuario final. Decir "No necesito probar mi infraestructura o configuración porque está automatizada" es como si un desarrollador dijera que no necesita probar su código porque hace lo que está escrito para hacer. El punto es que necesita validación externa.
El control de calidad para DevOps es, y probablemente siempre será, un término amplio. Sin embargo, si no puede validar de forma independiente y automática la infraestructura y la configuración de la aplicación, existe una gran brecha en su enfoque.