AUTOMATIZACIÓN DEL SDLC
(CI/CD-SCV)

Automatización del SDLC

Configuración de pipelines para CI/CD

Niveles de Desarrollo en el SDLC y la necesidad de automatización

El SDLC entendido como un ciclo donde se van a entegar versiones de Software cada vez que se desarrolla una nueva funcionalidad (como en una arquitectura de microservicios), por lo que se trata de un proceso de desarrollo con funcionalidades incrementales o lo que es lo mismo un MVP. Estos ciclos iterativos implican prácticas como los SCV, que van a permitir mantener un historial de cambios en el codigo fuente, permitiendo así el control de versiones, este proceso implica que se creen ramas de desarrollo del código y que estas se integren y se desplieguen en un entorno de producción hacia la rama principal.
Por los tanto: estas prácticas se van a repetir, a medida avance el proyecto, por lo que el mismo carácter cíclico del SDLC y su principio de infinidad incremental implica la repetición de sus etapas, las que a consecuencia se van a automatizar, a continuación enuncio estas etapas (para ver en detalle revisar la lección Ciclo de Vida de Software ).
Estos son:
Planificación, Codificación, Construcción, Pruebas, Lanzamiento, Despliegue, Operación y Monitoreo

En cada etapa se van a realizar tareas específicas, hasta poder entregar el MVP y para que esto sea posible hay que crear el código e integrarlo con el proyecto final, por lo que se debe asegurar que cada cambio se integre correctamente y se despliegue correctamente, en otras palabras se deben realizar pruebas constantemente.
Se trata de múltiples pruebas desde la sintaxis propia del lenguaje con que se escribió el código, los componenentes y módulos, la integración de estos, en fin son tareas complejas, cíclicas y reiterativas
Además en los proyectos trabajan en paralelo varios desarrolladores, por lo que se deben realizar pruebas en paralelo en diferentes entornos para cada cambio que un realizador crea.
Por lo tanto se deben automatizar las tareas de integración y despliegue en el flujo de SDLC para que el proceso de desarrollo sea eficiente y se optimicen las entregas de los MVP. Decimos automatizar tareas como las pruebas, las revisiones del código y los despliegues, pero todo este flujo implica crear una metodología que asegure que todas las etapas del SDLC se realicen de manera eficiente y eficaz.

Automatización en el flujo de SDLC: CI/CD

La automatización en el flujo de SDLC implica crear metodologías que incluyan procedimientos y buenas prácticas que abarquen el sistema de control de versiones, la integración de los cambios en el código fuente en los difrentes entornos, el despliegue de los cambios y la entrega del producto final.
Estas metodologías de Automatización es lo que se conoce como el DevOPs, o sea la programación de las operaciones en el flujo de SDLC, a través de herramientas de Software.
Las tareas de DevOps se pueden clasificar de la siguiente manera:
- La creación, pruebas y entrega del código como una Integración Continua ó CI.
- El Despliegue y entrega Continua CD .
Esta división de las tareas de DevOps se corresponde con las etapas del SDLC, CI comprende las etapas de Código, Construcción y Pruebas, CD es la etapa de Despliegue y Entrega .
En resumen,DevOps: Es una metodología de buenas prácticas de procesos automatizados, eficientes y rápidos que buscan llevar un producto al mercado e innovar en sus funcionalidades.
En muchos proyectos esta metodología la implementan Desarrolladores especializados en servidores e infraestructura, aunque este proceso implica a todos los relacionados con el SDLC, en especial los QA tienen un papel importante, ya que como dije antes, el flujo de CI/CD implica la automatización de las pruebas a difrentes niveles de desarrollo o entornos.

Integración Continua CI: - Objetivo:Asegurar que el código de un programador se integre sin conflictos con el trabajo de otros programadores; - Etapas: Planificación, Construcción, Pruebas; - Proceso:Implica que los desarrolladores integran frecuentemente su código en un repositorio compartido. Cada integración es verificada por una construcción automatizada y pruebas automatizadas.
Si las pruebas fallan, la integración no se permite, lo que previene que los errores se propaguen y facilita su detección temprana; - Beneficios: Reduce los conflictos de código, mantiene el código base estable y funcional, y facilita la identificación y corrección rápida de errores
Despliegue Continuo CD: - Objetivo: Enviar automáticamente los nuevos cambios que han pasado las pruebas de CI a producción; - Etapas:Construcción, Pruebas, Despliegue; - Proceso: Si el código pasa todas las pruebas automatizadas en la fase de CI, se despliega automáticamente a un entorno de staging y, si se cumplen ciertos criterios o se da una aprobación manual (en el caso de Continuous Delivery), se libera a producción. El término "continuo" implica que los cambios se integran y pasan a producción de forma constante, sin detener el proceso; - Beneficios:Permite entregar nuevas funcionalidades y correcciones de errores a los usuarios de manera más rápida y frecuente, lo que mejora la alta disponibilidad de la aplicación al poder reiniciar, escalar o revertir a versiones anteriores fácilmente. También ayuda a gestionar la alta complejidad de las aplicaciones al permitir el mantenimiento y la adición de funciones de forma aislada

La importancia de las prácticas de QA y su automatización en CI/CD

Para CI/CD se crean diferentes ambientes de desarrollo, pruebas y despliegue y en cada ambiente se ejecutan tareas específicas y pruebas específicas. A nivel más básico como comprobaciones se pueden hacer directas al código fuente, pruebas de sintaxis a los lenguajes de programación, pruebas unitarias, pruebas de integración y pruebas de aceptación.

Reduce los conflictos de código
Mantiene el código base estable y funcional
Reducción del tiempo de prueba: Las pruebas automatizadas se ejecutan en minutos o segundos, a diferencia de las horas o días que pueden tomar las pruebas manuales, lo que acelera significativamente los ciclos de desarrollo y despliegue
Detección temprana de errores: Los defectos se identifican de inmediato en la pipeline de CI/CD, evitando que errores críticos lleguen a producción. Este es el principio del "Shift-Left Testing", que busca incorporar actividades de calidad desde el inicio del ciclo de desarrollo para prevenir problemas
Reduce la complejidad de las aplicaciones al permitir el mantenimiento y la adición de funciones de forma aislada
Mayor cobertura de pruebas: Los scripts automatizados pueden evaluar múltiples escenarios, plataformas y configuraciones en paralelo, lo que amplía la cobertura sin intervención manual
Permite entregar nuevas funcionalidades y correcciones de errores a los usuarios de manera más rápido y frecuente
Mayor velocidad y eficiencia en los ciclos de lanzamiento: Al automatizar tareas repetitivas, los equipos pueden liberar código con más frecuencia y confianza, acelerando los ciclos de lanzamiento sin sacrificar la calidad

Configuración de pipelines para CI/CD

La integración continua del código se va a realizar a través canales o Pipelines. Estos pipelines funcionan como canales complejos, por el cual va a transitar cada código que se va integrando, provocando una nueva versión del código fuente. La definición de una canalización se escribe en un archivo con un conjunto extensible de herramientas para modelar canales de entrega, desde simples hasta complejos, "como código" a través comprobaciones de sintaxis, pruebas unitarias y de integración.
Cada pipeline se encarga de un conjunto de tareas que se van a ejecutar en el orden que se va a definir, cómo un programa que a su vez también tendrá un código ejecutable, descrito en el archivo antes mencionado, que, a su vez, puede enviarse al repositorio de control de código fuente de un proyecto.
Esta es la base de "Canalización como código", que se va a tratar la canalización de CD como parte de la aplicación que debe ser versionada y revisada como cualquier otro código.
¿Que es un Pipeline?
Los pipelines son sistemas que se configuran con un conjunto de herramientas, en su lógica interna va a contener instrucciones, qur no son más que los pasos que se van a ejecutar, una vez que se detecte un cambio en el repositorio controlado por un SCV donde se envían los cambios del código fuente. Podrá tener un conjunto de tareas como ejecutar pruebas al código, automáticamente, después de cada confirmación y envío de cambios, luego va a trabajar con ramas y va realizar merge de ramas y el código se va a desplegar a un entorno de pruebas y por último a un entorno de producción.
Los piplines, son el corazón del desarrollo de las peraciones (DevOps) en CI/CD, automatizando cada paso del ciclo de vida del software, desde el desarrollo hasta el despliegue.
Una pipeline de CI/CD típico, independientemente de la herramienta que se utilice suele incluir la siguiente lógica:
Pasos de un Pipeline

1-Checkout: Extracción del código fuente.
2-Test: Ejecución de pruebas unitarias y de integración.
3-Build: Construcción de la aplicación.
4-Deploy: Despliegue a un entorno de pruebas y ensayo.

Una vez desarrollado el paso de construcción (Build) se puede agregar un paso que ejecute los Test de interfaz de usuario UI que se hayan automatizado en la fase de pruebas, y respondan a estrategias de regresión e integración del QA Automation. Esto podría aportar una mayor cobertura al control y automatizar estas pruebas cada vez que hayan versiones nuevas.
Es crucial que la pipeline esté configurada para que los errores de prueba sean tratados como bloqueadores críticos, impidiendo que el código avance a la siguiente etapa si las pruebas fallan. Esta integración garantiza una retroalimentación rápida y confiable sobre el estado del código.
Después del Deploy, la persona en el Rol de QA puede hacer pruebas en este entorno creado.

Las Pruebas en un flujo de CI/CD

Como se mencionaba antes el QA es muy valioso e inherente a la automatización del SDLC, donde las pruebas son prácticas que permiten establecer procedimientos de control en las etapas de desarrollo, integración y entrega. Por ende según el nivel de desarrollo ya sea automatizado o no se incluyen las pruebas, en la presente explicación todas las pruebas se van a considerar como automatizables, las cuales se pueden clasificar de la siguiente manera:

Tipos de Pruebas	Objetivos	Descripción
Pruebas Unitarias	Verifican el comportamiento de pequeñas unidades de código, como métodos y clases	Son rápidas y se suelen ejecutar primero para obtener un conocimiento rápido del estado actual del código
Pruebas de Integración	Verifican que los componentes del software funcionen correctamente cuando se combinan.	Aseguran que la aplicación cumple los requisitos técnicos en un entorno de prueba.
Pruebas Sintéticas	Se ejecutan continuamente en segundo plano para generar tráfico y verificar el buen estado del sistema.
Pruebas de Rendimiento	Simulan la capacidad de producción para determinar si la aplicación cumple con los requisitos de rendimiento.	Apache JMeter es un ejemplo
Pruebas de Interfaz de Usuario (UI) y Aceptación	Verifican que la aplicación cumple con los requisitos de aceptación de los usuarios la funcionalidad a través de la interfaz de usuario.	Simulan interacciones del usuario en navegadores web para probar cómo se comporta la aplicación en condiciones de uso reales. Herramientas como Selenium , Cypress y Playwright son muy utilizadas para la automatización de UI
Pruebas de Regresión	Verifican que las nuevas funcionalidades o cambios no introduzcan errores en el sistema existente ni rompan funcionalidades ya existentes.	Se ejecutan de forma exhaustiva con cada actualización de software.
Pruebas Estáticas de Seguridad de Aplicaciones (SAST)	Analizan el código para detectar vulnerabilidades sin ejecutarlo	Algunos de los Softwares que se utilizan para estas pruebas son: OWASP ZAP
Pruebas Dinámicas de Seguridad de Aplicaciones (DAST)	Identifican vulnerabilidades en un entorno de prueba aprovisionado	También conocidas como pruebas de penetración o pentesting

Como mínimo, una pipeline de CI/CD debería ejecutar pruebas unitarias y pruebas SAST en el código base, así como pruebas de integración y aceptación en un entorno de pruebas.

Herramientas de Software para CI/CD

Existen muchas herramientas de software para automatizar CI/CD, algunas vienen integradas dentro de plataformas como Github , también usada para el SCV, por ejemplo AzureDevOps como parte de los servicios que ofrece la plataforma Azure.
Aprender a utilizar alguna herramienta en particular es una tarea compleja, requiere infraestructura y capacitación adicional. Hay que conocer muy bien las pruebas inherentes al código.
la participación en un flujo de CI/CD es un rol muy importante y requiere vincularse con DevOps directamente, hay quienes han acuñado el término TestOps para identificar a aquellos que se enfocan en el QA dentro de estas operaciones. Aunque como QA si hacemos pruebas automatizadas de UI también se podrían integrar a este flujo de trabajo, además se puede validar la implementació de pruebas en cada etapa.
Las herramientas que se utilicen para automatizar CI/CD cuentan con amplia documentación, guías muy explicativas, es recomendable revisarlas para aprender a utilizarlas, aunque tambiénse utilicen otros medios más visuales, como videos o blogs o cursos.
Hasta el momento mencionaba el término de pipelines, sin embargo, es importante aclarar que según la herramienta que se utilice para automatizar CI/CD, este término, aunque en principio tiene la misma lógica, podría cambiar.
Jenkins, GitLab CI/CD , Bitbucket Pipeline , Azure DevOps ,utilizan pipelines y GitHub utiliza el término Actions
Comparto a continuación algunos detalles identificativos sobre algunas herramientas, que además puedes corroborar, accediendo a la web oficial de cada una.

Jenkins

Es un servicio de servidor de automatización autónomo y de código abierto que se puede utilizar para automatizar todo tipo de tareas relacionadas con la creación, prueba y entrega o implementación de software. Para conocer más sobre Jenkins recomiendo acceder a su web oficial y revisar su documentación: https://www.jenkins.io/doc/.
Para comenzar a usar Jenkins:

1-Instalar Jenkins: Descargar e instalar Jenkins. Este servicio permite crear una virtualización de un entorno de desarrollo completo, se puede hacer en local, en un contenedor o en la nube, en el primer caso es necesario tener instalado Java y contar con capacidad de memoria. En el caso de un contenedor es necesario tener instalado Docker y contar con algunas configuraciones y conocimientos de comandos de Docker. Se trata de un servidor que vas a instalar para realizar las tareas de integración de tu sistema, testearlo y desplegarlo, cada vez que se realiza un cambio en el sistema, Jenkins se encarga de automatizar estos procesos, dichos cambios pudieran ser modificaciones en el código fuente del sistema (como un Pull Request) o en las pruebas, por ejemplo, cambios en las pruebas unitarias, en las de integración, aceptación, las de regresión, en fin a partir del "trigger" que se realice en el Repositorio Control del Código Fuente.

2-Crear un proyecto de Jenkins Pipeline: Esta a su vez la principal funcionalidad de este servidor, se dice proyecto porque se trata de configurar un programa con scripts para ejecutar instrucciones, tal y cómo sería trabajar en un proyecto de desarrollo de software, por ende para trabajar con Jenkins se crea un directorio de trabajo con los archivos del proyecto que se quiere automatizar.
4-Configurar el Pipeline desde la interfaz gráfica: Este archivo también se puede crear de forma manual utilizando la interfaz clásica de Jenkins, o de forma automática usando la herramienta Blue Ocean que es otra interfaz gráfica de Jenkins, la cual es mucho más amigable y visual, más sencilla de usar, ambas interfaces muestran una disposición a modo de Dashboard, ya que quienes hagan sus configuraciones se perciben como administradores del proyecto, por lo que establecen las reglas para las operaciones en general y las pueden personalizar de acuerdo a sus necesidades y modificar.Blue Ocean se basa en la herramienta Pipeline y ofrece funcionalidades adicionales que permiten crear y editar el Pipeline de forma directa, ayuda a configurar el proyecto Pipeline , y crea y escribe automáticamente el Pipeline (es decir, el Jenkinsfile), a través del editor gráfico de Pipeline.
Como parte de la configuración de un proyecto Pipeline en Blue Ocean, Jenkins configura una conexión segura y debidamente autenticada con el repositorio de control de código fuente de su proyecto. Por lo tanto, cualquier cambio que realice a Jenkinsfile a través del editor Pipeline de Blue Ocean se guarda y se envía automáticamente al repositorio de contal control de código fuente.
Se puede configurar el pipeline usando el SCM (SCM = Source Control Management) para que Jenkins se encargue de la integración y despliegue de tu sistema, esto significa: SCM significa Source Control Management, o sea, un sistema como Git (GitHub, GitLab, Bitbucket, etc.).
Cuando decimos "crear el Jenkinsfile desde SCM", no hablamos de escribirlo ahí directamente, sino de: 🔹 Guardar el Jenkinsfile dentro del repositorio de código fuente, y 🔹 Configurar Jenkins para que lo busque ahí automáticamente.
3-Crear un Jenkinsfile: Para configurar un proyecto de Jenkins Pipeline, se deben crear archivos con extensión .groovy, llamados Jenkinsfile, se trata de un tipo de archivo de texto plano que contiene instrucciones para ejecutar tareas de Jenkins, mediante scripts, escritos en lenguaje de programación Groovy, con una sintaxis similar al lenguaje de programación Java. Estos Jenkinsfile se van a agregar al ditrectorio que contienen el repositorio de control del código fuente de un proyecto, el cual define la secuencia de tareas que se van a realizar en el servidor Jenkins para la integración y despliegue de un sistema, cada vez que se realice un cambio en el repositorio, donde se puede ejecutar todo el proceso o una de sus etapas (Stage), como por ejemplo la prueba unitaria, esto lo define la metodología SDLC con que trabaja el equipo de desarrollo.

Nota:En resumen Jenkins permite crear el proyecto pipeline y vincularlo con el Repositorio del Código Fuente, cuyas tareas de SDLC se quieren automatizar, creando el Jenkinsfile de forma manual o automática usando Blue Ocean.

GitHub Actions

Es una funcionalidad que ofrece la plataforma de Github, se trata de una herramienta integrada, que se puede ver en la misma interfaz donde se aloja el Repositorio del Código Fuente.
Se trata de un conjunto de acciones que sería lo mismo que pasos para automatizar, personalizar y ejecuta los flujos de trabajo ó Workflowsde desarrollo de software directamente en el repositorio. Permite descubrir, crear y compartir acciones para realizar cualquier trabajo que quieras, incluido CI/CD, y combinar acciones en un flujo de trabajo completamente personalizado.
Al activar la opción de GitHub Actions en Github, se va crear un Directorio de workflow (.github/workflows) que va a almacenar los archivos, de flujo de trabajo en el Repositorio que se aplique.
Estos archivos utilizan una sintaxis del lenguaje YAML para describir el flujo por lo que aparecen con una extensión .yml o .yaml., este es un lenguaje de serialización de datos, como, un superconjunto estricto de JSON (otro lenguaje), con la adición de características del lenguaje Python, en síntesis YAML, permite definir estructuras de datos complejos en un formato sencillo y legible, digamos que describe objetos o colecciones de objetos, cada objeto va a tener sus propiedades escritas en un par llave-valor ó key-value.

Las plantillas de GitHub Actions facilitan la creación de flujos de forma ágil y ofrecen la alternativa de trabajar desde un archivo de flujo de trabajo en blanco, lo que resulta útil porque parte del trabajo ya se habrá realizado. Estas plantillas contiene flujos de trabajo para varios lenguajes y herramientas. Cuando configuras flujos de trabajo en un repositorio, GitHub analiza el código en el repositorio y recomienda flujos de trabajo en función del lenguaje y el marco del repositorio. Por ejemplo, si usas Node.js, GitHub sugerirá una plantilla de flujo de trabajo que instala los paquetes de Node.js y ejecuta las pruebas. Estas plantillas ofrecen soluciones para automatizar flujos de trabajo, como evaluar las solicitudes de incorporación de cambios y aplicar una etiqueta basada en las rutas modificadas en la solicitud de incorporación de cambios, o bien saludar a los usuarios que colaboran por primera vez en el repositorio.
Las plantillas pueden ser modificadas en función de los accesos y permisos de los colaboradores. Cualquiera con acceso de escritura al repositorio .github de la organización puede configurar una plantilla de flujo de trabajo

Nota: Github Actions ofrece plantillas preconfiguradas que ayudan a crear flujos de trabajo de GitHub Actions propios para un repositorio y permiten personalizar y ejcutar las acciones de control para la integración continua de cambios, a partir de la aplicación de pruebas al código y la aprobación del despliegue de nuevas versiones.

Desafíos para el QA de Software en el flujo de CI/CD

Como se mencionó anteriormente, hay muchos tipos de pruebas que se pueden incorporar en un flujo de CI/CD, además de las relativas al código directamente, como las pruebas de UI que QA automatice (integración, funcionales, regresión), además el QA puede incluso "adueñarse" de partes del flujo de trabajo, generando y manteniendo pipelines y decidiendo qué pruebas se ejecutan, lo que promueve una estrategia "shift left" donde el testing se inicia más temprano en el ciclo de desarrollo para prevenir errores.
El QA puede también garantizar la validación en cada fase del pipeline (Build, Test, Staging, Production).Colabora en el monitoreo continuo para identificar problemas en tiempo real después de los despliegues. Proporciona métricas clave como cobertura de pruebas, tiempos de ejecución y tasas de éxito.
Algunos criterios y desafíos a considerar como un pensamiento estratégico si como QA quieres implicarte en los flujos de CI/CD son:

Desafíos para el QA

Selección de herramientas de Automatización para Test Case de UI, adecuadas que sean compatibles con los sistemas de integración continua, cómo Selenium, Cypress, Playwright .
Mantenimiento constante de los scripts de prueba para adaptarse a los cambios dinámicos del código.
No todas las pruebas pueden automatizarse completamente (ej: usabilidad o pruebas exploratorias)
Necesidad de un proyecto de automatización maduro y eficaz para evitar "flaky tests" (pruebas inestables) que pierdan credibilidad
Asegurar una cobertura de pruebas adecuada y significativa, enfocándose en las pruebas más importantes para la salud de la aplicación
Autonomía de las pruebas, los tests deben ser capaces de inicializarse, ejecutarse, generar reportes y limpiar el ambiente sin intervención humana

AUTOMATIZACIÓN DEL SDLC (CI/CD-SCV)