Distribution EOLE » Qualification, Test et Intégration continue

Problèmes¶

Les tests actuels effectués depuis Jenkins ne sont pas :

• publiques
• reproductibles (permettre à une académie d’avoir son propre Jenkins)
• fiables

Un autre problème est la multiplacition des conditions dans le code en fonction des versions EOLE, par exemple :

• L’import de la base Zéphir 2.6.1 ne vérifie pas la présence d’erreur d’importation
• Des erreurs d’importation de configuration 2.3 sont présente
• De vraies erreurs d’importation existent et devraient être rapportées
  

  16:46:30             serveur ajouté aca.sphynx-basique-2.5.2 : 215
  16:46:30                   rc=0
  16:46:30                  msg=serveur 215 - erreur de sauvegarde de zephir.eol :
  16:46:30             La variable obligatoire 'x509_locality_name' de la famille 'Vpn_pki' n'est pas renseigne !
  16:46:30                Configuration: basique-2.6.0
  16:46:30                  Configuration: basique
  16:46:30                  Version: 2.6.0
  
  16:46:33             serveur ajouté aca.sphynx-basique-2.6.0 : 216
  16:46:33                   rc=0
  16:46:33                  msg=serveur 216 - erreur de sauvegarde de zephir.eol :
  16:46:33             La variable obligatoire 'x509_locality_name' de la famille 'Vpn_pki' n'est pas renseigne !
  16:46:33                Configuration: basique-2.6.1
  16:46:33                  Configuration: basique
  16:46:33                  Version: 2.6.1
  16:46:33             serveur ajouté aca.sphynx-basique-2.6.1 : 217
  16:46:33                   rc=0
  16:46:33                  msg=serveur 217 - erreur de sauvegarde de zephir.eol :
  16:46:33             La variable obligatoire 'x509_locality_name' de la famille 'Vpn_pki' n'est pas renseigne !
  

Il faudrait donc détecter les erreurs d’importation Zéphir mais pas celles pour les modules 2.3, ce qui complexifie le code de test et le rend plus difficile à maintenir.

Propositions¶

• Définir un cycle de développement pour les tests comme pour tout autre code
  • Des branches par version des produits testés
  • Une politiques de release des tests (branche master -> branche de production de la version X)
• Documenter l’écriture de tests (voir avec les méthodologies de développement)
• Revoir l’orchestrateur afin de le rendre diffusable

Demande initiale¶

Pour conforter le process Devops, il faudrait un Jenkins en "production" avec que des tests validés. Du coup les alertes seraient à traiter quotidiennement.

On conserve le jenkins actuel pour travailler sur les tests