Producto
Archito NuevoAprende de sus merge requests y señala lo atascado Integraciones 25
Soluciones
Por rol
Por qué AppArch
Recursos
Clientes Precios Contacto
Idioma
Contáctanos

Cómo se gestionan sus repositorios, puntuado en un solo lugar.

Salud de Git revisa cómo se gestiona cada repositorio, no lo que contiene: ¿está protegida la rama por defecto, se aprueban los merge requests, llevan los commits una clave de tarea, hay seguridad en el pipeline, están los archivos necesarios? 29 reglas y una puntuación ponderada en GitHub, GitLab, Bitbucket y Azure DevOps.

Pantallas de una instalación en funcionamiento

Seis grupos, 29 reglas

Cada regla responde una pregunta de sí o no sobre cómo se gestiona el repositorio y lleva una severidad y un peso.

5 reglas

Protección de ramas

Rama por defecto protegida, sin push directo ni forzado, ramas de release y etiquetas protegidas.

6 reglas

Reglas de merge request

Aprobación obligatoria, número mínimo de aprobaciones, sin autoaprobación, discusiones resueltas y pipeline en verde antes de fusionar, rama de origen eliminada después.

5 reglas

Trazabilidad

Los commits y los títulos de MR llevan una clave de tarea, los nombres de rama siguen un patrón y hay un gestor de tareas conectado.

7 reglas

Seguridad en CI

SAST, detección de secretos, análisis de dependencias y contenedores, un SBOM y SonarQube con informes de MR - detectados en el pipeline, plantillas incluidas también.

5 reglas

Higiene del repositorio

CODEOWNERS, un lockfile en el repositorio, plantillas de merge request y de incidencias, y ningún archivo secreto confirmado (se identifica por nombre; nunca se lee el contenido). README, .gitignore y SECURITY.md los revisa el módulo de Cumplimiento.

1 reglas

El propio AppArch

Un collector ha informado en los últimos 30 días, así que el resto de puntuaciones están al día.

Desconocido no es cero

Una regla que la plataforma o el token no pueden responder se marca como omitida y queda fuera de la puntuación. Una conexión con un token caducado muestra «0 de 2 puntuables», nunca «29 fallos». Igual con un pipeline que no se puede leer entero: un include ilegible significa omitida, no fallida.

Sin inscripción, nada que lanzar a mano

Todo proyecto con conexión Git participa desde que se añade.

  1. 01

    Añadir un proyecto

    El primer análisis se encola en cuanto se crea el proyecto.

  2. 02

    Los análisis se mantienen al día

    Los análisis programados revisan cada repositorio; un ajuste cambiado la semana pasada aparece sin que nadie lo pida.

  3. 03

    Corregir y seguir la puntuación

    Cada regla fallida dice lo que encontró; la puntuación del proyecto aparece en la ficha de salud junto a las de los demás módulos.

Qué se puede comprobar en cada plataforma

No todas las plataformas exponen cada ajuste por su API. Cuando una no puede responder, la regla se omite y sale de la puntuación; nunca cuenta como fallo.

GitLab GitHub Bitbucket Azure DevOps
Ramas principal y de release protegidas
Reglas de merge: aprobaciones, sin autoaprobación, pipeline en verde, hilos resueltos omitida omitida
Sin force push ni push directo a la rama principal omitida omitida
Rama de origen borrada tras el merge omitida omitida
Etiquetas protegidas, clave de incidencia en reglas de rama omitida omitida omitida
Claves de incidencia en commits y títulos de MR, nombres de ramas
CODEOWNERS, lockfile, plantillas, sin secretos confirmados en parte en parte
Herramientas de seguridad en CI: SAST, secretos, dependencias, contenedores, SBOM, SonarQube
Collector activo, gestor de incidencias conectado

Las reglas que revisan muchos elementos dan crédito parcial: una rama sin proteger de siete no cuesta lo mismo que siete.

Todos los merge requests de todos los proveedores en una lista

Salud de Git también reúne los merge requests del espacio de trabajo, estén en la plataforma que estén.

  • Filtrar por estado, proyecto, autor y rama de destino, o buscar
  • Una insignia enlaza cada MR revisado con su informe de ArchPilot
  • El filtro «más de lo habitual» de Archito muestra lo atascado

Preguntas sobre Salud de Git

¿Qué plataformas cubre?
GitHub, GitLab (gitlab.com o autoalojado), Bitbucket Cloud y Azure DevOps. Una regla que una plataforma no puede responder - Bitbucket y Azure DevOps no tienen un ajuste de borrar la rama de origen para todo el repositorio, por ejemplo - se omite, nunca falla.
¿Lee nuestro código?
No. Lee los ajustes del repositorio, la protección de ramas y etiquetas, los últimos commits y merge requests, la configuración de CI y el árbol de archivos. Los archivos secretos se detectan por nombre; su contenido nunca se lee.
¿Qué permisos necesita el token?
El acceso de lectura cubre la mayoría de reglas. Algunos ajustes solo los ve un token de administrador - borrar la rama al fusionar en GitHub, por ejemplo; sin él, esa regla se omite.
¿Cambia Salud de Git nuestras otras puntuaciones?
No. Tiene su propia puntuación, junto a las de ArchScan, ArchSecurity y Cumplimiento en la ficha de salud de cada proyecto.

Míralo en el producto

Todas las capturas

Vea cómo se gestionan de verdad sus repositorios

Conecte un proveedor Git durante una PoC; las primeras puntuaciones llegan en cuanto se añaden los proyectos.