Policy Engine Aquila PRO V1

Le policy engine est le cœur de l’édition PRO. Il transforme une demande d’exécution en décision explicite.

Entrées du moteur

Le moteur reçoit, pour chaque demande, un payload JSON du type :

{
  "repository": "org/service-api",
  "branch": "main",
  "pipeline": "deploy-prod",
  "metadata": {
    "initiator": "github-actions",
    "run_id": "123456789",
    "environment": "production"
  }
}

Étapes d’évaluation

1. Contrôle de la licence
2. Vérification de la licence PRO via la clé publique RSA.

3. Si licence invalide ou expirée : décision refused avec raison licence_expired ou équivalent.

4. Résolution du projet

5. Recherche du projet et du pipeline correspondants dans projects.json.

6. Si aucun projet/pipeline trouvé : décision pouvant être refused (project_not_managed) ou accepted selon la politique choisie.

7. Application des règles globales

8. Vérification de l’état du freeze global.
9. Vérification des fenêtres horaires et du week‑end.

10. Si contrainte violée : décision refused (freeze_active, time_window_violation, etc.).

11. Application des règles locales

12. Contrôle de la branche (allowed_branches).
13. Contrôle du type de pipeline (ex. seuls certains pipelines autorisés en production).

14. Application du cooldown pour ce couple projet / pipeline / branche.

15. Construction de la décision

16. Attribution d’un statut : accepted ou refused.
17. Ajout d’une ou plusieurs raisons (reasons[]) permettant d’expliquer la décision.
18. Persistance de l’événement dans l’historique (en cas d’activation de l’historisation).

Sortie du moteur

Exemple de réponse en cas d’acceptation :

{
  "status": "accepted",
  "reasons": [],
  "project": "service-api",
  "pipeline": "deploy-prod",
  "branch": "main"
}

Exemple de réponse en cas de refus :

{
  "status": "refused",
  "reasons": [
    {
      "code": "cooldown",
      "message": "Cooldown actif pour ce pipeline sur cette branche."
    }
  ],
  "project": "service-api",
  "pipeline": "deploy-prod",
  "branch": "main"
}

Extension et maintenance

• Les règles sont principalement définies dans la configuration (global_policy.json, projects.json) et dans le code du policy engine.
• Toute évolution doit être testée :
• via des tests unitaires ciblés sur les scénarios critiques ;
• via une recette contrôlée sur un environnement de pré‑production.