# Michelin B2C

###### tags: `process` `michelin` `onboarding`

## Caractéristiques du projet

**B2C experience** est un projet fonctionnant avec la stack technique suivante :
- [Git](https://git-scm.com/downloads)
- [Docker](https://www.docker.com/get-started)
- [Node.js](https://nodejs.org/en/)
- [Apostrophe CMS](https://apostrophecms.org/docs/)
- [MongoDB](https://docs.mongodb.com/manual/administration/install-community/)
- [ImageMagick](https://www.imagemagick.org/script/download.php)

### Git/Gitlab
L'équipe gère le versioning sur un serveur Gitlab. Elle y gère également la gestion des tickets, appelés _issues_. L'organisation est dite _agile_, ce qui implique une périodicité dans la communication et la résolution des tickets. Il y a donc des cycles :

[todo]

Voici une liste de procédure à suivre concernant les déploiements et commits :
- Lorqu'une **pipeline** est en cours d'exécution suite à un **push** et qu'on veut **refaire** un push, il faut d'abord **annuler** la pipeline en cours afin de ne pas surcharger la **CI** avec des pipelines inutiles.
- Lorsqu'une migration a été executée sur une pipeline mais que cette **migration** a été modifiée puis **poussée de nouveau**, il faut la relancer manuellement via l'interface de la **CI** avec le job `manual_restore_staging` dans le stage `deploy` qui va restaurer la collection `aposMigrations` de la base de données qui représente les migrations executées.
- Si l'**environnement** est prêt pour la **review fonctionnelle**, il faut lancer l'**environnement BFG** avec le job `build_review_bfg` dans le stage `build`.

Exemple d'URL vers un environnement de review :

        en-au-review-lab-b2c-ex-6eqshv-review.dev-dcadcx.michelin.fr
        ------------------------^^^^^^------------------------------
    Cette sous-partie change  <-'
    pour chaque environnement
    de review déployé.

Lorsque vous faites des changements sur un module externe et que vous voulez tester ces changements sur le projet, vous avez le choix entre 2 options :
- Faire un link du module localement sur votre container `apostrophe` :

$ cd /path-to-the-module
$ npm link
$ cd /app
$ npm link <module-name>

- Déployer une version beta :

$ npm version X.X.X-beta.X
$ git push
$ git push --tags

### Apostrophe
[Apostrophe CMS](https://apostrophecms.org/docs/) est un outil permettant de gérer des contenus et de développer son interface de gestion. Notre rôle en tant que développeur ici est donc de maintenir le comportement des modules [Apostrophe](https://apostrophecms.org/docs/) que nous développons vis-à-vis des utilisateurs finaux mais aussi vis-à-vis des éditeurs de contenu qui utilisent ces modules. Nous avons donc 2 types d'utilisateurs finaux à satisfaire.

### Les locales
[Apostrophe CMS](https://apostrophecms.org/docs/) gère également très bien le concept de **locale**. **B2C experience** se disperse en effet autour d'un très grand nombre de localités, avec non seulement des traductions correspondantes mais **avec pour chacune une expérience utilisateur différente**. L'utilisateur final américain de Michelin ayant des réflexes différents que l'utilisateur final russe par exemple. L'UX est donc configurable via [Apostrophe](https://apostrophecms.org/docs/).

### RAM
Prévoyez suffisamment de mémoire pour faire tourner le projet sur votre machine, 16go pour une expérience de devéloppement minimale, 32go pour une expérience optimale.
Pourquoi : Mongo requiert de par sa configuration au moins **50% - 1go** de la RAM de la machine sur laquelle il est hebergé. Voir la [documentation](https://docs.mongodb.com/v4.0/reference/configuration-options/#storage-options) à ce sujet. Vous pouvez configurer cela mais le comportement en sera potentiellement impacté au vu du volume de la base de données du projet.

## Slack
Le workspace Slack DCAD CX
- Quand on crée une **MR**, il faut la mentionner elle et les personnes **responsables** des différentes **reviews** dans le channel **b2c-core-team-reviews** avec ce template par exemple :

Resolve "<nom du ticket>" <lien du ticket>
Need <Corps de métier (FE, BE, FA, QA)> @<nom de la personne> @<nom de la personne>
Need <Corps de métier (FE, BE, FA, QA)> @<nom de la personne> @<nom de la personne>
Need <Corps de métier (FE, BE, FA, QA)> @<nom de la personne> @<nom de la personne>
Need <Corps de métier (FE, BE, FA, QA)> @<nom de la personne> @<nom de la personne>

(FE : Front-End, BE : Back-End, FA : Functional Analyst, QA : Quality Analyst)
- Quand on a un **imprévu** on doit mentionner les **horaires/dates impactées** dans le channel **b2c-core-team**.

## Vocabulaire
- **CX** : **C**ustomer e**X**perience
- **RC** : **R**elease **C**andidate.
- **AC** : **A**cceptance **C**riteria.
- **BV1** : **B**usiness **V**alue 1, signifie que l'utilisateur final est actuellement impacté par le ticket associé, devant donc être traité rapidement.
- **BV2** : ?
- **TV1** : **T**echnical **V**alue 1, dette technique à résoudre.
- **TS** : Tyre Selector, interface de recherche par critères progressifs
- **TSU** : Tyre Selector Universal, module dédié au **TS**, fait aussi référence à l'API de TyreDating utilisée par le module.
- **DL** : Dealer Locator
- **BFG** : BFGoodrich
- **RAR** : Ratings And Reviews
- **PLA** : Product Line Activity (Voiture, moto, vélo, ...)
- **Persona** : Equivalent Apostrophe de **PLA**
- **2W** : 2 Wheels (moto) (**PLA**/**persona**)
- **4W** : 4 Wheels (voiture) (**PLA**/**persona**)
- **Classic** : Voitures de collection (**PLA**/**persona**)
- **Authoring** : Edition d'un contenu sur l'interface Apostrophe.
- **DGAD** : Direction Groupe des Activités Digitales
- **TDP** : Tyre Details Page
- **TRP** : Tyre Results Page
- **DDP** : Dealer Details Page
- **DRP** : Dealer Results Page
- **SKU table** : Liste dans la **TDP** regroupant les tailles disponibles pour un pneu donné.

___

# VVV **A TRIER** VVV

## Outils

Pour bien démarrer il faut installer un certain nombre d'outils.

- Slack
Outils de chat collaboratif, utilisé pour nos rappel de réunion, nos demande de review ou questions techniques.
- télécharger
- [Linux](https://slack.com/intl/fr-fr/downloads/linux)
- [Mac](https://slack.com/intl/fr-fr/downloads/mac)
- rejoindre le worskpace dgad-slack.com et demander a votre accompagnateur de vous inviter dans les différentes chaîne de discussion

- IDE

A vous de choisir mais ici on utilise (presque) tous [VSCode](https://code.visualstudio.com/download).
Vous trouverez [ici](https://community.dgadteamdev.com/t/editors-plugins/139) une liste d'extensions conseillés pour VSCode

- Shell

Encore un fois c'est votre choix mais ici on aime bien [Oh My Zsh !](https://www.synbioz.com/blog/astuces_zsh_installer_et_comprendre_oh_my_zsh)

- Docker & Docker-Compose
Certaint d'entre nous utilise docker-compose pour lancer le projet en local.
Il faut donc installer Docker-CE pour votre OS
- [Ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/)
- [Debian](https://docs.docker.com/install/linux/docker-ce/debian/)
- [MacOS](https://docs.docker.com/docker-for-mac/install/)

Puis [docker-compose](https://docs.docker.com/compose/install/)

- MongoDB UI
Par exemple, [Robo3T](https://robomongo.org/download)

## TODO:

- local.js et /etc/hosts
- liens vers community
- Process de développement (git branch, issues tag, pipeline, reviews etc)
- npm run changelog
- npm link
- Expliquer datafeed datastream
- Expliquer TSU et TyreDating
- Expliquer Lizeo
- Liste liens tuto apostrophe
- [DCOS](http://dgaddevwemaster.trafficmanager.net/#/login?relativePath=/&_k=ygvzy6)
- [TyreDating](http://tsu-michelin-eu-dev.tyredating.com/do_login?username=dgad_FR_4W&password=dgad01)
- [Migration & Script](https://community.dgadteamdev.com/t/migration-and-database-scripts-general-guidelines/386)
- Diagrame d'action ?? Schema d'architecture du projet (Apos, TSU, DataFeed, Lizeo)