Doodle DevOps

Ce dépôt contient une application de type Doodle composée d’un backend Quarkus, d’un frontend Angular et de services annexes déployés via Docker Compose.

Le projet a été réalisé dans un contexte DevOps avec deux objectifs principaux :

• corriger les problèmes bloquants pour faire fonctionner l’application en local ;
• ajouter des pratiques DevOps autour de l’intégration continue, de l’analyse statique et de l’automatisation des tests.

Contexte du projet

Le travail demandé consistait à partir d’une base déjà existante, à corriger les problèmes bloquants, puis à renforcer le projet avec des outils et pratiques de DevOps. L’objectif était de rendre le projet fonctionnel en local, puis d’ajouter des étapes d’automatisation pour garantir la qualité et la maintenabilité du code.

Équipe

• Khawla Khallouq
• Niloy Roy
• Othniel Kombo
• Dominique Behi

Plan de travail

1. Préparer l’environnement local et faire fonctionner l’application existante.
2. Corriger les problèmes bloquants côté backend, frontend et services Docker.
3. Mettre en place l’automatisation des tests pour valider les évolutions.
4. Ajouter l’intégration continue pour lancer les vérifications à chaque changement.
5. Configurer l’analyse statique avec SonarQube et exploiter les rapports de qualité.

Architecture générale

Le projet est organisé en plusieurs services :

• api/ : backend Quarkus exposant les API métier ;
• front/ : application Angular utilisée comme interface utilisateur ;
• docker-compose.yml : orchestration locale des services ;
• autres services : base de données MySQL, Etherpad, messagerie SMTP et SonarQube.

Prérequis

Avant de lancer le projet, il faut disposer au minimum de :

• Java 11 ;
• Maven ;
• Docker et Docker Compose ;
• Node.js et npm pour le frontend Angular.

Lancer le projet en local

Depuis la racine du dépôt :

docker compose up -d

Les services principaux deviennent alors accessibles aux adresses suivantes :

• frontend : http://localhost:4200
• backend : http://localhost:8080
• Etherpad : http://localhost:9001
• SonarQube : http://localhost:9000

Pour arrêter l’environnement :

docker compose down

2. Corriger les problèmes bloquants côté backend, frontend et services Docker

Le projet initial présentait plusieurs problèmes empêchant son bon fonctionnement. Nous avons identifié et corrigé les principaux blocages suivants :

• Le lien entre le frontend et le backend était mal configuré.
• Le docker-compose n'était pas à jour avec les certaines versions des services.

On a corrigé ces problèmes en ajustant les configurations, et on a cré un docker-compose.yml qui lance le backend et le frontend correctement, avec tous les services nécessaires.

3. Mettre en place l’automatisation des tests

Tests unitaires

Nous avons ajouté des tests unitaires pour les composants critiques du backend. Ces tests sont écrits avec JUnit et Mockito pour assurer la couverture des fonctionnalités clés.

4. Implémentation de l’intégration continue

Configuration de la pipeline CI avec GitLab CI

Nous avons mis en place une pipeline GitLab CI pour automatiser le build, les tests et le déploiement de notre projet Doodle DevOps. Le dépôt contient un backend Quarkus dans api/ et un frontend Angular dans front/, donc la pipeline est séparée pour couvrir ces deux parties.

Objectif

Cette pipeline nous permet de vérifier automatiquement que le backend compile, que les tests passent, que le frontend se construit correctement, et que le déploiement peut être déclenché selon la branche.

Prérequis à installer en local

Pour mettre en place et tester la pipeline en local, nous avons besoin de quelques outils de base :

• Git : pour cloner le dépôt et envoyer les changements.
• Docker et Docker Compose : pour lancer les services nécessaires au projet et tester l’environnement.
• Java 11 et Maven : pour le backend Quarkus dans api/.
• Node.js et npm : pour le frontend Angular dans front/.
• GitLab Runner : seulement si nous voulons exécuter la pipeline en local avec un runner installé sur notre machine.

Fichier de pipeline

La configuration est placée à la racine du dépôt dans le fichier .gitlab-ci.yml. GitLab détecte automatiquement ce fichier et lance les jobs à chaque push ou merge request sur les branches prévues.

Structure de la pipeline

Nous avons organisé la pipeline en trois stages :

• build : pour compiler le backend et le frontend.
• test : pour lancer les tests automatisés.
• deploy : pour déployer l’application sur l’environnement de développement ou de production.

Étapes de la pipeline

1. Build du backend

Nous utilisons une image Maven avec Java 11 pour compiler l’API Quarkus. Le job se place dans api/ puis lance mvn clean compile -DskipTests afin de vérifier que le code compile sans exécuter les tests à ce stade.

2. Build du frontend

Pour le frontend, nous utilisons une image Node.js. Le job se place dans front/, exécute npm ci, puis lance npm run build -- --configuration production pour produire l’application Angular.

3. Tests du backend

Nous lançons ensuite les tests unitaires du backend avec mvn test. Les rapports JUnit sont récupérés comme artefacts pour faciliter la lecture des résultats dans GitLab.

4. Tests du frontend

Nous lançons aussi les tests du frontend avec npm run test. Dans notre pipeline, cette étape est tolérante en cas d’échec partiel, car certains environnements Angular nécessitent des adaptations pour exécuter les tests headless.

5. Déploiement

Enfin, nous avons deux jobs de déploiement : un pour la branche develop et un pour master. Le déploiement s’appuie sur Docker et docker-compose.yml pour lancer les services de l’application.

La logique GitLab CI implémentée

stages:
  - build
  - test
  - deploy

La pipeline est déclenchée sur merge_requests, main, develop et master pour les jobs de build et de test, puis sur develop ou master pour les jobs de déploiement.

Cache et artefacts

Nous avons ajouté du cache pour accélérer les exécutions : Maven conserve ses dépendances dans api/.m2/repository, et Node.js conserve front/node_modules/. Nous avons aussi ajouté des artefacts pour garder les dossiers target/, dist/ et les rapports de tests pendant un certain temps.

5. Analyse Statique avec SonarQube

Étapes pour configurer SonarQube avec le projet Maven

1. Démarrer l’environnement Docker

Il faut lancer les services :

docker compose up -d

Cela démarre notamment :

• SonarQube
• la base de données
• les services du projet

---

2. Accéder à SonarQube

Si le SonarQube est bien démarré, il faut manuellement ouvrir dans le navigateur :

http://localhost:9000

---

3. Connexion initiale

• Identifiant par défaut : admin
• Mot de passe par défaut : admin

Lors de la première connexion, il est obligatoire de changer le mot de passe.

Dans notre cas :

• Nouveau mot de passe : DevopsS82026!

---

4. Générer un token d’accès

Dans SonarQube :

• Il faut aller dans My Account, puis dans Security
• Il faut donner un nom au token (dans notre cas : DevOps), selectionner le type de token (dans notre cas : User Token) et la durée de validité (dans notre cas : 30 jours) et cliquer sur Generate

Nous avons obtenu le token suivant : squ_9ed49ef1d3c80b33d62bfbdc5eee986e625a7fd7

---

5. Commande pour lancer l’analyse du projet avec Maven et envoyer les résultats à SonarQube :

./mvnw clean verify org.sonarsource.scanner.maven:sonar-maven-plugin:5.5.0.6356:sonar \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.token=squ_9ed49ef1d3c80b33d62bfbdc5eee986e625a7fd7

---

6. Consulter les résultats

Après exécution : A l'exécution de la commande, il nous fournit une URL pour consulter les résultats de l'analyse. Dans notre cas : http://localhost:9000/dashboard?id=fr.istic%3AtlcdemoApp

Les résultats sont également accessibles manuellement via le tableau de bord de SonarQube, en cliquant sur le projet correspondant