Ir al contenido

Proyecto independiente de I+D · Colonia

AnyLAI

Fences ejecutables

Un estado prohibido impide la integración, la versión, el despliegue o la publicación afectados.

No normativo

Versión del Companion
1.0
Corresponde a COADF Core
2.2
Estado
Vigente
Última revisión
Principios de COADF
P-6

En esta página

  1. Propiedad de arquitectura
  2. Por qué importa
  3. Estrategias de implementación válidas
  4. Modos de fallo
  5. Verificación
  6. Realizaciones alternativas
  7. Limitaciones
  8. Fuentes

Propiedad de arquitectura

COADF P-6: una barrera que vive en un documento es un consejo; una barrera que se ejecuta en la pipeline y bloquea una entrega es un fence. Los fences caen en cuatro categorías (datos, arquitectura, texto y proceso), cada uno con un identificador, una regla y un método de aplicación, y un fence se gana su sitio solo con una prueba de dientes. COADF no publica el vocabulario con el que hace coincidencia su propio fence de publicación, porque una lista de lo que se vigila es un mapa de lo que se protege.

La propiedad no es “hay una comprobación”. Es que el estado prohibido no puede pasar de un punto determinado, y que alguien ha visto cómo se le detiene allí.

Por qué importa

Cualquier otra propiedad de este Companion puede implementarse correctamente una vez y perderse en el cambio siguiente. Un fence es lo que mantiene verdadera una propiedad a través de cambios que nadie revisó pensando en ella. Lo difícil rara vez es escribir la comprobación. Es colocarla en el camino que el estado prohibido tiene que recorrer, y demostrar que salta allí, en el camino real, y no en una prueba unitaria de la función que comprueba.

Estrategias de implementación válidas

Superficies de aplicación

Cada superficie ve algo distinto, y cada una tiene una forma característica de eludirla. Un fence pertenece a la superficie que ve el estado prohibido, y es tan fuerte como lo permita la forma de eludir esa superficie.

Dónde puede situarse un fence, qué ve allí y cómo se elude habitualmente
SuperficieVeForma habitual de eludirla
Compilador y comprobador de tiposLa estructura del código y los tipos declaradosCasts, tipado dinámico, reflexión, código generado
Validación en la aplicaciónValores en una frontera, en tiempo de ejecuciónUn segundo punto de entrada: una tarea por lotes, un script, una migración
Prueba de arquitecturaEl grafo de dependenciasCarga por nombre en tiempo de ejecución; un paquete nuevo que la regla no nombra
Prueba de contrato y de esquemaLa compatibilidad de las interfacesUn consumidor que nadie registró
Integración continuaEl repositorio en un commitUna comprobación obligatoria que se omite y se informa como éxito
Barrera de integraciónQué comprobaciones tienen que pasar antes de integrarAdministradores, pushes directos, una protección que el plan de alojamiento no aplica
Pipeline de versionesEl artefacto que se promueveUna subida manual
Admisión en el despliegueLos objetos de la API enviados al clústerUna política de fallo que ignora los errores; objetos que existían antes de la política
Compilación de la publicaciónLa salida pública renderizadaContenido servido desde fuera de la compilación

Los perfiles implementan tres cadenas, cada una terminada en una transición detenida:

  • Una violación de arquitectura hace fallar una prueba de arquitectura, y la integración no se produce (Python y FastAPI).
  • Una incompatibilidad de contrato hace fallar una comprobación de contrato, y la versión no se publica.
  • Un centinela prohibido sintético en el sitio compilado hace fallar el fence de publicación, y la publicación no se produce (Python y FastAPI, cloud-native).

La integración continua es una superficie entre nueve, no la definición de un fence. GitHub Actions, GitLab CI y Jenkins pueden alojar uno; también un comprobador de tipos, una política de admisión o la compilación que renderiza un sitio.

Prueba de dientes

  • Introducir un defecto controlado y sintético.
  • Ejercitar el camino real de aplicación, no una prueba unitaria de la función que comprueba.
  • Verificar que falla, y que falla por el motivo plantado.
  • Restaurar el fixture exacto, y demostrarlo comparando un digest antes y después.
  • Verificar que vuelve a pasar.

Hay que hacer commit antes de plantar. Restaurar descartando cambios restaura el último commit, que en una rama de trabajo puede no ser el punto de partida, y entonces la prueba destruye el trabajo que debía proteger.

Modos de fallo

  1. El fence está en el camino equivocado

    Comprueba el repositorio, mientras que el contenido prohibido se inyecta en la compilación, en el despliegue o en tiempo de ejecución.

  2. Una comprobación obligatoria omitida se lee como éxito

    GitHub informa una tarea omitida como correcta, y una tarea omitida no impide una integración aunque sea una comprobación obligatoria. Una tarea obligatoria que depende de un fence fallido se omite, y la integración sigue adelante. Hay que exigir el propio fence, o una tarea de resumen que se ejecute siempre y falle salvo que todos los fences hayan pasado (el consejo del propio GitHub para comprobaciones que dependen de otras tareas).

  3. Consultivo por configuración

    continue-on-error, allow_failure: true en GitLab CI, un webhook de admisión cuya política de fallo ignora los errores, una restricción de Gatekeeper en dryrun o warn: cada uno convierte un fence en un consejo sin que nadie escriba la palabra.

  4. Nada comprobado, informado como limpio

    Una lista de patrones vacía, una selección de pruebas que no coincide con nada, un escaneo de un directorio vacío. El número de comprobaciones realmente ejecutadas pertenece al resultado, y cero es un fallo.

  5. El fence salta con trabajo legítimo y se desactiva

    La precisión mantiene vivo un fence. Una regla que coincide con texto corriente acabará desactivada en lugar de obedecida, y un fence desactivado es peor que ninguno, porque todo el mundo sigue creyendo que está ahí.

  6. Se publica la lista del propio fence

    Una lista pública de términos vigilados le dice a quien la lee exactamente qué se está protegiendo.

  7. Nunca se comprueba el estado existente

    Las comprobaciones de admisión y previas a la integración actúan sobre las peticiones a medida que se hacen, no sobre lo que ya existe. Kubernetes lo documenta para un plugin de admisión con todas las letras: cuando se añade un LimitRange, los pods que ya existen continúan sin cambios. Gatekeeper tiene una auditoría de los recursos existentes precisamente para ese hueco.

  8. El verde se lee como suficiente

    Una comprobación que pasa demuestra que la comprobación pasó. Si es la comprobación correcta es una cuestión de arquitectura que ninguna pipeline puede responder; véase la nota técnica.

Verificación

  • Prueba de arquitectura

    Pasa cuando: La regla de dependencias pasa sobre el árbol actual.

    Prueba de dientes: Se planta la importación prohibida: falla, y la barrera de integración la rechaza.

  • Prueba de contrato

    Pasa cuando: Los esquemas del productor y del consumidor son compatibles.

    Prueba de dientes: Se quita un campo obligatorio del productor: la comprobación falla y la tarea de versión no se ejecuta.

  • Prueba de extremo a extremo

    Pasa cuando: El fence de publicación escanea la salida compilada y pasa.

    Prueba de dientes: Se planta un centinela sintético en la salida: la compilación falla. Se retira, se compara el digest y la compilación pasa.

  • Prueba de despliegue o de admisión

    Pasa cuando: Se admite un objeto que sigue la regla.

    Prueba de dientes: Se envía uno que la incumple: rechazado, con el mensaje de la regla.

  • Evidencia manual

    Pasa cuando: Al integrar, una persona identificada confirma que cada fence se ejecutó en esta ejecución: el identificador de la ejecución y el número de comprobaciones ejecutadas quedan registrados, no recordados.

Realizaciones alternativas

  • Hooks de pre-commit. Respuesta rápida, y eludibles en la propia máquina de quien desarrolla: un consejo, no un fence.
  • Guardas en tiempo de ejecución. Detienen un estado prohibido en producción en lugar de antes. Necesarias donde el estado solo existe en tiempo de ejecución.
  • Barreras manuales. Una persona identificada ejecuta un procedimiento escrito. COADF informa de un control así honestamente como manual, nunca como aplicado.
  • Motores de políticas para reglas de infraestructura. ValidatingAdmissionPolicy de Kubernetes dentro del proceso, u Open Policy Agent con Gatekeeper, donde el estado prohibido es un objeto de la API.

Limitaciones

  • Un fence de texto no puede ver un mecanismo expresado mediante flujo de control, identificadores renombrados, flujo de datos o la geometría de un diagrama. Las barreras automatizadas son necesarias y no suficientes; la revisión humana sigue siendo necesaria.
  • Un fence detecta lo que se escribió para detectar, y nada más.
  • Que los fences pasen establece que los fences pasaron. No establece ningún estatus regulatorio.

Fuentes

COADF Engineering Companion 1.0 · no normativo · corresponde a COADF Core 2.2

Derechos de publicación reservados. Por ahora no se concede ninguna licencia pública para el COADF Engineering Companion 1.0 ni para sus ejemplos de referencia.

Estado de propiedad intelectual y de publicación