Contenido
En los siguientes apartados se realiza una especificación conceptual del pipeline que se implementará en la Plataforma CI/CD. Se realiza una evaluación de su diseño y funcionalidad desde una perspectiva más amplia, identificando posibles áreas de mejora y optimización:
- Analizar la estructura del pipeline y su flujo de trabajo.
- Evaluar la eficiencia y la velocidad de ejecución del pipeline.
- Identificar cualquier redundancia o procesos innecesarios en el pipeline.
- Revisar la gestión de errores y la tolerancia a fallos en el pipeline.
- Evaluar la escalabilidad del pipeline para futuras necesidades.
¿Cómo funciona un Pipeline de Integración Continua (CI)?
En lineas generales, un pipeline de integración continua funciona de la siguiente forma:
- Disparador del evento: Normalmente, se suele escuchar un evento que proviene del repositorio de código (aunque pueden ser otros eventos los que lance el pipeline, como una tarea programada o la creación de un determinado ticket en un sistema). Cuando se realiza una modificación en el repositorio de código, como una confirmación (push event), se desencadena un evento (vía webhook) que alerta al motor de integración continua.
- Configuración/Autoconfiguración: Es probable que se tenga que suministrar determinada configuración al pipeline para que este se ejecute correctamente o bien, el propio pipeline pueda realizar dicha configuración a partir de la información suministrada por el evento, por datos existentes en el propio repositorio, etc.
- Obtención del código fuente: El motor de CI clona o descarga la última versión del código del repositorio central, o mejor dicho, descarga la versión correspondiente donde se ha producido el evento.
- Construcción y Pruebas: Se ejecutan una serie de pasos que pueden incluir la compilación del código, la ejecución de pruebas unitarias, pruebas de integración y otras verificaciones de calidad del código, en la que se pueden utilizar múltiples herramientas.
- Despliegue: Si las pruebas pasan con éxito, el motor de CI puede implementar automáticamente la nueva versión del software en un entorno de desarrollo, pruebas o producción, según la configuración específica del pipeline. Idealmente, las fases de despliegue deberían estar desacopladas del proceso de CI. CI termina desencadenando el evento que provoque el proceso de entrega continua/despliegue continuo.
- Notificación y Registro de Resultados: El motor de CI notifica a los miembros del equipo sobre los resultados de la construcción y las pruebas. También registra los resultados y se publica en un dashboard, lo que facilita el seguimiento y las tareas de auditoría.
Normalmente, estas acciones se agrupan en fases que ejecutan acciones concretas. Dependiendo de la la solución de integración continua que se elija, se llamará de distinta forma (fases, tareas, acciones, etc), pero viene a significar lo mismo (el conjunto de acciones acotadas que tienen un resultado concreto).
Beneficios de un Pipeline de Integración Continua
- Feedback rápido: Detecta y soluciona problemas de código en fases iniciales (si incorporamos desde un inicio su uso), lo que mejora la calidad del software. Esto es lo que se suele denominar como “shift-left” (estrategia que implica realizar actividades o pruebas más temprano en el ciclo de desarrollo de software).
- Automatización: Automatiza tareas repetitivas, lo que ahorra tiempo y reduce los errores inherentes a las ejecuciones manuales.
- Mayor calidad: Se implementan pruebas, a distintos niveles (unitarias, de integración, funcionales, etc), así como otras pruebas relacionadas con el estado y calidad del código (como el análisis estático de código), en fases tempranas, lo que permite ir corrigiendo las no conformidades y mejorar la calidad.
- Mayor seguridad: Se implementan revisiones de seguridad tempranas en el proceso de desarrollo para identificar y mitigar posibles vulnerabilidades de seguridad antes de que el software se despliegue en producción.
- Visibilidad y Control: Proporciona una visión clara del estado del proyecto y facilita el gobierno del mismo.
Fases de un Pipeline de Integración Continua
A continuación se desarrollan las fases (o tareas), que debe formar el pipeline, sin entrar en detalles técnicos de implementación.
Fase de inicialización
Objetivo
- Esta fase se utilizará para inicializar el lanzamiento del pipeline. Se realizarán todas las tareas previas necesarias, como por ejemplo, limpieza del workspace si correspondiese o cualquier otra acción que se considere necesaria antes de realizar la ejecución del pipeline.
Valor obtenido
- Entorno de ejecución del pipeline listo para ejecutar.
Dependencias
- Evento disparador: Se necesita conocer el evento que disparará el pipeline.
- Flujo de trabajo: También es necesario saber el flujo que se adoptará en el pipeline para poder disparar correctamente el pipeline.
Fase de configuración / autoconfiguración
Objetivo
- Obtener la configuración necesaria para que el pipeline pueda ejecutarse correctamente. Esta fase podría dividirse en otras o tener varias pasos o etapas , por ejemplo, la obtención de la configuración por un lado, y el proceso de autoconfiguración por otro. Dependiendo de donde resida la configuración, es posible que está fase sea sustituida o completada por otra que se ejecute tras la obtención del código fuente.
Valor obtenido
- Pipeline configurado y adaptado para ejecutar correctamente contra un componente especifico.
Dependencias
- Servidor de configuración: Si la configuración no se va a aportar desde el propio repositorio, es necesario disponer de un servidor donde resida la configuración.
Fase de obtención de código fuente
Objetivo
- Realizar la descarga del código fuente desde el repositorio de código fuente para poder ejecutar el pipeline sobre él. Idealmente, la información del repositorio no debería residir en el código del propio pipeline, sino que o bien es informada vía integración con el repositorio de código fuente (si lo permite la herramienta) o bien es obtenida previamente en la fase de configuración. Si es informada por el repositorio, también se podría utilizar esta fase para mapear todos los valores necesarios que se obtenga del repositorio (url del repositorio, proyecto, rama sobre la que se realiza el cambio, persona que realiza el cambio,etc) y ponerlo en el contexto de ejecución del pipeline para que pueda ser reutilizado en fases posteriores.
Valor obtenido
- Código fuente sobre el que ejecutar el proceso de CI
- Mapeo de valores del repositorio en contexto de ejecución del motor de CI
Dependencias
- Si el evento que dispara el pipeline no es un webhook que proporcione información sobre el repositorio → Fase de configuración / autoconfiguración
Fase obtención información producto (identificación)
Objetivo
- Identificar correctamente el producto para poder ejecutar correctamente el pipeline. Por ejemplo, si es una aplicación maven, conocer las coordenadas que lo conforman y poner en el contexto de ejecución del pipeline dichos valores, ya que pueden ser de utilidad en futuras fases o incluso la propia identificación de la pila tecnológica. Esta fase puede completar las tareas necesarias de la fase de de configuración o llegar a sustituirla por completo si la configuración se va a obtener desde el propio repositorio.
Valor obtenido
- Producto correctamente identificado.
- Mapeo de valores en contexto de ejecución del motor de CI.
Dependencias
- Fase de obtención de código fuente
Fase construcción / empaquetado
Objetivo
- Realizar el proceso de construcción de software, con las herramientas necesarias, según la pila tecnológica que aplica al tipo de producto que se quiera construir / empaquetar. Según la pila tecnológica, es posible que está fase tenga diferentes implementaciones.
- Según pila tecnológica, es posible que también se vea conveniente realizar la subida al repositorio de artefactos en esta fase, ya que hacerlo en fases posteriores, según las herramientas que se utilicen, puede implicar volver a lanzar el mismo proceso de construcción.
Valor obtenido
- Software construido / empaquetado
- Artefacto en repositorio de artefactos.
Dependencias
- Fase de obtención de código fuente
Fase pruebas y evaluación de código
Objetivo
- Realizar distintas pruebas sobre el código para evaluar la calidad del mismo. Esta fase, puede ser realmente una metafase que englobe otras fases o tareas a realizar, que tienen sentido y entidad por si mismas. Las pruebas más habituales que se suelen realizar sobre el código son:
- Pruebas unitarias: son evaluaciones individuales del código para garantizar que funcionen como se espera y no tengan errores. Se centran en validar el comportamiento de una parte aislada de la aplicación, por lo general, una función o método.
- Pruebas de integración: se centra en verificar la interacción y comunicación entre diferentes módulos o componentes del software para asegurarse de que funcionan de manera conjunta y se integran correctamente.
- Análisis estático de código: es un proceso automatizado que examina el código fuente en busca de posibles errores, malas prácticas y vulnerabilidades sin llegar a ejecutar la aplicación.
- Análisis de dependencias: es un proceso automatizado para analizar las dependencias utilizadas en un proyecto y así evaluar los posibles riesgos asociadas a las mismas.
- Otras verificaciones: cualquier otra verificación que se quiera automatizar en el proceso.
Valor obtenido
- Pruebas realizadas sobre el código que ayudan a determinar la calidad
- Obtención de los posibles stoppers para parar el proceso de CI.
Dependencias
- Fase de obtención de código fuente
Fase subida artefacto generado al repositorio de artefactos
Objetivo
- Realizar la subida del artefacto generado al repositorio de artefactos de la organización para que sea fácilmente distribuible. Dependiendo de la pila tecnológica, es posible que esta fase se quiera implementar en la fase de construcción/empaquetado para no tener que repetir el proceso de construcción nuevamente.
Valor obtenido
- Artefacto construido disponible en repositorio de artefactos de la organización, correctamente etiquetado y listo para su distribución.
Dependencias
- Fase construcción / empaquetado
- Fase pruebas y evaluación de código (si se quiere evitar que se suban artefactos que no pasa alguna de las pruebas)
Fase de generación de imagen
Objetivo
- Cuando aplique el despliegue en contenedores, en esta fase se generará la imagen correspondiente y se etiquetará en el registro de imágenes.
Valor obtenido
- Nueva imagen etiquetada en repositorio de imágenes lista para ser desplegada.
Dependencias
- Fase construcción / empaquetado
Fase disparo de despliegue
Objetivo
- Idealmente, el pipeline de integración continua no debería realizar tareas relacionadas con el despliegue. Estas tareas (la de despliegue), deberían ser realizadas por otras herramientas especializadas, pero el pipeline de CI debe finalizar con una acción que desencadene el despliegue, por ejemplo, la modificación del manifiesto de kubernetes donde se describe el objeto Deployment para indicar la nueva imagen a utilizar y posterior confirmación en el repositorio (siempre que estemos utilizando una herramienta de CD que esté monitorizando los cambios sobre el repositorio)
Valor obtenido
- Generación del evento que provocará el funcionamiento de los mecanismos que culminarán con el despliegue de una nueva versión.
Dependencias
- Fase de generación de imagen
Índice