C'est tout le framework du Pass Culture!

Il vous faudra une machine UNIX.

Installer:

• docker
• docker-compose
• yarn voir le README dans le dépot https://github.com/betagouv/pass-culture-browser/

Mais spécialement, en plus pour macosx:

• brew install coreutils

Enfin pour tout le monde:

./pc symlink

puis

./pc symlink
pc install

Pour vérifier les tests:

pc test-backend

Pour avoir une database de jeu:

pc sandbox -n industrial

Pour lancer l'API:

pc start-backend

Pour lancer l'appli webapp:

pc start-webapp

Pour lancer le portail pro:

pc start-pro

Pour reconstruire l'image docker sans cache

pc rebuild-backend

Pour effacer la base de données complétement, et relancer tous les containers:

pc restart-backend

Si vos serveurs de dev tournent, et que vous souhaitez juste effacer les tables de la db:

pc reset-sandbox-db

Si vous voulez juste enlever les recommandations et bookings crées en dev par votre navigation:

pc reset-reco-db

Vous pouvez passer toutes les cli classiques d'alembic comme ceci:

pc alembic upgrade

Pour tester le backend:

pc test-backend

Pour tester le frontend:

pc test-frontend

Pour tester la navigation du site web

pc -e production test-cafe-webapp -b firefox

Exemple d'une commande test en dev sur chrome pour un fichier test particulier:

pc test-cafe-pro -b chrome:headless -f signup.js

Pour restorer un fichier de dump postgresql (file.pgdump) en local:

pc restore-db file.pgdump

Pour anonymiser les données après restauration, et changer le mot de passe pour tout les users :

./api/scalingo/anonymize_database.sh -p PASSWORD

Afin de naviguer/tester différentes situations de données, il existe dans api des scripts permettant d'engendrer des bases de données "sandbox".

La plus conséquente est l'industrial, elle se créée via la commande:

pc sandbox -n industrial

Cette commande faite, il y a alors deux moyens pour avoir les email/mots de passe des utilisateurs sandbox :

• on peut utiliser la commande sandbox_to_testcafe qui résume les objets utilisés de la sandbox dans les différents testcafés. Si on veut avoir tous les utilisateurs des tests pro_07_offer dans l'application pro, il faut faire:

  pc sandbox_to_testcafe -n pro_07_offer

• on peut utiliser un curl (ou postman) qui ping directement le server à l'url du getter que l'on souhaite:

curl -H "Content-Type: application/json" \
     -H "Origin: http://localhost:3000" \
     GET http://localhost:80/sandboxes/pro_07_offer/get_existing_pro_validated_user_with_validated_offerer_validated_user_offerer_with_physical_venue

Il est important que votre serveur API local tourne.

Pour les développeur.ses, quand vous écrivez un testcafé, il faut donc la plupart du temps écrire aussi un getter côté api dans sandboxes/scripts/getters/<moduleNameAvecleMêmeNomQueLeFichierTestcafe>, afin de récupérer les objets souhaités dans la sandbox.

Pour l'application WEBAPP, vous pouvez naviguer avec ce user toujours présent:

email: [email protected]

Pour l'application PRO, vous pouvez naviguer en tant qu'admin avec:

email: [email protected]

Ou en tant qu'user avec :

email: [email protected]

Le mot de passe est toujours : user@AZERTY123

(Ces deux utilisateurs existent également pour le 97, pour les utiliser, il suffit de remplacer 93 par 97)

La politique de tagging de version est la suivante :

• On n'utilise pas de semantic versioning
• On utilise le format I.P.S
  • I => incrément d'Itération
  • P => incrément de fix en Production
  • S => incrément de fix en Staging

• Je livre une nouvelle version en staging en fin d'itération n°20 => 20.0.0
• Je m'aperçois qu'il y a un bug en staging => 20.0.1
• Le bug est corrigé, je livre en production => 20.0.1
• On détecte un bug en production, je livre en staging => 20.1.0
• Tout se passe bien en staging, je livre en production => 20.1.0
• On détecte un autre bug en production, je livre en staging => 20.2.0
• Je m'aperçois que mon fix est lui-même buggé, je relivre un fix en staging => 20.2.1
• Mes deux fix sont cette fois OK, je livre en production => 20.2.1

Pour poser un tag sur une version :

S'assurer d'avoir bien commité ses fichiers. Checkout de master sur pass-culture-main, pass-culture-api, pass-culture-webapp et pass-culture-pro.

pc -t I.P.S tag

La seule branche devant être taguée de cette façon est master. Pour les hotfixes, voir plus bas.

Le fichier version.txt de l'API est mis à jours ainsi que le package.json de Webapp et Pro. Le tag est posé sur les branches locales checkout (de préférence master): Api, Webapp et Pro. Elles sont ensuite poussées sur le repository distant. Les tests sont enfin joués et on déploie sur Testing.

Pour tagguer les hotfixes, commencer par se placer sur la dernière version déployée en production ou en staging à l'aide d'un git checkout vI.P.S sur chacun de projets. En effet nous voulons déployer uniquement ce qui est en Prod + nos commits de hotfix.

Une fois le tag checked-out, commiter le fix du bug puis lancer la commande de création de branches de hotfixes et de tag pour chacun des projets :

pc -t I.P(+1).S(+1) tag-hotfix.

Une fois les tests de la CI passés, on peut déployer ce tag.

Le tag déployé, il faut reporter les commits des hotfixs sur les branches masters des différents projets pour qu'il soient présent lors des prochaines livraison, sinon il seront écrasés. Il faut aussi penser à supprimer les branches de hotfixs.

Pré-requis : installer jq

En premier lieu:

• bien vérifier qu'on a, en local, main et tous les submodules (api, pro, webapp) à jour par rapport à master
• de là on peut poser un tag pc -t I.P.S. tag (pour savoir le tag précédent, il suffit de faire un git tag dans pass-culture-main)
• se rendre sur CircleCI pour vérifier qu'il y a un job lancé par submodule (api, pro, webapp), ainsi que main qui a également lancé autant de jobs qu'il y a de submodules,
• réaliser le déploiement lorsque les tests de chaque submodule sont bien verts

Pour déployer une nouvelle version, par exemple en staging: (Attention de ne pas déployer sur la production sans concertation !)

pc -e <datalake|staging|production|demo|integration> -t I.P.S deploy

Par exemple pour déployer la version 3.0.1 en demo :

pc -e demo -t 3.0.1 deploy

A la fin de l'opération, une fenêtre de votre navigateur s'ouvrira sur le workflow en cours.

Après avoir livré en production, ne pas oublier de livrer ensuite sur les environnements de demo, d'integration et de datalake.

Pour publier une version de pass-culture-shared sur npm

cd shared
npm adduser
yarn version
yarn install
npm publish

Puis sur webapp et/ou pro, mettre à jour la version de pass-culture-shared dans le fichier package.json :

yarn add [email protected]
git add package.json yarn.lock

avec x.x.x, étant la nouvelle version déployée sur pass-culture-shared.

pc -e <testing|staging|production> psql

ou

pc -e <testing|staging|production> pgcli

pc psql

ou

pc pgcli

pc start-metabase

Lance Metabase et une base de données contenant les données sandbox du produit. Pour supprimer les volumes avant de lancer Metabase, utiliser la commande :

pc restart-metabase

L'url pour aller sur Metabase en local est : http://localhost:3002/

Pour configurer Metabase, il suffit de créer un compte admin, puis de se connecter à la base produit. Pour cela, il faut renseigner les informations suivantes :

• Host : pc-postgres-product-metabase
• Port : 5432
• Database name : pass_culture
• Database username : pass_culture
• Database password : passq

pc -e <testing|staging|production> python

Il est également possible d'uploader un fichier dans l'environnement temporaire grâce à la commande suivante :

pc -e <testing|staging|production> -f myfile.extension python

L'option -f est également disponible pour la commande bash :

pc -e <testing|staging|production> -f myfile.extension bash

En local :

pc access-db-logs

Sur les autres environnements :

pc -e <datalake|testing|staging|production> access-db-logs

Pour toutes les commandes suivantes, vous devez disposer des secrets de connexion.

Pour lister le contenu d'un conteneur spécifique :

pc list_content --container=storage-pc-staging

Pour savoir si une image existe au sein d'un conteneur :

pc does_file_exist --container=storage-pc-staging --file="thumbs/venues/SM"

Pour supprimer une image au sein d'un conteneur :

pc delete_file --container=storage-pc-staging --file="thumbs/venues/SM"

Pour faire un backup de tous les fichiers du conteneur de production vers un dossier local :

pc backup_prod_object_storage --container=storage-pc --folder="~/backup-images-prod"

Pour copier tous les fichiers du conteneur de production vers le conteneur d'un autre environnement :

pc copy_prod_container_content_to_dest_container --container=storage-pc-staging

Vérifier déjà que l'un des admins (comme @arnoo) a enregistré votre adresse ip FIXE (comment connaitre son adresse ip? http://www.whatsmyip.org/)

pc -e <testing|staging|production> ssh

ssh to the prod server

cd ~/pass-culture-main && pc dump-prod-db-to-staging

Then connect to the staging server:

cd ~/pass-culture-main
cat "../dumps_prod/2018_<TBD>_<TBD>.pgdump" docker exec -i docker ps | grep postgres | cut -d" " -f 1 pg_restore -d pass_culture -U pass_culture -c -vvvv
pc update-db
pc sandbox --name=webapp

Renseigner la variable d'environnement PC_GPG_PRIVATE. Puis lancer la commande suivante :

pc install-private

Une fois connecté:

cd /home/deploy/pass-culture-main/ && pc update-db

Pour obtenir un certificat et le mettre dans le nginx (remplacer par le domaine souhaité, qui doit pointer vers la machine hébergeant les docker)

docker run -it --rm -v ~/pass-culture-main/certs:/etc/letsencrypt -v ~/pass-culture-main/certs-data:/data/letsencrypt deliverous/certbot certonly --verbose --webroot --webroot-path=/data/letsencrypt -d <domaine>

Puis mettre dans le crontab pour le renouvellement :

docker run -it --rm -v ~/pass-culture-main/certs:/etc/letsencrypt -v ~/pass-culture-main/certs-data:/data/letsencrypt deliverous/certbot renew --verbose --webroot --webroot-path=/data/letsencrypt

yarn global add cordova-cli

cd webapp && cordova run ios

Vous pouvez utiliser une ptite config ngrok pour l'api et la webapp par exemple:

cd webapp/ && yarn run ngrok

Ensuite il faut lancer l'application configurée avec ces tunnels:

pc start-browser-webapp -t

Vous pourrez alors utiliser l'url ngrok webapp pour dans votre navigateur android.

Pour déployer une nouvelle version phonegap (par default c'est en staging)

pc build-pg

Les tests requièrent d'avoir un environnement spécifique sur Scalingo, ici pass-culture-dev-perf, comportant notamment une base utilisateur. Pour la remplir, il faut jouer les sandboxes industrial et activation.

Execution des sandboxes sur le conteneur :

scalingo -a pass-culture-dev-perf run 'PYTHONPATH=. python scripts/pc.py sandbox -n industrial'
scalingo -a pass-culture-dev-perf run 'PYTHONPATH=. python scripts/pc.py sandbox -n activation'

Ensuite, lancer le script d'import des utilisateurs avec une liste d'utilisateurs en csv prédéfinie placée dans le dossier artillery sous le nom user_list. On passe en paramètre un faux email qui ne sera pas utilisé.

scalingo -a pass-culture-dev-perf run 'ACTIVATION_USER_RECIPIENTS=<email> python scalingo/import_users.py user_list' -f user_list

Un exemple de csv utilisateur user_list :

1709,Patricia,Chadwick,[email protected],0155819967,Drancy (93),16282,2001-05-17,secure_password

Pour lancer les tests de performance il faut installer le logiciel artillery : npm install -g artillery et son plugin metrics-by-endpoint : npm install artillery-plugin-statsd, puis se munir du fichier csv contenant les users valides.

Puis se placer dans le dossier artillery et lancer la commande :

artillery run scenario.yml -o reports/report-$(date -u +"%Y-%m-%dT%H:%M:%SZ").json

Un rapport des tests daté sera généré dans le sous-dossier reports (qui doit être crée).