Discovery — Auditoría DevOps & CI/CD

Instrucciones: Este assessment toma entre 10 y 15 minutos. Con sus respuestas, el equipo de Virtual Xpert preparará una propuesta técnica y comercial a medida en un plazo de 48–72 horas. Sus respuestas son confidenciales y serán utilizadas únicamente para diseñar su propuesta. El objetivo de este formulario es concreto: entender dónde está parado su equipo hoy en el ciclo de entrega de software. No se requieren respuestas técnicas exhaustivas; una estimación honesta es suficiente. Los campos marcados con ★ son clave para el diagnóstico. Si algún dato no está disponible o no aplica, indíquelo — eso también es información útil.

Perfil de la Organización

Contexto del equipo y stack tecnológico

Nombre de la organización ★

Industria / Sector ★

País(es) de operación

Tamaño del equipo de desarrollo ★

1-2 personas 3-5 personas 6-15 personas 16-50 personas Más de 50

Roles presentes en el equipo

Developers full stack Developers backend Developers frontend QA / Testers DevOps / SRE Arquitecto de software Tech Lead Product Owner / PM Ninguno dedicado a DevOps

Tipo de aplicaciones que desarrollan ★

Aplicaciones web APIs / microservicios Mobile (iOS/Android) Integraciones con ERP o sistemas externos Aplicaciones de escritorio Scripts / automatizaciones internas Otro

Stack tecnológico principal

Contacto responsable ★ Nombre, cargo, email y WhatsApp

Gestión del Código Fuente

Source control y branching strategy

¿Usan sistema de control de versiones? ★

Sí, usamos Git Sí, pero no todos los desarrolladores lo usan Usamos SVN u otro sistema No usamos control de versiones

Herramienta de repositorio

GitHub GitLab Bitbucket Azure DevOps Repos Servidor propio (self-hosted) No usamos repositorio

¿Dónde está alojado el repositorio?

Hosting del código fuente

Cloud SaaS (GitHub.com, GitLab.com, Bitbucket Cloud, etc.) Self-hosted en servidor propio / VM (on-premise o en nube) Repositorio integrado en la herramienta de CI/CD Mixto

Estrategia de branching

GitFlow (main/develop/feature/release) Trunk-based development (rama principal + feature branches cortas) Un solo branch (main/master para todo) No tenemos una estrategia definida Otro

Detalle de la estrategia

¿Usan Pull Requests / Merge Requests?

Sí, siempre A veces No usamos

¿Hay revisión de código (code review) antes de mergear?

Sí — revisión obligatoria por al menos un par Sí — revisión ocasional pero no obligatoria No — mergeamos directamente No aplica

¿Quién puede hacer push/merge a la rama principal?

Solo Tech Lead o Arquitecto Todo el equipo de desarrollo Cualquier persona con acceso al repositorio No está definido

Proceso de Despliegue Actual

Cómo se entrega software hoy

¿Cómo realizan los despliegues a producción hoy? ★

Manual — acceso directo al servidor (SSH, RDP, FTP) Manual — con scripts propios que ejecutamos a mano Semi-automático — pipeline parcial con pasos manuales Automático — CI/CD completo sin intervención manual No tenemos un proceso definido

¿Quién ejecuta el despliegue a producción?

El desarrollador que hizo el cambio El Tech Lead Un rol dedicado (DevOps/SysAdmin) Cualquier miembro del equipo Un proceso automático (pipeline)

Frecuencia de despliegues a producción

Varias veces al día Una vez al día Varias veces por semana Una vez por semana Cada 2-4 semanas Una vez al mes o menos

Tiempo promedio de un despliegue Desde código listo hasta en producción

Menos de 30 min 30 min – 2 horas 2 – 8 horas Más de 8 horas No lo medimos

¿Tienen ambientes separados? ★

Desarrollo (dev) QA / Testing Staging / Pre-producción Producción Ninguno separado

¿Qué pasa cuando un deploy falla?

Hay un proceso de rollback definido y probado Hacemos rollback manualmente (tarda pero funciona) Tenemos que corregir el error y volver a desplegar No tenemos proceso definido — improvisamos

¿Cuánto tarda recuperarse de un fallo en producción?

Menos de 1 hora 1-4 horas 4-8 horas Más de 8 horas No lo medimos

CI/CD — Automatización del Pipeline

Integración y entrega continua

¿Tienen pipelines de CI/CD implementados? ★

Sí — pipeline completo (CI + CD) Sí — solo CI (build y tests automáticos) Sí — solo CD (deploy automático sin tests) Parcialmente — algunos proyectos tienen No — todo es manual Estamos en proceso de implementarlo

Herramienta de CI/CD

GitHub Actions Azure Pipelines (Azure DevOps) GitLab CI/CD Jenkins CircleCI Bitbucket Pipelines TeamCity Ninguna Otro

¿Qué incluye el pipeline hoy?

Build / compilación automática Ejecución de tests unitarios Ejecución de tests de integración Análisis estático de código (linting/SonarQube) Escaneo de vulnerabilidades de dependencias Deploy automático a staging Deploy automático a producción Notificaciones (Slack/email) al equipo Ninguna de las anteriores

¿Qué etapas les gustaría agregar o mejorar?

¿Cómo definen los pipelines?

Forma en que se configuran los pipelines de CI/CD

YAML en repositorio (pipeline as code) Editor visual / Classic Editor Mixto — algunos en YAML, otros en editor visual Scripts propios fuera de la herramienta de CI/CD No aplica / no tenemos pipelines

¿Qué porcentaje de aplicaciones tiene pipeline de CI/CD?

Todas La mayoría (+70%) Algunas (30–70%) Pocas (-30%) Ninguna

Testing y Calidad

Cobertura y automatización de pruebas

¿Tienen tests automatizados? ★

Sí — cobertura alta (+70%) Sí — cobertura media (30-70%) Sí — cobertura baja (-30%) No — solo pruebas manuales No tenemos pruebas de ningún tipo

Tipos de tests que tienen hoy

Tests unitarios Tests de integración Tests end-to-end (E2E) Tests de performance / carga Tests de regresión Ninguno

¿Los tests corren automáticamente en el pipeline?

Sí, siempre A veces No — los corremos manualmente No tenemos pipeline

¿Tienen QA dedicado? La ausencia de QA no es un problema en sí — nos ayuda a dimensionar el esfuerzo

Sí — QA en equipo interno Sí — QA externo / tercerizado No — los developers hacen las pruebas No — ningún proceso de QA formal

Herramientas de calidad de código

SonarQube / SonarCloud ESLint / TSLint Prettier ReSharper Checkmarx Ninguna

ℹ La incorporación de tests automatizados al pipeline es uno de los quick wins de mayor impacto en proyectos DevOps — reduce la tasa de bugs en producción hasta un 40%.

Seguridad en el Pipeline — DevSecOps

Gestión de secretos y accesos

¿Cómo gestionan credenciales y secretos? ★ Las credenciales hardcodeadas en el código son uno de los principales riesgos de seguridad

Usamos un gestor de secretos (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault) Usamos variables de entorno del pipeline (GitHub Secrets, Azure Pipeline Variables) Están en archivos .env que no se suben al repositorio Están hardcodeadas en el código fuente No tenemos una política definida

⚠ Si tienen credenciales hardcodeadas en el repositorio, esto debe resolverse como prioridad antes de cualquier otra mejora al pipeline.

¿Quién tiene acceso a los servidores de producción?

Solo DevOps / SRE dedicado Tech Lead y DevOps Todo el equipo de desarrollo Cualquier persona con las credenciales No está definido formalmente

¿Tienen registro de auditoría de los deploys?

Sí — logs completos con quién y cuándo Parcialmente No

¿Realizan escaneo de vulnerabilidades en dependencias?

Sí, automático en el pipeline Sí, manualmente de vez en cuando No

¿Tienen política de rotación de credenciales?

Sí, definida y cumplida Sí, pero informal No

Infraestructura y Ambientes

Plataforma y consistencia de entornos

¿Dónde están alojadas las aplicaciones? ★

Microsoft Azure Amazon Web Services (AWS) Google Cloud Platform (GCP) Servidores on-premise propios Hosting compartido (cPanel, etc.) Mixto (cloud + on-prem) Otro

¿Usan contenedores?

Sí — Docker + Kubernetes (orquestado) Sí — Docker sin orquestación Estamos evaluando adoptarlos No usamos contenedores

¿Usan Infrastructure as Code (IaC)?

Sí — Terraform Sí — Bicep / ARM Templates (Azure) Sí — Ansible Sí — otro No — la infraestructura se crea manualmente Estamos evaluando adoptarlo

¿Los ambientes (dev/staging/prod) son consistentes entre sí? La inconsistencia entre ambientes es una causa frecuente de bugs que solo aparecen en producción

Sí — son prácticamente idénticos Parcialmente — hay diferencias menores No — son muy distintos y generamos bugs por eso No tenemos ambientes separados

¿Cómo segmentan los ambientes en su plataforma cloud?

Ej.: cuentas/proyectos/suscripciones separadas por ambiente, o todo en una sola con resource groups/namespaces

Cuentas / suscripciones / proyectos separados por ambiente (dev, QA, prod) Una sola cuenta con resource groups / namespaces por ambiente Sin separación formal — todo convive en el mismo espacio No usamos nube pública

¿Tienen estrategia de etiquetado (tagging) de recursos?

Etiquetas como environment, owner, project, cost-center permiten atribuir costos y auditar recursos

Sí — estrategia formal y aplicada consistentemente Parcialmente — algunos recursos etiquetados, sin estándar claro No — no tenemos etiquetado de recursos No aplica

Observabilidad y Monitoreo

Visibilidad sobre el sistema en producción

¿Tienen monitoreo de sus aplicaciones en producción? ★

Sí — monitoreo completo con alertas Sí — logs básicos pero sin alertas proactivas Parcialmente — algunos sistemas monitoreados No — nos enteramos de los problemas cuando los reportan los usuarios

Herramientas de monitoreo y observabilidad

Azure Monitor / Application Insights Datadog Grafana + Prometheus New Relic Elastic / ELK Stack Sentry CloudWatch (AWS) Ninguna Otro

¿Tienen logs centralizados?

Sí No Parcialmente

¿Reciben alertas automáticas cuando algo falla?

Sí No Solo para algunos sistemas

¿Cuánto tiempo tardan en detectar un problema en producción?

Menos de 5 minutos (alerta automática) 5-30 minutos 30 min – varias horas Cuando un usuario nos avisa No lo sabemos

Métricas DORA — Estado Actual

Las 4 métricas clave de madurez DevOps

Las métricas DORA (DevOps Research and Assessment) son el estándar global para medir la madurez de un equipo de entrega de software. No hace falta precisión exacta — una estimación es suficiente para diagnosticar su nivel actual.

MÉTRICA DORA	HOY (estimación)	META DESEADA
Deployment Frequency ¿Con qué frecuencia despliegan a producción?
Lead Time for Changes ¿Cuánto tiempo desde que el código está listo hasta que está en producción?
Change Failure Rate ¿Qué % de los deploys genera un incidente o rollback?
MTTR (Mean Time to Recovery) ¿Cuánto tardan en recuperarse de un fallo en producción?
Cobertura de tests % estimado de código cubierto por tests automatizados
Deploys con rollback (último mes) Cantidad de deploys que requirieron rollback en el último mes

ℹ Equipos de alto rendimiento según DORA despliegan varias veces al día, con lead times menores a 1 hora y tasas de fallo menores al 5%. Esta auditoría identifica el camino más corto hacia ese nivel.

Objetivos, Prioridades y Expectativas

A dónde quieren llegar y con qué urgencia

Principales dolores del proceso actual ★

Despliegues lentos o propensos a errores Falta de visibilidad sobre qué se desplegó y cuándo Demasiado tiempo manual en tareas repetitivas Miedo a desplegar — deployamos poco y en horarios nocturnos Bugs que aparecen en producción pero no en desarrollo Falta de tests — no sabemos si algo rompimos Credenciales o secretos mal gestionados Falta de cultura de revisión de código No sabemos cuánto tardamos ni cuántos errores tenemos Otro

¿Qué quieren mejorar primero?

Automatizar el pipeline de CI/CD desde cero Agregar tests automatizados al proceso Mejorar la seguridad del pipeline (secretos, accesos) Unificar y ordenar los ambientes Implementar monitoreo y alertas Mejorar la estrategia de branching y code review Todo — necesitamos una hoja de ruta completa

¿El equipo tiene experiencia con herramientas DevOps?

Sí — el equipo ya conoce GitHub Actions, pipelines, etc. Básica — conocen los conceptos pero no tienen práctica Poca — la mayoría no ha trabajado con estas herramientas Ninguna — sería una adopción desde cero

¿Les interesa capacitación del equipo como parte del proyecto? Capacitamos al equipo durante la implementación para que no dependan de un proveedor a futuro

Sí — es fundamental que el equipo aprenda mientras implementamos Sí — queremos talleres/workshops separados No — solo queremos la implementación Evaluamos según propuesta

Urgencia del proyecto

Urgente — necesitamos avanzar este mes En los próximos 3 meses En los próximos 6 meses Estamos evaluando — sin fecha definida

Presupuesto orientativo Esto nos ayuda a diseñar una propuesta realista y ajustada a su contexto — no condiciona el alcance de la solución.

Menos de USD 3.000 USD 3.000 – 8.000 USD 8.000 – 20.000 Más de USD 20.000 Prefiero no indicar

¿Están evaluando otros proveedores?

Sí No — Virtual Xpert es nuestra primera consulta Ya decidimos trabajar con VX

Comentarios adicionales o contexto Cualquier detalle relevante que no haya quedado cubierto arriba

Hubo un error al enviar. Por favor escribinos a info@virtual-xpert.com

Cuestionario de Discovery — Auditoría DevOps & CI/CD