Plataformas Git
Repositorios, merge requests y miembros vienen de aquí. Conexión con token de acceso o aplicación OAuth; GitLab autoalojado también funciona.
Revisión de arquitectura en cada pull request, en sus propios servidores.
AppArch lee la estructura de su código - capas, dependencias, contratos - y comenta el pull request en cuanto se abre. Se ejecuta en su CI y en su red. Nada sale.
- Instalado en sus servidores
- 9 lenguajes
- GitLab, GitHub, Bitbucket, Azure DevOps
9lenguajes: lenguajes: .NET, Java, Python, Go, TypeScript, Ruby, PHP, Kotlin, Swift
1000+reglas: reglas en el catálogo, cada una con su página
4plataformas Git: plataformas Git
5módulos: módulos sobre un mismo grafo de código
<2 minpor revisión: por revisión: menos de 2 minutos, medido en un repositorio de 5 GB
4marcos de seguridad: marcos de seguridad: OWASP, PCI DSS, STIG, CASA
Cinco módulos, una sola lectura de su código
Cada módulo responde a una pregunta distinta sobre el mismo repositorio. Active los que necesite; comparten el catálogo de reglas y el grafo de dependencias.
ArchPilot
Comentarios de revisión en el pull request
- Comentarios en línea con el código de la regla y enlace a su documentación
- Un comentario resumen por merge request: nuevos, abiertos, resueltos
ArchScan
Un informe completo de todo el código
- Cada hallazgo incluye las líneas afectadas, no solo un nombre de archivo
- Un mapa de dependencias interactivo de proyectos y paquetes
ArchSecurity
Análisis de seguridad estático asignado a los marcos que piden los auditores
- Un informe por marco, listo para auditoría
- Dependencias vulnerables comprobadas contra un conjunto de avisos sin conexión
Cumplimiento
Comprobaciones de política con puntuación y traza de auditoría
- Reglas activadas por proyecto, por espacio de trabajo o para toda la instalación
- Análisis programados, para que la puntuación siga actualizada sin que nadie tenga que acordarse
Git Health
29 comprobaciones sobre cómo se gestiona el repositorio
- Protección de ramas, reglas de MR, seguridad en CI
- Los hallazgos llevan un valor, no solo aprobado o fallido
¿Por dónde empezar?
La mayoría de los equipos empieza con ArchPilot: el primer comentario llega en la siguiente pull request.
Cómo llega un hallazgo a su pull request
Tres pasos, sin agente en la máquina del desarrollador, nada que llame a casa.
- 01
Registre el repositorio
Conecte una credencial de Git en el panel y elija el repositorio. AppArch emite un token de proyecto.
- 02
Añada un job a su pipeline
Una imagen de contenedor por lenguaje se ejecuta como job de CI sobre el código descargado. Obtiene las reglas, analiza in situ y envía solo los resultados.
- 03
Lea el comentario, abra el informe
El ingeniero ve el hallazgo en el pull request; el equipo ve la puntuación, la tendencia y los hallazgos en el panel.
Las reglas se gestionan en el panel, no en un archivo
Cada regla del catálogo tiene un código, un nombre, una descripción y una página de documentación. Desactive una regla para toda la instalación, un espacio de trabajo o un proyecto; gana el ajuste más específico.
- El umbral que hace fallar un pipeline es un ajuste, no un cambio de código.
- El alcance del análisis - qué carpetas cuentan - se define en el mismo lugar.
- Cada regla tiene su propia página de documentación en docs.apparch.io.
Diseñado para funcionar dentro de su red
No hay versión alojada. AppArch se instala en un host que usted controla, y el código que lee nunca sale de su CI.
Instalación en un solo host
Docker Compose con PostgreSQL y Redis. Un asistente crea el primer administrador; las actualizaciones aplican sus propias migraciones.
Inicio de sesión con su directorio
Inicio de sesión con LDAP y Active Directory, autenticación de dos factores, invitación por dominio. Sin inicio de sesión social.
Licencia firmada, sin conexión si hace falta
La licencia es un archivo firmado que la instalación verifica localmente. Los sitios aislados obtienen las imágenes de un registro privado y nunca llaman al exterior.
Ningún dato de uso sale
La única llamada saliente es la comprobación de actualizaciones, opcional y desactivable. Todo lo demás se queda en su host.
Con qué se conecta
Las plataformas Git aportan los repositorios y los merge requests; el resto añade alrededor despliegues, incidentes, tareas e IA.
Pipelines de CI
El analizador se ejecuta como un job en tu propio pipeline: fragmentos listos para cuatro proveedores y un docker run simple para el resto.
Despliegue
Qué versión corre en qué entorno se escribe en el catálogo de servicios.
Observabilidad
Con Dynatrace, New Relic o Percona PMM conectado llegan los registros de incidentes, y las dos métricas DORA vacías, tasa de fallos de cambios y tiempo de recuperación, se llenan con datos reales. Percona PMM añade además los tiempos de consulta de la base de datos.
Calidad y pruebas
Las métricas y hallazgos de SonarQube están junto a los de AppArch; los resúmenes de pruebas de JMeter llegan a la página de pruebas de rendimiento del proyecto.
IA
El operador de la instalación conecta un proveedor; las solicitudes salen de esa cuenta y nada pasa por AppArch.
Seguimiento de incidencias
Los hallazgos se abren como incidencias en el tablero que tu equipo ya usa. El mapeo de proyecto se configura por espacio de trabajo.
Inicio de sesión y notificaciones
Se inicia sesión con la cuenta de LDAP o Active Directory; las notificaciones salen por correo a través de tu propio servidor SMTP. Los canales de Slack y Teams están en camino.
¿Para qué sirve una herramienta de revisión de arquitectura?
Una base de código está hecha de cientos de pequeñas decisiones que, una a una, parecen correctas: qué capa llama a cuál, cuándo se rompió un contrato de servicio, en qué cambio desapareció un control de seguridad. La revisión de código ve estas decisiones, pero se cansa con el tiempo; nadie escribe a mano el mismo aviso en cada pull request.
Una herramienta de revisión de arquitectura convierte esas decisiones en reglas y las aplica automáticamente a cada cambio. El desarrollador ve el hallazgo en su propia pull request, el líder del equipo sigue la tendencia en el panel y el equipo de seguridad obtiene el informe de cumplimiento del mismo análisis.
En qué se diferencia de un linter o de una plataforma de calidad de código
Un linter mira un archivo cada vez. AppArch lee el grafo de dependencias de todo el repositorio, así que puede decir que un proyecto de presentación referencia la infraestructura o que dos módulos dependen entre sí. Los hallazgos de escáneres externos aparecen en el mismo panel, etiquetados con su origen.
Qué mirar al elegir una
- ¿Sale el código de su red? Una herramienta que se ejecuta on-premise mantiene el código dentro de su propia red.
- ¿Quién gestiona las reglas? Gestionar las reglas en un panel y no en un archivo mantiene a todo el equipo coherente.
- ¿Escribe en la pull request? Los informes no se leen; un comentario en línea sí.
Para más detalles, consulte las páginas ArchPilot, On-premise y air-gap y catálogo de reglas.
Preguntas frecuentes
¿En qué se diferencia de un linter o de SonarQube?
Un linter mira un archivo. AppArch lee el grafo de dependencias de todo el repositorio, por lo que puede decir que un proyecto de presentación referencia a infraestructura, o que dos módulos dependen entre sí. Los hallazgos de SonarQube pueden reflejarse en ArchSecurity junto a los propios de AppArch, etiquetados por origen.
¿Qué lenguajes se admiten?
.NET, Java, Python, Go, TypeScript y JavaScript (incluidos React, React Native y Node.js), Ruby, Kotlin, Swift y PHP. Cada uno tiene su propia imagen de análisis y su propia parte del catálogo de reglas.
¿Sale nuestro código de nuestra red?
No. El analizador se ejecuta como job en su propia CI, sobre el código descargado, y envía solo los hallazgos al servidor AppArch, que también es suyo. No hay ningún servicio alojado en el camino.
¿Y los falsos positivos?
Desactive la regla para el proyecto, el espacio de trabajo o toda la instalación, o reduzca el alcance del análisis para omitir la carpeta. Los hallazgos también pueden reconocerse en el panel, y la severidad de una regla puede bajarse para que ya no haga fallar el pipeline.
¿Cómo se licencia?
Por instalación, con un archivo de licencia firmado que fija los usuarios y los proyectos; todos los módulos están incluidos. Sin cobro por análisis y sin versión alojada. Contáctenos y lo dimensionamos juntos.
¿Cuánto tarda la instalación?
Un solo host con Docker: descargue las imágenes, ejecute el archivo compose, siga el asistente. Registrar el primer repositorio y añadir el job de CI suele caber en la misma tarde.
Véalo con su propio código
Reserve una demo de treinta minutos. Recorremos el panel con un repositorio real y respondemos a las preguntas de su equipo.