Discovery — Auditoría DevOps & CI/CD

Instrucciones: Este formulario tiene un objetivo 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. Puede dejar en blanco lo que no aplique.

Perfil de la Organización

Contexto del equipo y stack tecnológico

Nombre de la organización ★ org_nombre

Industria / Sector ★ industria

País(es) de operación paises

Tamaño del equipo de desarrollo ★ equipo_dev_size

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

Roles presentes en el equipo roles_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 ★ tipo_apps

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

Stack tecnológico principal stack_tech

Contacto responsable ★ Nombre, cargo, email y WhatsApp

Gestión del Código Fuente

Source control y branching strategy

¿Usan sistema de control de versiones? ★ usa_vcs

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

Herramienta de repositorio herramienta_repo

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

Estrategia de branching branching_strategy

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 branching_detalle

¿Usan Pull Requests / Merge Requests? usa_pr

Sí, siempre A veces No usamos

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

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? merge_permisos

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? ★ deploy_metodo

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? deploy_ejecutor

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 deploy_frecuencia

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 deploy_tiempo

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

¿Tienen ambientes separados? ★ ambientes

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

¿Qué pasa cuando un deploy falla? rollback_proceso

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? mttr_actual

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? ★ tiene_cicd

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 herramienta_cicd

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

¿Qué incluye el pipeline hoy? pipeline_incluye

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? pipeline_mejorar

Testing y Calidad

Cobertura y automatización de pruebas

¿Tienen tests automatizados? ★ tiene_tests

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 tipos_tests

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? tests_automaticos

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

¿Tienen QA dedicado? tiene_qa 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 herramientas_calidad

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? ★ gestion_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? acceso_produccion

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? auditoria_deploys

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

¿Realizan escaneo de vulnerabilidades en dependencias? escaneo_vulnerabilidades

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

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

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

Infraestructura y Ambientes

Plataforma y consistencia de entornos

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

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? usa_contenedores

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

¿Usan Infrastructure as Code (IaC)? usa_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í? consistencia_ambientes 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

Observabilidad y Monitoreo

Visibilidad sobre el sistema en producción

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

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 herramientas_monitoreo

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

¿Tienen logs centralizados? logs_centralizados

Sí No Parcialmente

¿Reciben alertas automáticas cuando algo falla? alertas_automaticas

Sí No Solo para algunos sistemas

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

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 ★ dolores_actuales

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? prioridad_mejora

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? exp_equipo_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? interes_capacitacion 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 urgencia

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

Presupuesto orientativo presupuesto

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? eval_competidores

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

Comentarios adicionales o contexto contexto_adicional 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