Acerca de nuestro producto y nuestro modelo de entrega
Descripción general del producto/proyecto
freya fusion una plataforma tecnológica regulatoria avanzada que aprovecha la inteligencia artificial y cloud-based para optimizar los procesos de cumplimiento normativo. Entre sus características principales se incluyen una«Regulatory Cloud» basada en la inteligencia artificialpara una supervisión inteligente,la capacidad de combinardatos, contenidos, aplicaciones e interfaces de usuario para mayor flexibilidad, yprocesos regulatorios alineadoscon una planificación multifuncional. La plataforma también ofrecesoluciones de automatización integradas, ungráfico de conocimientopara obtener información estructurada y unainterfaz de usuario conversacionalpara mejorar la interacción con el usuario. Diseñada para la eficiencia, Freya Fusion tecnología de vanguardia con experiencia en materia de regulación para simplificar los complejos flujos de trabajo de cumplimiento normativo.
Proceso actual y ecosistema de entrega
Metodología ágil y herramientas
En freya fusion, aplicamos la metodología ágil integrada con prácticas de DevSecOpspara garantizarla seguridad, el cumplimiento normativo y la eficiencia,desde el código hasta la implementación. En nuestro marco ágil,las funcionalidades constituyen los elementos de trabajo principales de cada lanzamiento. Se agrupan y validan varias funcionalidades a la vez para formar unaversión candidata (RC), lo que garantiza una entrega de valor incremental y controlada.
Azure DevOps (ADO) e integraciones de complementos
Descripción general del proceso de CI/CD
Los procesos de integración continua y despliegue continuo (CI/CD) automatizan el proceso de entrega de software desde el desarrollo hasta la producción, lo que garantizalanzamientos más rápidos,una calidad constante yuna reducción de los errores manuales.
Integración continua (CI): la fase de compilación y pruebas que utiliza el equipo de Sprint
- Publicación de código: los desarrolladores envían los cambios a un repositorio compartido (por ejemplo, Azure Repos, GitHub).
- Compilación automatizada: el proceso compila el código, resuelve las dependencias y empaqueta los artefactos.
- Pruebas automatizadas: se ejecutan pruebas unitarias, pruebas de integración y análisis de seguridad (SAST/DAST) para detectar problemas en una fase temprana.
- Almacenamiento de artefactos: Las compilaciones validadas se almacenan en repositorios
Implementación continua (CD): la fase de lanzamiento que utiliza el equipo de implementación
- Entornos de prueba: el código avanza a través deDevSecOps → SQA → Preproducción → Producción conetapas de aprobación.
- Implementaciones automatizadas: la implementación se lleva a cabo a través de procesos de lanzamiento con un tiempo de inactividad mínimo
- Comprobaciones tras la implementación: pruebas de funcionamiento automatizadas, supervisión del rendimiento y mecanismos de reversión establecidos y regulados por SOP.
Tipos de versiones: mayor, menor, parche, corrección urgente
Las versiones se clasifican en principales, secundarias, de parches o de correcciones, dependiendo del objetivo y de las características que se incluyan en cada una de ellas.
- Versión principal: indica una versión inicial o una versión en la que las novedades afectan a la funcionalidad y no hay compatibilidad con versiones anteriores.
- Menor: indica el lanzamiento de nuevas funciones con compatibilidad con versiones anteriores y mejoras en las funciones existentes
- Parche: se refiere al lanzamiento de un conjunto de correcciones de errores, actualizaciones de seguridad y pequeñas mejoras, con compatibilidad con versiones anteriores.
- Hotfix: lanzamiento de emergencia destinado a resolver problemas críticos detectados en el entorno de producción en la versión implementada.
Indicadores clave que importan
Explicación de los cuatro indicadores DORA:
Según los estándares del sector, hay cuatro indicadores clave que deben supervisarse y optimizarse para que las organizaciones alcancen el éxito.
- Plazo de entrega (la rapidez con la que lanzamos el software a producción)
- Frecuencia de implementación(cada cuánto tiempo se realizan lanzamientos).
- Modificar la tasa de fallos(la frecuencia con la que fallan las implementaciones).
- Tiempo medio de recuperación (MTTR)(la rapidez con la que se solucionan las averías).
El tiempo de entrega esuna de las cuatro métricas clave de DevOps Research and Assessment (DORA). Mide el tiempo que tardan los cambios en el código en pasar de la confirmación a la implementaciónen producción, lo que refleja la eficiencia de tu proceso de entrega de software. Esta métrica indica la duración media que transcurre entre el momento en que se confirma un cambio en el código y el momento en que se implementa con éxito en producción.
El plazo de entrega indica:
- rapidez en la entregayeficiencia en los procesos.
- Los plazos de entrega más cortos se traducen enciclos de retroalimentación más rápidosyuna mayor agilidad.
La frecuencia de implementación mide la periodicidad con la que los cambios en el código se implementan correctamente en el entorno de producción. Refleja lavelocidad yla consistenciade la entrega de software.
La frecuencia de implementación indica:
- Agilidad del equipoymadurez de los procesos.
- Las implementaciones frecuentes reducen el riesgo al permitircambios más pequeños y graduales(en comparación con las versiones grandes y poco frecuentes).
- Esto se traduce enciclos de retroalimentación más rápidosyuna mayor satisfacción del cliente.
El tiempo medio de recuperación (MTTR)mide eltiempo medio que se tarda en restablecer el servicio tras un fallo(por ejemplo, una interrupción del servicio, una disminución del rendimiento o un error). Reflejala resiliencia de tu equipoy la eficacia de su respuesta ante incidentes.
El MTTR indica:
- Reduce al mínimo el tiempo de inactividady el impacto para los usuarios.
- Un MTTR elevado indicauna depuración lenta, una supervisión deficiente o unos procesos de reversión ineficaces.
- Está relacionado conla confianza de los clientes, los costes operativos y el estrés del equipo.
La tasa de fallos por cambios (CFR)mide elporcentaje de implementaciones que provocan fallos en el entorno de producción y requieren una solución (por ejemplo, reversiones, correcciones o parches). Refleja laestabilidad y la fiabilidadde tu proceso de lanzamiento.
El CFR indica:
- Indicacon qué frecuencia las implementaciones provocan fallos(errores, interrupciones del servicio, problemas de rendimiento).
- Una tasa de mortalidad alta sugiere quelas pruebas son deficientes, que el seguimiento es inadecuado o que las prácticas de liberación son peligrosas.
- Está relacionado conel agotamiento del equipo, la confianza de los clientes y los costes operativos.
| Sistema métrico | Definición | Fórmula |
| Plazo de entrega | Tiempo medio para completar una función | Suma del plazo de entrega y el número de características |
| Frecuencia de implementación | Con qué frecuencia se implementa el código en el entorno de producción. | Total de despliegues / Número de meses |
| Índice de fallos en el cambio (CFR) | Porcentaje de implementaciones que provocan un fallo. | Número de cambios fallidos ÷ Número total de cambios × 100. |
| Tiempo medio de reparación (MTTR) | Tiempo medio necesario para restablecer el servicio tras una avería. | Suma de los tiempos de restauración ÷ Número de fallos (problemas de funcionamiento/errores de software/problemas con los datos) |
Métricas complementarias:
- Trabajo en curso (WIP): Mide el número de tareas sin terminar (por ejemplo, cambios en el código, funcionalidades, errores) que se encuentran actualmente en proceso. Esta métrica ayuda a identificar los cuellos de botella y la necesidad de dividir la funcionalidad o la historia de usuario.
- Tiempo de ciclo: tiempo transcurrido desdeel inicio del trabajo(por ejemplo, la creación del ticket) hastasu finalización
- Número de solicitudes de incorporación de cambios: métrica que registra elnúmero de solicitudes de incorporación de cambios creadas, fusionadas o rechazadas duranteun periodo de tiempo determinado (por ejemplo, diario, semanal o mensual). Ayuda a los equipos a evaluarla productividad de los desarrolladores, la eficacia de la colaboración y los cuellos de botella en el flujo de trabajo.
- Incidentes de clientes: número de incidentes de producciónnotificados por los clientes que reflejan la calidad de las pruebas internas
- Errores pendientes: esta métrica registra el número de defectos (errores) sin resolver en el sistema en un momento dado. Ayuda a evaluar la calidad del software, la deuda técnica y la eficiencia del equipoa la hora de gestionar los problemas.
- Errores pendientes desde hace tiempo: los errores pendientes desde hace tiempo sondefectos que permanecen sin resolver durante un periodo prolongado (normalmente más de 30 días). Su seguimiento ayuda a identificarineficiencias en los procesos, deficiencias en la priorización y deuda técnica.
- Errores aplazados: se trata de defectos que se hanidentificado pero cuya resolución se ha pospuesto intencionadamentepara más adelante. Aunque el aplazamiento puede ser una estrategia legítima, un número excesivo de aplazamientos puede indicaruna acumulación de deuda técnica, problemas de priorización o ineficiencias en los procesos.
- Estado de las compilaciones de CI: esta métrica supervisa laestabilidad y la fiabilidad de tu canal de integración continua (CI) medianteel seguimiento de la tasa de éxito o fracaso de las compilaciones y pruebas automatizadas. Un sistema de CI en buen estado es fundamental para obteneruna retroalimentación rápida, lanzamientos de alta calidad y la productividad de los desarrolladores.
- Estado del ciclo de desarrollo y lanzamiento (CD): esta métrica supervisa laestabilidad, la velocidad y la tasa de éxito de tu implementación automatizada. Un sistema de CD en buen estado garantiza lanzamientosfiables, frecuentes y de bajo riesgo.
- Pruebas de integración: Las pruebas de integración verifican quelos módulos, servicios o sistemas desarrollados de forma independiente funcionen correctamente cuando se combinan. Se trata de una fase fundamental en DevOps para detectar problemasantes de que reach .
- Conjunto de herramientas de supervisión de producción: conjunto de herramientas y prácticas para supervisar el estado del sistema, detectar anomalías y resolver problemas en tiempo real en las aplicaciones que se ejecutan en entorno de producción. Es fundamental para que los equipos de SRE, DevOps y Operaciones mantengan el tiempo de actividad, el rendimiento y la satisfacción de los usuarios.
Por qué las métricas son importantes en una organización de éxito
El seguimiento de las métricas de DevOps y operativas (comoDORA, el tiempo de entrega, la frecuencia de implementación, el MTTR, el CFR, las alertas de monitorización, etc.) proporcionainformación útilque impulsael éxito empresarial, la excelencia técnica y la ventaja competitiva.
- Acelerar la comercialización
- Métricas:plazo de entrega, frecuencia de implementación, tiempo de ciclo
- Repercusión:
- Lanzamientos más rápidos →Respuesta más ágil a las demandas del mercado.
- Ciclos de retroalimentación más cortos →Innovar más rápido que la competencia.
- Mejorar la calidad y la fiabilidad del software
- Métricas:Índice de fallos por cambios (CFR), tiempo medio de recuperación (MTTR), incidencias pendientes
- Repercusión:
- Menos fallos de producción →Mayor satisfacción del cliente.
- Resolución más rápida de incidencias →Minimizar la pérdida de ingresos
- Reducir costes y residuos
- Métricas:estado de la integración continua, fallos en las pruebas de integración, pruebas inestables
- Repercusión:
- Detección temprana de errores →Es más barato solucionarlos en el entorno de desarrollo que en el de producción
- Flujos de trabajo eficientes →Ahorro en costes de nube y de recursos informáticos
- Mejora la productividad y la moral del equipo
- Métricas:tiempo de ciclo de PR, límites de trabajo en curso, tasa de éxito de las implementaciones
- Repercusión:
- Menos cuellos de botella →Los desarrolladores dedican más tiempo a programar y menos a esperar.
- Comprobaciones automatizadas →Reducir el agotamiento derivado del trabajo manual.
- Alinear DevOps con los objetivos empresariales
- Indicadores:Entrega de unidades comercializables, tasa de incidencias de clientes, compromisos de tiempo de actividad
- Repercusión:
- Vincula el trabajo de ingeniería conlos ingresos, el crecimiento del número de usuarios y la retención.
- Toma de decisiones basada en datos
- Métricas:Tendencias en el MTTR, la antigüedad de los errores y la frecuencia de implementación
- Repercusión:
- Dar prioridad alas mejoras de gran repercusión
- Justifica las inversiones enautomatización, formación o herramientascon ROI .
Resumen:
Alautomatizar el seguimiento y la optimizaciónde estos indicadores clave, las organizaciones pueden obtener importantes ventajas, entre las que se incluyen:
- Decisiones basadas en datos: aprovecha la información útil para orientar la estrategia y las inversiones.
- Excelencia en ingeniería: fomentar la mejora continua en las prácticas de desarrollo y operativas.
- Competitividad del sector: igualar (o superar) los mejores índices de referencia del sector.
- Éxito del cliente: ofrecer soluciones fiables y de alta calidad que satisfagan las expectativas de los usuarios.
- Gobernanza y liderazgo: garantizar la transparencia y la rendición de cuentas en todos los niveles.
Este enfoque estructurado garantizaprocesos más eficientes, un mejor rendimiento y un crecimiento empresarial sostenido.
Referencias
- Accelerate, de Forsgren, Humble y Kim
- Documentación de Azure DevOps
- Informes de Investigación y Evaluación de DevOps (DORA)