La QA pour les nuls...

Coucou !

Voici un petit topo pour les dev' qui voudrait faire de la QA mais qui ont la flemme de se rappeler des commandes et opérations a faire.

Ce guide est destiné avant tout au dev' back souhaitant faire la QA du back. Je ne connais pas assez le front pour le faire. Certains commandes de préparation sont cependant communes au deux. Tout sera redige pour fonctionner sur un système Linux.

Ce guide sera illustré via la QA d'une PR de moi-meme : la PR 1549.

Tour du proprietaire

Commençons par regarder l'interface de github pour trouver les choses importantes…

Sur cette image j'ai tracé deux cadres importants :

• En rouge sont les informations de PR. Il doit impérativement y être présent le cartouche visible dans le fichier de contributing. En bonus toujours sympa des notes de QA peuvent-être la. Si le cartouche n'est pas la, signalez le dans les commentaires, la PR ne pourra pas être mergee sans.
• En bleu sont les infos de branches. A gauche est la branche cible de la PR. C'est la ou les changements atterriront après merge. A droite on a la branche source, celle du contributeur qui fait la PR et celle qui nous intéresse. Elle est au format [compte-GH-du-contrib]:[branche-du-contrib].

En haut nous trouvons aussi le titre et l'id de la PR (#1549 en l’occurrence)

Voila pour les présentations.

Profiter des instances externes:

Quelques uns de nos membres proposent de mettre à disposition des instances de test du code de zeste de savoir.

Pour tester une nouvelle fonctionnalité, il suffit de les contacter sur IRC, ils vous aideront avec plaisir.

Liste des possesseurs d'instances de test :

• artragis
• sandhose

Préparer la branche a QA

(fac.) Si vous n'avez jamais travailler avec le depot de ce contrib'

Si vous n'avez jamais travaille avec le depot de ce contributeur, il va falloit commencer par l'ajouter. Pour cela, une simple commande git vous le permet:

1

git remote add [nom-local] https://github.com/[contrib]/zds-site.git

Dans notre exemple nous ferions donc :

1

git remote add Eskimon https://github.com/Eskimon/zds-site.git

ou par le protocole git directement:

1

git remote add eskimon git://github.com/Eskimon/zds-site.git

La liste des depots ajoutes peut etre verifie avec:

1

git remote -v

Récupérer les branches du contrib'

Nous allons maintenant recupererer les references des branches du contributeur qui nous interesse via la commande fetch

1

git fetch Eskimon

Switcher sur la branche a QA-tiser

Maintenant que nous avons les references, nous pouvons passer a la branche de travail. La syntaxe est la suivante :

1

git checkout -b [nom-local] [contrib]/[branche-contrib]

Je vous propose la convention suivante, le nom local est "QA_xxxx" avec xxxx representant l'id de la PR a tester. Dans notre cas nous ferons donc :

1

git checkout -b QA_1549 Eskimon/fix_1518

Vous serez alors automatiquement place dans votre nouvelle branche QA_1549 qui pointe sur la branche fix_1518 du dépôt d'Eskimon.

Avoir un environnement de travail propre

Une fois la branche recuperee, on peut avoir besoin de partir sur un environnement de travail propre dans certains cas. Voyons comment tout nettoyer et reconstruire.

Nettoyer et repartir sur de bonne bases _(ahah)

Pour avoir un environnement propre nous allons faire les opérations suivantes :

1. Virer la base de donnees
2. Virer les dossiers des tutos / articles / media
3. Reconstruire la BDD et charger ses donnees de tests

Et voici en commande comment faire (detail dans la doc du site)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# on supprime tout !
rm base.db
rm -rf tutorial-*
rm -rf article*
rm -rf media/

# On met a jour les dépendances si besoin
sudo pip install --upgrade -r requirements.txt

# on reconstruit la bdd en une commande
python manage.py syncdb; python manage.py migrate; python manage.py loaddata fixtures/*.yaml

Une fois cela fait, le site doit pouvoir être lancé et fonctionner via

1

python manage.py runserver

Minimum syndical si on ne veut pas nettoyer

Si vous pensez que votre base de donnees et environnement est assez propre, voici les commandes minimales a faire avant de travailler:

1
2
3
4
5

# On met a jour les dépendances si besoin
sudo pip install --upgrade -r requirements.txt

# on met a jour la bdd si du nouveau est la
python manage.py migrate;

Mettre a jour sa branche de travail

Si un contributeur a fait de nouveau commit, un simple git pull dans la branche de travail fera l'affaire.

Cool ce petit topic ! o/

Mmh, juste un truc à apporter pour la config des remote. Le "protocol git", ce n'est pas ça, c'est git://github.com/Eskimon/zds-site.git, car celle que tu propose (git@github.com:Eskimon/zds-site.git) est l'accès ssh (lecture + écriture). Or, mis à par toi (et d'éventuels contrib que t'aurai ajouté dans tes settings), personne ne peut cloner / accéder par cette url.

Juste un FYI, mais bon topic.

Arf, oui my bad, je suis passe sur mon propre repo et copier/coller une adresse qui du coup devrait etre adapte a moi meme. je corrige !

Accessoirement, pour éviter de fetch les 500 branches du repo distant, on peut faire ça :

1

git fetch <remotename> <remote branch>:refs/remotes/<remotename>/<local branch>

Par exemple :

1

git fetch Eskimon fix_1518:refs/remotes/Eskimon/fix_1518

Aussi, vu que quand on QA on se place dans une position de lecture seule, inutile de créer une nouvelle branche. On peut tout simplement switcher sur la branche dans les remotes. Au lieu de :

1

git checkout -b [nom-local] [contrib]/[branche-contrib]

On fera :

1

git checkout [contrib]/[branche-contrib]

Ca évite encore une fois d'avoir 500 branches en local et d'être obligé de les supprimer après.

Sauf erreur de ma part :

1
2

# on reconstruit la bdd en une commande
python manage.py syncb; python manage.py migrate; python manage.py loaddata fixtures/*.yaml

Il y a une erreur, c'est syncdb et non syncb

Une petite faute s'est glissée dans cette QA pour les nuls, les commandes sont

1

git remote add ...

Et pas

1

git add remote add ...

Sinon pour ce topic.

J'ai fait un petit script Bash/Shell pour ceux qui veulent.

La commande $ bash zds-cleaner.sh nettoie et prépare ZdS dans la branche Git actuelle

La commande $ bash zds-cleaner.sh remote/branch nettoie et prépare ZdS dans la branche Git branch de remote

luve you guy. Je pense que ça peut être largement ajouté dans le dépôt principal.

Je ne pense pas que ça soit une bonne idée, puis faudrait étoffer le script parce qu'il est basique en l'état.

Il faut changer sudo pip install --upgrade -r requirements.txt par pip install --user --upgrade -r requirements.txt qui me semble plus adapté.

Voir utiliser un virtualenv, non ?

1. Virer la base de donnees
2. Virer les dossiers des tutos / articles / media
3. Reconstruire la BDD et charger ses donnees de tests

Et voici en commande comment faire (detail dans la doc du site)

1 2 3 4 5 6 7 8

# on supprime tout ! rm base.db rm -rf tutorial-* rm -rf article* rm -rf media/ # On met a jour les dépendances si besoin sudo pip install --upgrade -r requirements.txt

J'ai aucun des dossiers à supprimer ci-dessus… Est-ce normal ou ce message n'est plus à jour ?

Aussi je pense qu'il faut rajouter requirements-dev.txt, et comme dit ci-dessus, le sudo est inutile, soit :

1

pip install --upgrade -r requirements.txt -r requirements-dev.txt

J'ai aucun des dossiers à supprimer ci-dessus… Est-ce normal ou ce message n'est plus à jour ?

C'est normal si tu n'as jamais lance le site avant et que tu as 0 tutos/articles sur ta version local.

Oui faut que je mette a jour cette histoire de requirement qui a change de nom !

Ce n’est pas plus rapide de faire : git fetch upstream pull/1549/head:readability ?