Archive #17744
Mis à jour par Daniel Dehennin il y a environ 7 ans
h3. 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 project:zephir 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
<pre>
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 !
</pre>
Il faudrait donc détecter les erreurs d’importation project:zephir mais pas celles pour les modules 2.3, ce qui complexifie le code de test et le rend plus difficile à maintenir.
h3. 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":https://dev-eole.ac-dijon.fr/doc/devnotebook/)
* Revoir l’orchestrateur afin de le rendre diffusable
h3. 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 un le jenkins actuel pour travailler sur les tests
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 project:zephir 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
<pre>
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 !
</pre>
Il faudrait donc détecter les erreurs d’importation project:zephir mais pas celles pour les modules 2.3, ce qui complexifie le code de test et le rend plus difficile à maintenir.
h3. 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":https://dev-eole.ac-dijon.fr/doc/devnotebook/)
* Revoir l’orchestrateur afin de le rendre diffusable
h3. 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 un le jenkins actuel pour travailler sur les tests