Le code

J’ai commencé à suivre les péripéties de Marc Lou (@marc-lou) il y a quelques mois, comme certains d’entre vous j’imagine. Il y a pas mal de concepts intéressants dont il parle, un certain nombre issu de la communauté ‘indie hacking’. Ses deux vidéos sur le code assisté par IA (début 2025) m’ont intéressé.

J’ai donc testé le travail de code assisté par IA, même s’il s’est avéré qu’il s’agissait plutôt d’une IA qui code assistée par un humain !

J’ai choisi la même tech stack que Marc Lou afin de pouvoir me familiariser avec un framework frontend et me replonger dans du JS.

On a donc comme Tech Stack :

Frontend

  • Framework: Next.js 15 with App Router
  • UI Library: React 19
  • Styling: Tailwind CSS 4

Backend

  • API: Next.js API Routes
  • Database: Vercel Postgres
  • Storage: Vercel Storage

Tests

  • Unit: Jest
  • Fonctional: Cypress

On part sur une application de e-commerce ‘classique’. C’est un site web pour une boulangerie qui a un service de commande pour ses gâteaux.

La roadmap produit initiale est:

  1. avoir quelques pages classiques (landing page, about avec l’histoire de la boulangerie et l’équipe, contact),
  2. une partie commande de gâteaux (les clients peuvent visualiser, commander et annoter leur commande)
  3. une partie administration (gestion des commandes par l’équipe et administration du site par le propriétaire).

C’est un cahier des charges assez simple mais qui permet d’explorer toutes les facettes d’un site web: le frontend et ses tests d’interfaces, le backend avec les API, la base de donnée, des parcours utilisateurs à modéliser et à tester.

Au moment de l’écriture de ce billet (20/08, commit 0760482), voici ce qui a été réalisé :

  • choix de tech stack
  • choix de l’hébergement code et app
  • roadmap produit (cf README du code)
  • création de la landing page
  • ajout de tests unitaires et fonctionnels

Le repo et le CI/CD

Le repo qui héberge le code est le repo bakeryproject sous Gitlab. C’est sur Gitlab-CI qu’on va ajouter la partie CI/CD.

La méthode de travail utilisée découle de “Feature Branch development” et elle serait appelée par certains “Issue-based development”. Son implémentation dans Gitlab est aisée:

  • un ticket (issue) est crée par quelqu’un
  • lorsqu’un développeur est prêt à agir sur ce ticket, il créé à partir de ce ticket une requête de fusion (MR)
  • la création de cette MR créé également une branche (dont le nom commence par le numéro de ticket)
  • divers commentaires sont rajoutés dans le ticket (pour discussion avec le client par exemple) et dans la MR (pour discussion interne)
  • le développeur récupère la branche liée au ticket sur son poste et commence à travailler

On fait donc, dans l’ordre:

Ticket (issue) -> Requete de fusion (MR) -> Creation de branche -> Récupération (pull) de la branche en local

C’est un processus très intéressant pour plusieurs aspects:

  1. Tout le processus est dans un seul outil (Pas d’intégration JIRA ici :D )
  2. Tout ce qui est réalisé est suivi par des tickets
  3. On peut tester à beaucoup d’endroits (commit / branch / MR / main), ce qui permet d’ajouter en complexité de tests à chaque palier

Pour pouvoir valider à toutes ces étapes, nous allons donc ajouter du CI/CD avec Gitlab CI. Voici le cahier des charges de notre CI:

  • tester unitairement (jest) en local et sur chaque push de branche
  • tester fonctionnellement au moins sur le push de branch
  • tester complètement (unitaire, fonctionnel, E2E) sur la MR avant de merger sur main

Étant donner que toutes nos modifications vers main passent par une MR (c’est le workflow et la branche est protégée), on va éviter de faire tourner en double un pipeline sur la branche et sur la MR mise à jour. Par contre, on va garder des tests/unitaires voir non-regression sur une branche seule. Cela concerne uniquement une branche présente dans Gitlab, poussée par le dev sans être lié à un MR. Normalement ça ne devrait pas arriver, mais au moins c’est couvert.

Pour la mise en prod, voici ce qu’on recherche:

  • test complet sur main
  • si OK, publication en prod

C’est déjà un pipeline intéressant qu’on construit. Par la suite, on pourra rajouter des choses et/ou changer de process. Par exemple, on pourra installer une branche develop pour coller au GitFlow, on pourra jouer avec les tags et sur la release note.

Voilà pour les présentations, la suite sera dans le prochain post.