Suivi — Administration système Pouvoir tester les mises à jour de maintenance

#2002 Posté par  (site Web personnel) . État de l’entrée : ouverte. Assigné à Adrien Dorsaz. Licence CC By‑SA.
Étiquettes : aucune
0
30
mai
2021

Hello,

Je crée cette entrée de suivi, parce que les développeurs et administrateurs systèmes n'ont pas de moyen pour savoir si un changement de dépendance (npm, ruby, debian) casse les fonctionnalités du site.

Sur Github, on a le robot "dependabot" qui cherche les mises à jour nécessaire des dépendances et propose des pull request pour les mettre à jour.

Mais, sans aucun tests, il est impossible de prendre la décision de fusionner les merge request.

Si on réintroduit les tests, on pourra en plus utiliser "Github Action" pour les exécuter automatiquement à chaque nouvelle demande de mise à jour. Ça permettra de réduire la barrière pour les nouveaux contributeurs: ils pourront avoir un aperçu si leur modification casse le site.

  • # Comment débuter ?

    Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

    Préambule: c'est moi qui est ouvert l'entrée de suivi, j'ai oublié de me connecter avant :)

    Comme je ne connais pas moi-même rails, j'ai cherché la manière de faire avec Rails.

    D'après son tutorial, rails a déjà son propre framework de test: https://guides.rubyonrails.org/testing.html

    J'ai donc commencé par chercher dans l'historique git et j'ai découvert qu'il y avait des tests dans le dossier test (dossier utilisé par rails, justement).

    Puis, ce dossier a été supprimé en faveur du framework de test rspec2 qui avait ses tests dans le dossier spec.

    Depuis le commit eaf8458858ab4fff7dffd86ae396c64f0d76e753, on a supprimé tous les tests.

    Avant de pouvoir commencer, j'ai donc plusieurs questions:

    • pourquoi est-ce que l'on est passé au framework rspec2 ?

    • le changement de framework a était fait il y a très longtemps (en 2010), si je recommence de zéro, on pourrait à nouveau utiliser le framework de rails ?

      • Je préférerais utiliser celui de rails, car le tutoriel de rails est plutôt complet (pour les autres aspects du framework en tout cas) et comme ça on peut diriger les bonnes volontés sur leur tutoriel.
    • est-ce que les tests qui étaient dans le dossier spec étaient vraiment trop cassé ? est-ce que je devrais recommencer de zéro ? étaient-ils utiles ?

    • [^] # Re: Comment débuter ?

      Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

      Préambule: c'est moi qui est ouvert l'entrée de suivi, j'ai oublié de me connecter avant :)

      ça c'est la partie facile, réaffectée :).

    • [^] # Re: Comment débuter ?

      Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

      pourquoi est-ce que l'on est passé au framework rspec2 ?

      C'était une autre époque. Aujourd'hui, le choix entre rspec et le framework de tests officiel de Rails est principalement une question de goûts (la syntaxe n'est pas la même), mais les deux sont très complets et ont copié de l'autre tout ce qu'il y avait d'intéressant.

      si je recommence de zéro, on pourrait à nouveau utiliser le framework de rails ?

      Oui, pas de soucis.

      est-ce que les tests qui étaient dans le dossier spec étaient vraiment trop cassé ? est-ce que je devrais recommencer de zéro ? étaient-ils utiles ?

      Les tests n'étaient pas très cassés, j'aurais pu les corriger en moins d'une heure. Par contre, ils n'étaient pas vraiment utiles. Je ne pense pas qu'ils n'aient jamais trouvé le moindre bug. La couverture de tests était vraiment très faible et c'était surtout les mêmes pages que je regardais quand je développais des nouvelles fonctionnalités. Si la page d'accueil casse, je m'en rendais compte très très rapidement, sans avoir besoin de tests automatisés pour ça.

      Mais, sans aucun tests, il est impossible de prendre la décision de fusionner les merge request.

      Pour info, même avec des tests, je pense que ça reste compliqué de prendre la décision. Il faut avoir une bonne couverture de tests pour que ça aide et, pour ça, il faut y passer beaucoup de temps à écrire des tests, temps qui serait probablement plus utile ailleurs. Et il faut aussi faire très attention à la version de Ruby : on a une version de Ruby assez ancienne en prod et j'ai plusieurs fois dû faire des reverts à cause de ça.

      • [^] # Re: Comment débuter ?

        Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

        Merci pour toutes ces informations, je vais voir ce que j'arrive à faire.

        Et il faut aussi faire très attention à la version de Ruby : on a une version de Ruby assez ancienne en prod et j'ai plusieurs fois dû faire des reverts à cause de ça.

        Est-ce que la version de Ruby est plus vieille que celle disponible sur Debian Stretch (version 2.3.3) ?

        Je comptais utiliser les images Docker que j'ai configuré et qui travaillent justement avec Debian Stretch pour l'instant.

        • [^] # Re: Comment débuter ?

          Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

          Est-ce que la version de Ruby est plus vieille que celle disponible sur Debian Stretch (version 2.3.3) ?

          C'est bien cette version.

          linuxfr@prod:~$ ruby -v
          ruby 2.3.3p222 (2016-11-21) [x86_64-linux-gnu]
          

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.