Guía del participante de la fase de acompañamiento del Proceso de Transición DevSecOps

Información general

Icono guías
Tipo de recurso
Guía
Etiquetas
DevSecOps

Introducción

En el marco de la transición hacia prácticas DevSecOps, este documento presenta una guía detallada para la Fase de Acompañamiento, en la cual se establece un enfoque asistido que contempla hitos intermedios y una coordinación activa entre los equipos involucrados. El objetivo es facilitar la adopción progresiva de estas prácticas mediante una estructura clara de responsabilidades y seguimiento.

Para ello, se incluyen diagramas BPMN que representan los distintos procesos implicados, detallando las acciones específicas a ejecutar y los actores responsables en cada etapa. Estos diagramas permiten visualizar de forma estructurada el flujo de trabajo, facilitando la comprensión y ejecución de las tareas.

La Oficina de Impulso DevSecOps será responsable del seguimiento y la coordinación general de esta fase, mientras que la ejecución de las tareas principales recaerá en los equipos designados (Impulso, Operaciones, Desarrollo). Así mismo, la Oficina de Impulso DevSecOps garantizará el cumplimiento de los hitos mediante un acompañamiento continuo y estructurado.

Fase de acompañamiento

A continuación, se presenta la sección dedicada a la Fase de Acompañamiento, en la que se describen los procesos clave que permitirán avanzar hacia la adopción de prácticas DevSecOps de manera estructurada y colaborativa.

Esta fase contempla un conjunto de acciones organizadas por bloques temáticos, en los que se identifican los equipos responsables y se detallan las tareas a ejecutar. Para facilitar la comprensión de estos procesos, se utilizarán diagramas BPMN, que permitirán visualizar de forma clara y ordenada la secuencia de actividades, los actores involucrados y sus respectivas responsabilidades dentro del marco de implementación.

 

A continuación, se explica cada una de las fases indicadas en el diagrama.

 

01_Lanzamiento de la fase de acompañamiento

En el lanzamiento de la Fase de Acompañamiento:

  • Se dará a conocer el Proceso de Transición DevSecOps
  • Se constituirá el equipo de trabajo que va a colaborar en este proceso
  • Se procederá a dar de alta a los colaboradores en las herramientas de coordinación que se usarán en esta fase para facilitar las labores de gestión y coordinación

A continuación, se presenta el diagrama correspondiente a esta fase.

 

 

En esta fase se mantendrán una serie de reuniones para presentar metodologías y procesos definidos en el proceso de transición a DevSecOps.

  • Presentación KickOff: Será gestionada por el equipo de impulso y servirá como punto de partida del proceso de transición al entorno Pre-Cloud. Durante esta sesión se presentarán las herramientas clave que se utilizarán a lo largo del proyecto, incluyendo el sistema de gestión de tickets TEO, el repositorio de código GitLab y la plataforma de despliegue OpenShift. Además, se presentará el proceso de transición (explicado en apartados posteriores) y se explicarán los equipos involucrados, los flujos de trabajo y la metodología colaborativa que guiará el desarrollo, validación y puesta en producción de los componentes. La duración estimada de la reunión será de 30 a 60 minutos.

  • Presentación del modelo de transición: El equipo de impulso llevará a cabo una sesión dentro del KickOff para presentar el modelo de transición a DevSecOps que se aplicará durante el proceso de transformación tecnológica. Esta estrategia tiene como objetivo principal facilitar la adopción progresiva de la cultura y prácticas DevSecOps por parte de los equipos técnicos vinculados a los sistemas de información. Durante la presentación se abordarán los siguientes aspectos clave:

    • Adopción de competencias DevSecOps: Se explicará cómo los equipos adquirirán conocimientos y hábitos orientados a la integración continua, automatización, seguridad desde el diseño y colaboración entre áreas.
    • Infraestructura de despliegue: Se detallarán los entornos disponibles en la ADA para alojar los sistemas, incluyendo CaaS (Containers as a Service), máquinas virtuales y servidores físicos, según las necesidades de cada componente.
    • Prácticas y herramientas: Se presentarán las herramientas que soportan el modelo (como GitLab, OpenShift y TEO) y las prácticas recomendadas para asegurar calidad, trazabilidad y seguridad en todo el ciclo de vida del software.
    • Experiencia previa: El modelo se basa en la experiencia adquirida durante el pilotaje de la transformación de varios sistemas gestionados por la Dirección General de Estrategia Digital de la Agencia Digital de Andalucía, lo que garantiza su aplicabilidad y madurez.

    La sesión incluirá un resumen visual del proceso para facilitar la comprensión global por parte de los participantes, promoviendo el alineamiento con los objetivos del proyecto y la asunción clara de responsabilidades.

  • Crear proyecto en TEO: La dirección de proyecto del equipo de impulso creará el proyecto del Sistema de Información (SI) en la herramienta TEO. En TEO se gestionan: las peticiones de recursos, las incidencias, la información principal del proyecto, el equipo de trabajo, las visibilidades, la información de los clústeres de despliegue y los componentes desplegados
    • Dar permisos en TEO La dirección de proyecto del equipo de impulso asignará los permisos correspondientes a los integrantes del equipo del Sistema de Información.
    • Actualizar la wiki del proyecto El equipo de impulso actualizará la wiki del proyecto con los datos principales del Sistema de Información y del proyecto.
    • Comprobar acceso Los integrantes del equipo deberán comprobar que tienen acceso correcto a la herramienta.
    • Actualizar el equipo de trabajo El equipo de desarrollo deberá actualizar la tabla del equipo de trabajo del grupo en la wiki del proyecto, indicando: nombre, correo electrónico y usuario LDAP de cada uno de los integrantes del equipo.
  • Presentación del uso de TEO: El equipo de impulso organizará una sesión de presentación sobre el uso de TEO, la herramienta de gestión del proyecto, con una duración estimada de 30 a 60 minutos. En esta reunión se explicarán las secciones clave de TEO, incluyendo la wiki del proyecto, la planificación, las plantillas de solicitudes y las normas de gestión, con el objetivo de asegurar un uso eficiente y alineado de la herramienta por parte de todos los equipos involucrados.

  • Presentación de la estrategia de ramificación: El equipo de impulso convocará una reunión técnica con una duración estimada de 30 a 60 minutos para presentar la estrategia de ramificación utilizada en el proyecto, basada en el modelo ADA Flow. Esta sesión tiene como objetivo explicar cómo se gestionará el ciclo de vida del código fuente en el repositorio GitLab, asegurando una estructura clara y controlada para el desarrollo, integración, validación y despliegue de los distintos componentes. Durante la presentación se abordarán los siguientes puntos:

    • Estructura de ramas: principales, de desarrollo, de integración y de hotfix.
    • Flujo de trabajo entre ramas y su relación con los entornos (desarrollo, preproducción, producción).
    • Normas de uso y buenas prácticas para evitar conflictos y facilitar la trazabilidad.
    • Integración con herramientas como OpenShift y el sistema de gestión de tickets TEO para automatizar despliegues y validaciones.

    Esta estrategia busca garantizar la calidad del código, facilitar la colaboración entre equipos y minimizar riesgos durante el proceso de transición al entorno Pre-Cloud.

  • Presentación del modelo operativo: El equipo de impulso organizará una reunión técnica con una duración estimada de 30 a 60 minutos para presentar el modelo operativo que regirá el proceso de transición al entorno Pre-Cloud. Esta sesión tiene como objetivo definir de forma clara los roles, participantes, funciones y responsabilidades que intervienen en cada fase del proyecto, asegurando una coordinación efectiva entre los distintos equipos. Durante la presentación se abordarán los siguientes puntos:
    • Identificación de los perfiles clave: impulso, desarrollo, operaciones, calidad, arquitectura, seguridad, y gestión de proyecto.
    • Asignación de responsabilidades: quién hace qué, cuándo y cómo, desde la planificación hasta el despliegue y seguimiento.
    • Flujos de trabajo colaborativos: cómo se relacionan los equipos entre sí, qué herramientas se utilizan (TEO, GitLab, OpenShift) y cómo se gestionan las entregas.
    • Normas de operación: buenas prácticas, canales de comunicación, gestión de incidencias y criterios de validación.
    • Presentación del procedimiento del pase a producción, apertura tickets, validación de calidad y operaciones, etc.

  • Sesión del proceso de integración CI/CD: El equipo de impulso convocará una sesión técnica con una duración estimada de 30 a 60 minutos para presentar en detalle el proceso de integración continua y entrega continua (CI/CD) que se aplicará durante la transición al entorno Pre-Cloud. Esta sesión tiene como objetivo proporcionar una visión clara y práctica de los pasos que deben seguirse para garantizar un flujo automatizado, seguro y eficiente desde el desarrollo hasta el despliegue en producción. Durante la sesión se abordarán los siguientes aspectos:

    • Definición del pipeline CI/CD: fases del proceso, desde la compilación del código hasta las pruebas automatizadas, validaciones de calidad y despliegue.
    • Integración con herramientas clave:
      • GitLab como repositorio de código y ejecutor de eventos para el pipelines.
      • OpenShift como plataforma de despliegue.
      • ArgoCD como herramienta de despliegue.
      • Jenkins como herramienta de integración continua.
    • Buenas prácticas DevSecOps: incorporación de validaciones de seguridad, control de versiones, revisión de código y gestión de artefactos.
    • Gestión de errores y stoppers: cómo identificar y resolver bloqueos en el pipeline, y cómo planificar ventanas de despliegue seguras.

    Esta sesión busca asegurar que todos los equipos implicados comprendan el funcionamiento del pipeline CI/CD, sus beneficios y cómo integrarlo correctamente en sus flujos de trabajo diarios.

  • Sesión para la adaptación a despliegues en contenedores: El equipo de operaciones presentará/organizará una sesión técnica con una duración estimada de 30 a 60 minutos para presentar la configuración estándar que debe tener el fichero Dockerfile, utilizado para construir las imágenes de los componentes que serán desplegados en el entorno Pre-Cloud. Y, además, presentará los manifiestos de despliegue que puede tener un componente. Esta sesión tiene como objetivo asegurar que todos los equipos de desarrollo comprendan cómo estructurar correctamente sus contenedores, siguiendo las buenas prácticas definidas por la Agencia Digital de Andalucía. Durante la sesión se abordarán los siguientes puntos:

    • Estructura básica del Dockerfile: instrucciones esenciales como FROM, COPY, RUN, CMD, EXPOSE, entre otras.
    • Buenas prácticas de construcción: optimización de capas, uso de imágenes base seguras, minimización de tamaño y gestión de dependencias.
    • Configuraciones específicas para OpenShift: requisitos de seguridad, usuario no root, variables de entorno, y compatibilidad con el pipeline CI/CD.
    • Definición de ficheros de despliegue y Kustomize.

    Esta sesión es clave para garantizar que las imágenes generadas sean consistentes, seguras y compatibles con el modelo operativo y de despliegue definido para el entorno Pre-Cloud.

  • Presentación del despliegue de BBDD: El equipo de impulso presentará como la plataforma de CI/CD llevará a cabo una sesión técnica con una duración estimada de 30 a 60 minutos para explicar cómo se gestiona el lanzamiento de scripts de bases de datos, a través del proceso CI/CD del entorno PreCloud, utilizando la herramienta Liquibase. Esta sesión tiene como objetivo explicar cómo se automatiza la gestión de cambios en bases de datos de forma segura, trazable y alineada con las prácticas DevSecOps. Durante la sesión se abordarán los siguientes puntos:

    • Introducción a Liquibase: qué es, cómo funciona y por qué se ha elegido como herramienta estándar para la gestión de cambios en BBDD.
    • Integración con el pipeline CI/CD: cómo se incorporan los scripts de Liquibase en el flujo de despliegue automatizado gestionado desde GitLab y ejecutado en OpenShift.
    • Buenas prácticas: cómo estructurar los scripts, evitar conflictos, asegurar la consistencia entre entornos y validar los cambios antes de su ejecución.
    • Casos prácticos: ejemplos de despliegue de cambios reales en bases de datos, desde el desarrollo hasta producción.

    Esta sesión permitirá a los equipos técnicos comprender cómo gestionar de forma eficiente y segura los cambios en las bases de datos, integrándolos en el ciclo de vida del software y asegurando trazabilidad y control en cada paso.

  • Presentación de la automatización de pruebas en plataforma CI/CD: El equipo de impulso organizará una sesión técnica con una duración estimada de 30 a 60 minutos para presentar la herramienta y el enfoque utilizado para la automatización de pruebas dentro del pipeline CI/CD en el entorno Pre-Cloud. Esta sesión tiene como objetivo mostrar cómo se integran las pruebas en el flujo de desarrollo y despliegue, garantizando calidad, seguridad y trazabilidad desde las primeras fases del ciclo de vida del software. Durante la sesión se abordarán los siguientes puntos:

    • Tipos de pruebas automatizadas: unitarias, de integración, funcionales, de seguridad y de rendimiento.
    • Integración en el pipeline CI/CD: cómo se ejecutan automáticamente en cada fase del proceso, desde el commit hasta el despliegue en OpenShift.
    • Herramienta utilizada: se presentará la solución adoptada.
    • Gestión de resultados: cómo se reportan los errores, cómo se visualizan los logs y cómo se gestionan los stoppers en caso de fallos.
    • Buenas prácticas: diseño de pruebas reutilizables, cobertura mínima recomendada, y mantenimiento de los scripts.

    Esta sesión busca capacitar a los equipos técnicos para que integren las pruebas automatizadas como parte natural de su flujo de trabajo, contribuyendo a la mejora continua y a la estabilidad de los sistemas desplegados en el entorno Pre-Cloud.

  • Presentación de Observabilidad en plataforma CI/CD: El equipo de operaciones llevará a cabo una sesión técnica con una duración estimada de 30 a 60 minutos para presentar la solución de observabilidad que se implementará en el entorno Pre-Cloud. Esta sesión tiene como objetivo mostrar cómo se monitorizan, analizan y gestionan los sistemas desplegados, garantizando visibilidad completa sobre el rendimiento, la disponibilidad y el comportamiento de los servicios. Durante la sesión se abordarán los siguientes aspectos:

    • Concepto de observabilidad: definición, importancia en entornos DevSecOps y diferencia con la simple monitorización.
    • Herramientas disponibles: se presentarán las soluciones integradas en la plataforma, como:
      • Prometheus para métricas.
      • Grafana para visualización.
      • Kibana para gestión de logs.
    • Integración con OpenShift y CI/CD: cómo se conectan estas herramientas con los despliegues automatizados y los pipelines para detectar errores, cuellos de botella o anomalías en tiempo real.
    • Alertas y dashboards: configuración de paneles personalizados y sistemas de notificación para facilitar la respuesta rápida ante incidencias.

    Esta sesión permitirá a los equipos técnicos comprender cómo utilizar la observabilidad como una herramienta clave para la mejora continua, la resolución proactiva de problemas y el cumplimiento de los objetivos operativos del proyecto.

  • Crear canal de Teams: El equipo de impulso creará el canal de teams del equipo que trabajará en el desarrollo y puesta en producción del sistema, con objeto de que sea el canal de comunicación para el trabajo conjunto.
    • Dar permisos en Teams: El equipo de impulso asignará permisos sobre el proyecto a los integrantes del equipo, de operaciones y de impulso
    • Comprobar acceso: Los integrantes de equipo de desarrollo, operaciones y de impulso deben comprobar el acceso al canal de Teams.

  • Realizar autoregistro en el repositorio de código corporativo: Como parte del proceso de incorporación al entorno de trabajo, los integrantes del equipo de desarrollo deberán realizar el autoregistro en la plataforma GitLab, que será utilizada como repositorio de código fuente durante todo el proyecto. Este paso es obligatorio para poder acceder por primera vez (confirmando los repositorios, pipelines y herramientas integradas). El proceso consiste en:

    • Acceder a la URL del repositorio de código corporativo proporcionada por el equipo de impulso.
    • Completar el formulario de registro con los datos personales y profesionales requeridos.
    • Confirmar el correo electrónico recibido tras el registro para activar la cuenta. Una vez activada, el usuario podrá ser asignado a los grupos y proyectos correspondientes, según su rol en el equipo.

    Este procedimiento garantiza la trazabilidad de las acciones realizadas en el repositorio, facilita la colaboración entre equipos y permite aplicar políticas de seguridad y control de acceso de forma centralizada.

    • Solicitar el grupo raíz en Gitlab: El equipo de desarrollo debe solicitar la creación del grupo raíz. Se puede solicitar de dos formas:
      • 1. Mediante el proceso oficial para la solicitud de grupos raíz en GitLab (NAOS). Orientado a sistemas que no están dentro del proceso de transición a DevSecOps o sistemas que aún estando dentro del proceso no tienen todavía definido el nombre del sistema de información.
      • 2. A través de Teams, TEO, o en una de las sesiones de transferencia. Por agilizar el proceso, los sistemas dentro del proceso de transición pueden solicitar la creación del grupo raíz a través de los medios comentados, indicando siempre el nombre del grupo (siguiendo siempre la nomenclatura) y el owner.
    • Crear el grupo: La Oficina de Impulso DevSecOps creará el grupo raíz en Gitlab de acuerdo a la solicitud presentada.
    • Asignar Owner: La Oficina de Impulso DevSecOps debe asignar el owner al grupo raíz.
    • Gestión del grupo de GitLab: El owner del grupo debe asignar usuarios, roles y permisos al grupo.
    • Crear proyectos: Los owners o mantainers del grupo crearán los proyectos/subgrupos necesarios del SI en el repositorio de Gitlab. Estos deben cumplir con las Normas de gestión de código en la Plataforma Pre-Cloud

 

02_Migración / aprovisionamiento en CPD destino

En esta fase se describirán los pasos necesarios para aprovisionar los entornos necesarios en los que trabajará en el proyecto, y todos los recursos necesarios para que funcione correctamente, como visibilidades, o BBDD, etc.

En la siguiente imagen se puede observar el diagrama del proceso general.

 

 

  • Solicitud de entorno no productivo: Debe crearse una subtarea en la tarea padre "Aprovisionamiento de entornos" en la cual se solicitará el entorno a crear (Test, Pre). En el siguiente enlace, se encuentra la plantilla de “Solicitud de aprovisionamiento de entornos” así como un ejemplo con datos para solicitar el entorno. Se debe copiar la plantilla y el ejemplo y modificar los campos indicados. Ante cualquier duda de como rellenar la plantilla, no dudar en comunicaros con Impulso DevSecOps, a través de cualquier medio de contacto.
    • Creación de entorno: El equipo de operaciones, cuando les llegue la petición, solicitarán a ISCP la creación del entorno y grupo, siguiendo la nomenclatura (test-si-sistema o pre-sistema). Una vez creado, deberán asegurar que el secreto de Quay está correctamente creado en el entorno, así como los grupos del equipo de desarrollo y de Impulso DevSecOps. Si todo está correcto se reasignará el ticket a la persona que lo solicitó. También tendrán que configurar el namespace en el ServiceAccount de ArgoCD (test y pre).
    • Comprobar el acceso al entorno creado: El equipo de desarrollo una vez recibida la confirmación de la creación, comprobará si todos sus miembros tienen acceso al namespace creado y continuará con el proceso. En caso contrario deberán devolver el ticket a Operaciones indicando el problema.
  • Identificar visibilidades: El equipo de desarrollo deberá asignarse la tarea "Identificar Visibilidades con terceros", ponerla en curso y rellenar la tabla de visibilidades de la wiki, para todos los entornos.
    • Solicitud de visibilidades: una vez completada la tarea "Identificar Visibilidades con terceros", el equipo de desarrollo creará una subtarea por entorno en "Asegurar visibilidades" para solicitar las visibilidades. Importante se creará una tarea por entorno. Se debe asignar al equipo de Operaciones.
    • Habilitar las visibilidades: El equipo de Operaciones solicitará la habilitación de visibilidades a los equipos que correspondan.
    • Solicitud de creación/migración de la BBDD: Si el sistema requiere de migración de la Base de Datos o creación ya sea en el namespace (Impulso no recomienda está opción por problemas de rendimiento) o fuera de namespace, tendrá que abrir una solicitud al grupo de operaciones encargado de administrar la máquina donde se alojará la BD.
      • Crear/migrar BBDD: El equipo de operaciones creará o migrará la BD. Una vez creada o migrada, importará los datos de conexión con la BD.
    • Comprobar que las visibilidades están habilitadas: Una vez resueltas las visibilidades, el equipo de operaciones comprobará si existe conectividad desde el namespace a las visibilidades indicadas.
  • Solicitar migración/visibilidad (repositorio artefactos) de dependencias del SSII: Si el sistema necesita que se migren unas dependencias que no están en el repositorio de artefactos, o necesita visibilidad de su repositorio de artefactos, debe solicitarlos a Impulso vía NAOS. Enlace al portal de desarrollo con los pasos para solicitarlo.
    • Inclusión de (repositorio artefactos) de dependencias/visibilidad del SSII: El equipo de Impulso DevSecOps añadirá las dependencias solicitadas, e informará en el ticket NAOS al equipo de que se han añadido las dependencias. En caso de que se solicite la visibilidad de un repositorio de artefactos, se añadiría o bien en Artifactory o bien en Jenkins tras un estudio previo.

 

03_Incorporación a la plataforma CI

En la siguiente sección se aborda la Fase de Integración en la Plataforma CI en la cual se detallan los procesos necesarios para habilitar la ejecución automatizada de tareas de construcción, empaquetado y despliegue de los componentes. Esta fase implica la configuración técnica de los repositorios de código y la adaptación de los mismos por parte del Equipo de Desarrollo, en función de los requerimientos del motor de CI/CD y del stack tecnológico utilizado. Asimismo, se contempla la migración de las dependencias de cada componente al repositorio de artefactos correspondiente, asegurando la trazabilidad y consistencia del entorno de integración.

En la siguiente imagen se puede ver el proceso de incorporación a nivel general.

 

 

  • Solicitud de creación de jobs en Jenkins: El equipo de desarrollo solicitará a Impulso DevSecOps la creación de los jobs Jenkins que necesiten. Esto se realizará mediante una solicitud en TEO. El equipo de desarrollo rellenará la tabla de jobs, con las URLs e ids de los proyectos en Gitlab. Después abrirá una petición en TEO a Impulso, para solicitar los jobs de Jenkins.
    • Creación de jobs en Jenkins: Impulso creará los jobs solicitados y copiará el token y la URL del webhook de los jobs para facilitárselo al equipo de desarrollo. Luego en la página de jobs marcará los jobs como creados en su columna correspondiente.
    • Configuración del Webhook en los repositorios: El equipo de desarrollo creará en cada repositorio de GitLab el webhook correspondiente, con su URL y token, según se indicó en la sesión y documentación correspondientes.
      • Configuración del fichero sonar.properties: El equipo de desarrollo deberá configurar el fichero sonar.properties en cada repositorio. Este deberá contener toda la configuración para la ejecución del análisis estático de Sonar.
      • Configuración del fichero Dockerfile: El equipo de desarrollo deberá configurar el fichero el fichero Dockerfile en cada repositorio de un componente desplegable (no librerías). Importante: No está permitido la compilación en estos ficheros salvo para el stack “minimal”.
      • Configuración de la carpeta de despliegue: El equipo de desarrollo creará y configurará por cada repositorio la carpeta de despliegue con los manifiestos para cada entorno de un componente desplegable (no librerías). (Pendiente de guía o sesión).
      • Configuración del fichero ci.json (manifiesto.json para minimal):El equipo de desarrollo creará y configurará por cada repositorio el fichero ci.json con la información del stack tecnológico, correspondiente. En caso de que el stack sea “minimal” deberá crear el fichero manifiesto.json. Todo esto se habrá explicado en la sesión y documentado correspondiente.
        • Ejecutar job configurado: Una vez configurado todos los ficheros, el equipo de desarrollo se encargará de verificar que se lance correctamente el job.
        • Verificar y corregir errores de la configuración: Si se dan fallos en el lanzamiento del job, se debe revisar su configuración, ya que no se debería desplegar un componente software que no cumpla con las pruebas y análisis realizados. El Control de stoppers se definió para estos casos.

 

04_Automatización de pruebas

La automatización de pruebas es un componente esencial dentro del modelo DevSecOps y del pipeline CI/CD en el entorno Pre-Cloud. Esta práctica permite validar de forma continua la calidad, funcionalidad y seguridad de los desarrollos, y acelerando los ciclos de entrega. En esta sección se describe cómo se integran las pruebas automatizadas en el flujo de trabajo, qué tipos de pruebas se contemplan, qué herramientas se utilizan y cómo se gestionan los resultados para garantizar un despliegue fiable y controlado.

A continuación, se presenta el diagrama correspondiente a esta fase.

 

 

  • Planificar automatización de pruebas: La planificación de la automatización de pruebas tiene como objetivo definir una estrategia clara y estructurada para validar la calidad del software desarrollado en los stacks tecnológicos Maven (Java) y Node.js (JavaScript/TypeScript). Esta tarea contempla la integración de distintos tipos de pruebas en el pipeline CI/CD, asegurando que cada componente sea evaluado de forma continua, automatizada y trazable. La planificación debe considerar herramientas compatibles con cada stack, buenas prácticas de desarrollo y criterios de cobertura que garanticen la fiabilidad del sistema antes de su despliegue en entornos como OpenShift. Se tendrán en cuenta los siguientes tipos de pruebas:
    • Pruebas Funcionales: Estas pruebas se centran en validar que cada funcionalidad del sistema cumple con los requisitos definidos, sin importar cómo esté implementada. Se basan en casos de uso concretos y verifican que el sistema responda correctamente ante determinadas acciones, como mostrar un mensaje de error al introducir datos inválidos o permitir la edición de un perfil de usuario.
  • Lanzar plan de pruebas funcionales: se ejecutarán las pruebas correspondientes a través de la plataforma CI/CD durante el proceso de despliegue.
    • Corregir errores en pruebas funcionales: Si durante la ejecución se producen fallos, el equipo de desarrollo deberá realizar los cambios pertinentes en las pruebas para que se ejecuten correctamente.
  • Ejecución automática del plan de pruebas funcionales: Se ejecutan las pruebas funcionales automáticamente desde la plataforma del CI/CD.

 

05_Despliegue en entornos no productivos (TEST)

En esta sección se describen los pasos necesarios para realizar el despliegue en el entorno de TEST, como parte del flujo de integración continua dentro de la Plataforma CI/CD.

 

 

  • Configurar manifiestos de despliegue para Test: El equipo de desarrollo deberá configurar los manifiestos de despliegue que el componente necesite para Test.
    • Creación de las aplicaciones de ArgoCD en Test: Una vez configurados los manifiestos para el entorno de Test, se crearán las aplicaciones en ArgoCD.
      • Crear solicitud de despliegue en Test: Para el despliegue en test se debe crear una solicitud de acuerdo con lo indicado en la estrategia de ramificación.
      • Aceptar la solicitud de despliegue y desplegar en Test: Si todo está correcto se aceptará la solicitud de despliegue en Test y se realizará el despliegue en el entorno de Test.
      • Pruebas en Test: Una vez realizado el despliegue del componente en Test el equipo de desarrollo realizará las pruebas pertinentes, para comprobar que el componente está bien desplegado.
      • Validación del entorno: Una vez desplegados todos los componentes, el equipo de desarrollo realizará una serie de pruebas de validación para asegurar que el funcionamiento del sistema es correcto y se puede realizar el despliegue en PRE.

 

06_Despliegue en entornos no productivos (PRE)

En esta sección se describen los pasos necesarios para realizar el despliegue en el entorno de PRE, como parte del flujo de integración continua dentro de la Plataforma CI/CD.

 

 

  • Configurar manifiestos de despliegue para Pre: El equipo de desarrollo deberá configurar los manifiestos de despliegue que el componente necesite.
    • Creación de las aplicaciones de ArgoCD en Pre: Una vez configurados los manifiestos para el entorno de Pre, se crearán las aplicaciones en ArgoCd.
      • Crear solicitud de despliegue en PRE: Para el despliegue en test se debe crear una solicitud de acuerdo con lo indicado en la estrategia de ramificación
      • Aceptar la solicitud de despliegue y desplegar en PRE: Si todo está correcto se aceptará la solicitud de despliegue en PRE y se realizará el despliegue en el entorno de PRE.
      • Pruebas en PRE: Una vez realizado el despliegue del componente en Pre el equipo de desarrollo realizará las pruebas pertinentes, para comprobar que el componente está bien desplegado.
      • Validación del entorno: Una vez desplegados todos los componentes, el equipo de desarrollo realizará una serie de pruebas de validación para asegurar que el funcionamiento del sistema es correcto y se puede realizar el despliegue en PRE.
      • Solicitud de pruebas de carga: El equipo de desarrollo creará una solicitud dirigida al equipo de Calidad para la ejecución de pruebas de carga.
        • Realizar pruebas funcionales, de seguridad y de carga: Recibida la solicitud el equipo de Calidad, realizará las pruebas respectivas a los distintos componentes del Sistema de información que se desean desplegar.
        • Entregar informe: el equipo de calidad entregará el informe de los resultados de las pruebas de carga al Sistema de información donde se comunicará si es apto o no para el despliegue en PRO de los componentes evaluados.
        • Cambios por fallos en pruebas de carga: Corregir los errores ocasionados durante las pruebas de carga y volver a lanzarlas.

 

07_Aprovisionamiento de entorno producción (PRO)

En esta sección se describen los pasos necesarios para solicitar el aprovisionamiento del entorno de PRO, como parte del flujo de integración continua dentro de la Plataforma CI/CD.

 

 

  • Solicitud de entorno productivo: Debe crearse una subtarea en la tarea padre "Aprovisionamiento de entornos" en la cual se solicitará el entorno de pro. En el siguiente enlace se encuentra la plantilla de “Solicitud de aprovisionamiento de entornos” así como un ejemplo con datos para solicitar el entorno. Se debe copiar la plantilla y el ejemplo y modificar los campos indicados. Ante cualquier duda de como rellenar la plantilla no dudar en comunicaros con Impulso DevSecOps, a través de cualquier medio de contacto.
    • Creación de entorno productivo: El equipo de operaciones cuando les llegue la petición, solicitarán a ISCP la creación del entorno, siguiendo la nomenclatura (si-sistema) y grupo. Una vez creado, deberán asegurar que el secreto de Quay está correctamente creado en el entorno de pro, así como el grupo del equipo de desarrollo. Si todo está correcto se reasignará el ticket a la persona que lo solicitó. También tendrán que configurar el namespace en el ServiceAccount de ArgoCD de pro.
    • Comprobar el acceso al entorno creado: El equipo de desarrollo una vez recibida la confirmación de la creación, comprobará si todos sus miembros tienen acceso al namespace creado y continuará con el proceso. En caso contrario deberán devolver el ticket a Operaciones indicando el problema.
    • Solicitud de creación/migración de la BBDD: Si el sistema requiere de migración de la Base de Datos o creación en el namespace (Impulso no Recomienda está opción por problemas de rendimiento), tendrá que abrir una solicitud al grupo de operaciones encargado de la administrar la máquina donde se alojará la BD.
      • Crear/migrar BBDD: El equipo de operaciones creará o migrará la BD. Una vez creada o migrada, importará los datos de conexión con la BD.
      • Identificar visibilidades: El equipo de desarrollo deberá asignarse la tarea "Identificar Visibilidades con terceros", ponerla en curso y rellenar la tabla de visibilidades de la wiki, para todos los entornos.
      • Solicitud de visibilidades: una vez completada la tarea "Identificar Visibilidades con terceros", el equipo de desarrollo creará una subtarea por entorno en "Asegurar visibilidades" para solicitar las visibilidades. Importante se creará una tarea por entorno. Se debe asignar al equipo de Operaciones
      • Habilitar las visibilidades: El equipo de Operaciones solicitará la habilitación de visibilidades a los equipos que correspondan.
      • Comprobar que las visibilidades están habilitadas: Una vez resueltas las visibilidades, el equipo de operaciones comprobará si existe conectividad desde el namespace a las visibilidades indicadas.

 

08_Despliegue en entornos productivos (PRO)

En esta sección se describen los pasos necesarios para realizar el despliegue en el entorno de PRO, como parte del flujo de integración continua dentro de la Plataforma CI/CD.

 

 

  • Rellenar el checklist: Validado el entorno, el equipo de desarrollo rellenará el checklist solicitado por el equipo de operaciones para el paso a producción, donde se indicarán datos como componentes a desplegar y recursos necesarios para ello. - Aprobar el checklist: El equipo de operaciones aprobará el checklist si los datos se encuentran correctos.
  • Configurar manifiestos de despliegue para PRO: El equipo de desarrollo deberá configurar los manifiestos de despliegue que el componente necesite.
    • Creación de las aplicaciones de ArgoCD en PRO: Una vez configurados los manifiestos para el entorno de Pro, se crearán las aplicaciones en ArgoCD.
      • Crear solicitud de despliegue en PRO: Para el despliegue en test se debe crear una solicitud de acuerdo con lo indicado en la estrategia de ramificación.
      • Aceptar la solicitud de despliegue y desplegar en PRO: Si todo está correcto se aceptará la solicitud de despliegue en PRO y se realizará el despliegue en el entorno de PRO.
      • Pruebas en PRO: Una vez realizado el despliegue del componente en Pro el equipo de desarrollo realizará las pruebas pertinentes, para comprobar que el componente está bien desplegado.
      • Validación del entorno: Una vez desplegados todos los componentes, el equipo de desarrollo realizará una serie de pruebas de validación para asegurar que el funcionamiento del sistema es correcto y se puede realizar el despliegue en PRO.