Article1-Connect
Gestion centralisée des utilisateurs et Single Sign-On (SSO)
Introduction
Le projet Article1-Connect a pour objectif de centraliser autant que possible la gestion des utilisateurs des applications d'Article1. Ceci comprends notamment :
Documentation
Organisation du développement
Le projet est organisé en monorepository. Il se décompose en 2 grandes catégories : * L'API qui comprends plusieurs "micro-services" situés dans le dossier back * L'interface utilisateur dont le code est présent dans front.
Cette organisation a pour but de condenser le code modifié dans une seule branche et que tout le code nécessaire à la validation et au déploiement d'une fonctionnalité soit présent au même endroit et non dispersé dans des projets Gitlab différents pouvant induire des erreurs de versions.
Développement
La gestion par tickets est assuré par le client sur JIRA. Toute nouvelle branche doit être créée à partir de la branche STAGING et comporter l'identifiant du ticket Jira auquel le développement se réfère. Ainsi des informations de Gitlab peuvent être retranmisent dans le ticket, permettant à toutes les parties prenantes du projet de s'y retrouver plus rapidement et de voir en un coup d'œil à quel étape se trouve le développement.
#Exemple
git checkout -b ACDR-1_Initial_commit origin/staging
Vous avez également la possibilité de créer la branche directement depuis Jira grâce à l'application Gitlab qui est déjà intégrée.
Installation du projet
Docker
Installation
https://www.docker.com/products/docker-desktop/
Lancement
Travail avec des conteneurs similaires sur un/des projet(s) différent(s)
// .env à la racine du projet
FRONT_DOCKER_EXPOSED_PORT=8082
POSTGRES_DOCKER_EXPOSED_PORT=5432
API_DOCKER_EXPOSED_PORT=3000
RABBITMQ_INTERFACE_DOCKER_EXPOSED_PORT=15672
RABBITMQ_DOCKER_EXPOSED_PORT=5672
MAILCATCHER_DOCKER_EXPOSED_PORT=1025
MAILCATCHER_INTERFACE_DOCKER_EXPOSED_PORT=1080
Si vous êtes sous Linux, renseigner cela dans les paramètres des conteneurs de vos autres projets qui souhaitent accéder à RabbitMQ depuis un autre network
extra_hosts:
- "host.docker.internal:host-gateway"
Commande pour un démarrage du service
cd <to_a1connect_directory>
docker-compose -p a1connect up -d
Connexion bash
# Liste des conteneurs lancés
docker ps
# Connexion
docker exec -it <container_name> bash
Problèmes connus
Lorsque l'api (port 3000) ne répond pas, relancer a1connect-api
docker stop a1connect-api
docker start a1connect-api
Interfaces utilisateurs
Rabbit MQ
http://localhost:15672
username: guest
password: guest
Mailcatcher
http://localhost:1080
Docker desktop
Base de données
La base de données ne nécessite aucune manipulation. Les migrations sont lancées automatiquement à chaque lancement de la commande Docker.
pgAdmin
Le conteneur pgAdmin n'a pas été ajouté dans le fichier docker-compose afin d'éviter qu'il soit créé en staging ou production. C'est une question de sécurité et empécher de potentielles failles.
Étapes de connexion : - Créer un utilisateur local pour pgAdmin - Clic droit sur "Servers" - Sélectionner "Nouveau" - Dans l'onglet "Nom", donner un nom au serveur de base de données - Dans l'onglet "Connexion", renseigner les informations ci-dessous
hostname : localhost
port : 5432
username : postgres
password : <docker-compose-file_postgres-password>
- Cliquer sur "Enregistrer"
Trouver les données :
Servers
|- nom_donné
|- base de données
|- CdR_staging
|- Schemas
|- API_Schema
|- Tables
Schema de données
Staging et Production
La préproduction et la production sont déployées sur un cluster Kubernetes hébergé par le préstataire AdmanTIC. La CI/CD s'occupe de build, tester et déployer les images Docker des 2 environnements sur le Registre de conteneurs du projet. Il n'y a par conséquent qu'à merger la branche de développement vers staging pour que les développements puisse être testés par le client et, après validation par ce dernier, merger la branche staging dans la branche main pour que les modifications soient en production.
La page des Pipelines permet de visualiser l'état des tâches effectuées et également d'avoir accès aux logs de chacune en cas d'erreur.
Les variables d'environnements de l'interface utilisateur doivent être définies dans les Paramètres du projet pour qu'elles soient prises en compte lors de la compilation du code au moment de l'étape du build. Certaines portent le même nom mais dépendent d'environnements différents afin que l'appel de la variable dans le fichier de CI soit le même, mais qu'en fonction de la branche pour laquelle le pipeline s'est déclenché, les bonnes valeurs soient implémentées.