Projet Fil Rouge — HashBoard

Progression dans cet atelier 0%

Vision

HashBoard est une plateforme collaborative légère permettant à des équipes de créer des projets, organiser des missions, gérer des tâches, suivre leur progression et documenter leurs décisions.

L’objectif n’est pas de construire une application complète. L’objectif est d’utiliser une application réaliste pour vivre les pratiques de l’ingénierie logicielle moderne.

Architecture du dépôt

hashboard/
├── README.md
├── docs/
├── frontend/
├── backend/
├── database/
├── .github/
├── .gitignore
└── LICENSE

Stack proposée :

Frontend : React ou Next.js
Backend : Express ou NestJS
Base de données : PostgreSQL
Déploiement : Vercel / Railway / Render

Progression sur 5 phases

Phase 1 — Comprendre Git Basics

Initialiser le projet et créer le premier historique Git.

Livrables :

Dépôt hashboard créé sur GitHub
README.md documenté (titre, description, stack, équipe)
Premier commit signé avec un message conventionnel

Phase 2 — Collaborer Branches & Issues

Découper le projet en modules et travailler en parallèle.

Issues à créer :

Authentication Module
Projects Module
Missions Module
Documentation Module

Branches à créer :

git switch -c feature/auth
git switch -c feature/projects
git switch -c feature/missions
git switch -c feature/docs

Livrables :

4 issues ouvertes avec descriptions
4 branches de fonctionnalité actives
Conventions de commits appliquées

Phase 3 — Organiser GitHub Project

Structurer le projet GitHub pour la gestion d’équipe.

Labels à créer :

Label	Usage
`bug`	Anomalie à corriger
`enhancement`	Nouvelle fonctionnalité
`documentation`	Mise à jour doc
`frontend`	Côté client
`backend`	Côté serveur
`security`	Sécurité

Milestone : v1.0.0

Project Board (colonnes) :

Backlog → To Do → In Progress → Review → Done

Livrables :

6 labels configurés
Milestone v1.0.0 créée
Project Board opérationnel avec toutes les issues assignées

Phase 4 — Livrer Pull Requests & Reviews

Appliquer le workflow complet Issue → PR → Review → Merge.

Issue → Branch → Commit → Push → Pull Request → Review → Merge

Chaque membre de l’équipe doit :

Ouvrir une PR depuis sa branche de fonctionnalité
Rédiger une description structurée avec checklist de qualité
Demander une review à un coéquipier
Résoudre les conflits si nécessaire
Merger après approbation

Livrables :

4 Pull Requests ouvertes
Au moins 2 reviews effectuées par membre
Merges validés dans main

Phase 5 — Automatiser CI/CD & DevOps

Mettre en place un pipeline d’intégration continue.

name: HashBoard CI

on:
  push:
    branches: [main, feature/**]
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build

Ajouter également :

Branch Protection Rules sur main (require PR + review)
Secrets GitHub pour les variables d’environnement
Webhook vers le service de déploiement

Livrables :

Pipeline CI actif et vert ✓
Branch protection configurée
Release v1.0.0 publiée avec notes de version

Definition of Done

Compétences consolidées

Architecture de dépôt multi-modules
Workflow Git collaboratif (branches, PRs, merges)
Gestion de projet GitHub (Issues, Labels, Milestones, Boards)
Revue de code constructive
CI/CD avec GitHub Actions
Release management avec tags sémantiques

Fiches de révision

Question

Quelle est la différence entre une Issue et une Pull Request ?

Cliquer pour révéler la réponse

Réponse

Une Issue décrit un problème ou une fonctionnalité à réaliser. Une PR propose du code pour résoudre cette Issue.

Cliquer pour voir la question

Question

Pourquoi utiliser des Branch Protection Rules ?

Cliquer pour révéler la réponse

Réponse

Pour empêcher les pushs directs sur main et imposer une review avant tout merge.

Cliquer pour voir la question

Question

À quoi sert une Milestone ?

Cliquer pour révéler la réponse

Réponse

À regrouper des Issues et PRs liées à une version ou un objectif, et suivre la progression vers cet objectif.

Cliquer pour voir la question

Évaluation des connaissances

Quel est le bon ordre du workflow Git collaboratif ?

Que doit contenir un bon README de projet ?

À quel moment le pipeline CI se déclenche-t-il dans la config de la Phase 5 ?