No puedo empezar este artículo sin antes agradecer a Víctor y a QALovers la oportunidad de contar a través de ellos, cómo el movimiento DevOps está ayudando a conseguir entregar software de mayor calidad en menos tiempo.
En un entorno donde cada vez contamos con más recursos y herramientas tecnológicas, y en el que el software no se limita únicamente a ordenadores personales y teléfonos móviles, sino que se amplía a un buen número de elementos que fomentan los hogares y ciudades “inteligentes”, los métodos clásicos de desarrollo y validación de calidad, se quedan obsoletos.
Se quedan obsoletos, en primer lugar, y como decía antes, por el elevado número de elementos que dependen del software en comparación a años atrás. En segundo lugar, porque, el avance tecnológico no recae únicamente en las empresas del sector IT. Y, además, en tercer lugar, se quedan obsoletos por la cada vez mayor necesidad de las organizaciones de hacer llegar sus productos al usuario antes que lo haga la competencia, cumpliendo siempre un mínimo de calidad.
Es por eso, que no es suficiente con entregar software rápido, ni es suficiente entregar software de calidad, es necesario entregar software rápido y de calidad.
Y si algo está destacando en estos últimos años, y que cada vez ayuda a más corporaciones a al cumplimiento del anterior objetivo, es la implantación de la cultura DevOps.
Así que en esta serie de artículos vamos los componentes y claves que aporta DevOps a conseguir software que hace lo que queremos que haga, que al fin y al fin y al cabo es lo que buscamos en calidad.
Si hablamos de calidad, tenemos que empezar por el principio, y el principio del software en las máquinas es… el código. Por eso, la primera clave es enfocarnos en la calidad del código, ya que es el elemento en el que como programadores o QA’s vamos a participar en mayor medida.
Y para ello debemos seguir un modelo de inspección continua que permita validar, o en el peor de los casos, detectar defectos, en el mejor momento posible, al principio, pues como veremos a continuación, aporta una serie de ventajas.
1. Qué es la inspección continua
La inspección continua, es el proceso de integrar el análisis de la calidad del código como parte del ciclo completo del desarrollo de software.
De esta forma, y al hilo de que el movimiento DevOps fomenta la cultura de la colaboración, el trabajo en equipo, mejorando los procesos y eliminando de barreras y silos que causan retrasos y defectos, la inspección continua es responsabilidad de todo el equipo que participa en el desarrollo del producto. Por eso, debe contar con el apoyo y el seguimiento de especialistas tanto del desarrollo de software, como de sistemas y de testing.
¿Y qué se debe corregir? Para responder a esta pregunta, una buena aproximación es la que ofrece SonarQube (sobre el que luego te contaré algo más) y su modelo de calidad enfocado en unos tipos concretos de evidencias.
Lo principal es encontrar dos tipos de defectos: bugs y vulnerabilidades. Si no tienes claro en qué se diferencian, debes saber que los bugs son aquellos elementos del código que causan que la aplicación falle (y seguramente lo hará en el peor momento posible), mientras que las vulnerabilidades son defectos que ofrecen a un posible atacante un agujero de seguridad que le permitiría realizar operaciones que no deseamos.
Estos dos elementos, bugs y vulnerabilidades, son los dos principales elementos que deben centrar nuestros en la inspección, pues ayudan a mantener un elevado nivel de fiabilidad y seguridad respectivamente, lo que se traduce en una mayor calidad.
Y el tercer tipo de defecto, menos prioritario, aunque nunca debe olvidarse, es el code smell, que son elementos del software que, no producen errores directamente, pero dificultan que el software sea mantenible y escalable, y que, por consiguiente, afecta directamente al nivel de mantenibilidad del software.
Así que, la inspección continua nos permite mantener a raya esos tres tipos de defectos inmediatamente tras escribir el código, por lo que habremos evitado la gran mayoría de defectos que aparecen en un software en producción.
2. Ventajas de la inspección continua
Los objetivos de la inspección continua, como decía antes, se deben centrar en la detección temprana de los defectos, al principio del desarrollo, pero ¿qué ventajas te trae esto?
Gracias la inspección continua se consigue:
- Agilizar el tiempo de desarrollo: Si eliminas los defectos en el momento de escribir el código, piensa por un lado en los procesos posteriores que se agilizarán: pruebas, validación, despliegues, etc… mientras que, por otro lado, es más fácil corregir errores si escribiste el código ayer, que si es un código heredado que ya tiene unos años.
- Reducir los costes: Si, como decía antes, entregas el producto a antes gracias a la reducción de tiempo de posteriores procesos, los costes se reducen de forma directamente proporcional al no requerir de tanto esfuerzos ni personas implicadas.
- Aumentar la calidad del producto: gracias a la automatización y que la inspección se realiza de forma continua, revisarás el código en más ocasiones, con lo que estás poniendo un mayor número de barreras a la aparición de defectos, y junto a la mayor facilidad en resolver errores, como mencionábamos en el punto anterior, se obtiene mejor software.
3. Herramientas disponibles para realizar inspección continua
Las herramientas necesarias para poder integrar la inspección continua en tu ciclo de desarrollo, se dividen en tres tipos.
En primer lugar, una herramienta tipo “linter”, que ayude a los desarrolladores a encontrar defectos en el código en el momento de escribirlo (y que no llegue ni siquiera al repositorio), y que pueda servir, además, como elemento formativo que instruya sobre las buenas prácticas que se deben seguir.
En este caso, recomiendo usar Sonarlint, disponible para los IDE’s más utilizados y gratuitos. Aunque también la mayoría de IDE’s y lenguaje cuentan con el suyo propio.
Por otro lado, debes contar con servidores de automatización, que te permitan realizar los análisis de forma: continua (siempre que haya un cambio en el código), rápida (para que muestre los resultados lo antes posible) y desatendida (que no requiera la presencia de ningún miembro del equipo durante la ejecución, más que para validar el resultado al final).
Sobre este tipo de herramientas, las más destacables que podemos ver en estos momentos son: Jenkins (Open Source, gratuito y muy extendido), Azure DevOps (una herramienta cada vez más utilizada por las organizaciones de considerable tamaño) y Gitlab (que además de automatizar, te permite disponer de otras herramientas como repositorio, wiki, etc…).
Por último, y en este caso, quizá la más importante, es necesario contar con una herramienta de análisis de código, que te permita detectar los defectos que hemos nombrado anteriormente y muestre la información de la forma más clara posible.
En este caso, mi recomendación también es clara, SonarQube, pues cuenta tanto con ediciones gratuitas para los lenguajes más habituales, como con ediciones que cumplen las necesidades de las corporaciones más grandes, aunque utilicen lenguajes menos habituales. Pero la oferta de herramientas de análisis estático no acaba aquí, también te invito a que busques información sobre otras como Kiuwan
--
Y hasta aquí, el primer artículo de esta serie de DevOps Lovers.
Si tuviera que elegir el concepto más importante que quiero que te lleves de este artículo es:
Empieza por analizar el código de forma continua, tus usuarios te lo agradecerán 😉
AUTOR: Oscar Moreno
0 Comentarios