Monorepo avec Go : organisation du code en pratique

Monorepo avec Go : organisation du code en pratique

Un monorepo est une approche de gestion de code où tous les projets, bibliothèques et services sont stockés dans un seul dépôt. Dans la communauté Go, cette approche gagne en popularité grâce à sa simplicité et son efficacité. Dans cet article, nous allons voir comment organiser un projet Go dans un monorepo en pratique : du choix de la structure à la configuration du CI/CD.

Pourquoi un monorepo pour Go ?

Go a été conçu dès le départ comme un langage pour les grandes bases de code. Des outils comme go mod et go work rendent le travail avec un monorepo naturel. Les principaux avantages :

• Simplification des dépendances : tous les modules utilisent une version unique des packages, pas de conflits de versions.
• CI/CD unifié : un seul fichier de configuration pour tous les services, plus facile à maintenir.
• Refactorisation : une modification d'API dans une bibliothèque se répercute immédiatement sur tous les consommateurs du dépôt.
• Standards unifiés : les linters, les formateurs et les revues de code s'appliquent à tout le code.

Structure du monorepo : un schéma éprouvé

Examinons une structure qui fonctionne parfaitement pour les projets Go de taille moyenne. Supposons que nous ayons deux services : auth-service et api-gateway, ainsi que des bibliothèques partagées.

my-project/├── apps/                    # Applications exécutables│   ├── auth-service/│   │   ├── cmd/│   │   │   └── main.go│   │   ├── internal/│   │   │   ├── handler/│   │   │   ├── service/│   │   │   └── repository/│   │   ├── go.mod│   │   └── go.sum│   └── api-gateway/│       ├── cmd/│       │   └── main.go│       ├── internal/│       │   ├── middleware/│       │   └── routes/│       ├── go.mod│       └── go.sum├── libs/                    # Bibliothèques partagées│   ├── config/│   │   ├── config.go│   │   ├── go.mod│   │   └── go.sum│   ├── logger/│   │   ├── logger.go│   │   ├── go.mod│   │   └── go.sum│   └── db/│       ├── postgres.go│       ├── go.mod│       └── go.sum├── scripts/                 # Scripts pour CI/CD et utilitaires│   ├── build.sh│   └── test.sh├── go.work                  # Workspace Go (optionnel)├── .golangci.yml            # Configuration du linter├── Makefile                 # Commandes communes└── README.md

Éléments clés de la structure

• apps/ — toutes les applications exécutables. Chaque application a son propre point d'entrée (cmd/main.go) et son propre go.mod.
• libs/ — bibliothèques d'usage général. Chaque bibliothèque est un module Go distinct.
• scripts/ — scripts auxiliaires pour la construction, les tests et le déploiement.
• go.work — fichier pour Go Workspace, simplifie le développement local.

Configuration de Go Workspace pour le développement local

Go 1.18+ prend en charge Workspace via le fichier go.work. Cela permet de référencer localement les bibliothèques de libs/ sans les publier dans un dépôt distant.

Créez go.work à la racine du projet :

go 1.22

use (    ./apps/auth-service    ./apps/api-gateway    ./libs/config    ./libs/logger    ./libs/db)

Désormais, lors du développement, vous pouvez importer les bibliothèques directement :

// apps/auth-service/cmd/main.gopackage main

import (    "my-project/libs/config"    "my-project/libs/logger")

func main() {    cfg := config.Load()    log := logger.New(cfg.LogLevel)    log.Info("Auth service started")}

Remarque importante : dans le go.mod de chaque application, la dépendance à la bibliothèque doit pointer vers un chemin local via replace :

// apps/auth-service/go.modmodule github.com/company/my-project/a