DEV Community: Patrick Turcotte

Développer pour le déploiement distribué

Patrick Turcotte — Sun, 14 Dec 2025 05:00:00 +0000

Bonnes pratiques et considérations

Introduction

L'idée de cet article m'est venue, en début d'année, après ma publication sur les éléments à considérer quand on démarre un projet de développement et en discutant avec des collègues qui commençaient à apprendre un environnement cloud.

Les applications sont maintenant souvent déployées dans des environnements distribués, que ce soit via des fournisseurs cloud (AWS, Azure, GCP), des orchestrateurs comme Kubernetes, des services managés, des fonctions serverless, ou même des infrastructures on-premise distribuées.

Le développement d'applications destinées à ces environnements distribués nécessite de prendre en considérations plusieurs aspects spécifiques.
Voici une liste de pratiques et de considérations clés pour développer des applications distribuées résilientes et scalables.

Pour les fins de cet article, nous énoncerons principalement des considérations pour les services à durée de vie prolongée.
La plupart de ces considérations s'appliquent également aux fonctions serverless et aux applications événementielles.

Multiples instances jetables pour rendre un même service

Plusieurs clones, une seule mission

La considération la plus importante est que votre application doit être conçue pour fonctionner dans un environnement où plusieurs instances peuvent être exécutées simultanément. Cela signifie qu'une instance de votre application ne doit pas interférer avec une autre instance, et qu'il faut éviter la duplication de traitement. De plus, votre application ne doit pas dépendre d'un état local ou de ressources spécifiques à une instance, car ces éléments ne sont pas garantis d'être disponibles ou persistants entre les instances ou les redémarrages.

Que ce soit pour scaler horizontalement (ajouter plus d'instances) ou pour la résilience (redémarrer une instance défaillante), parce que le nombre d'instances change en fonction de la charge réelle ou anticipée, en fonction de l'heure, etc., votre application doit être capable de gérer plusieurs instances sans conflit.

Elle sera aussi probablement démarrée sans intervention humaine. Vous devez donc conserver ces aspects en tête lors de la conception et du développement de votre application.

Architecture derrière un load balancer/reverse proxy

Comme une répartitrice d'appels en centre de services : chaque requête est envoyée au bon département — facturation, support, ou comptes — selon ce qu'elle demande.

Dans la plupart des cas, les instances de votre application seront déployées derrière un load balancer (équilibreur de charge).
Le load balancer distribue le trafic entrant entre les différentes instances de votre application.
L'utilisation de sticky sessions permet de faire en sorte que le load balancer va envoyer le trafic qui revient à la même instance.
Mais, il se peut que l'instance qui a fait le traitement initial ne soit plus disponible (scale down, mise à jour, etc.) ou que le load balancer ne supporte pas les sessions sticky, cela signifie que votre application doit être capable de prendre le relais d'une requête sans avoir répondu à la requête précédente dans le workflow.

Dans les architectures modernes, le load balancer ou l'API Gateway peut aussi router vers des services différents selon la requête :

Par chemin (path-based routing), ex. : /api/users → service Utilisateurs, /api/orders → service Commandes
Par hôte (host-based routing), ex. : api.example.com → API, static.example.com → ressources statiques
Par en-tête ou version d'API (header/version routing), ex. : X-Client: mobile ou Accept: application/vnd.company.v2+json
Par méthode ou port (rare), selon les contraintes techniques

Les conséquences du côté développement sont que vous devez éviter les hypothèses d'état de session local, car une requête peut arriver à un autre service ou une autre instance. Il devient très utile de propager les identifiants de corrélation pour tracer la requête à travers plusieurs services.

Externaliser la configuration

Externaliser la configuration, c'est comme insérer une carte SIM dans un téléphone : même appareil, réglages adaptés au réseau. En changeant de SIM, on peut aussi changer de fournisseur — Bell, Vidéotron, Orange — sans toucher au téléphone lui-même.

Un aspect important du développement pour le déploiement distribué (dont le cloud) est de séparer la configuration de l'application du code lui-même.
Cela permet notamment de modifier la configuration sans avoir à recompiler l'application.

Une pratique très courante est d'utiliser des variables d'environnement pour fournir la configuration à l'application. Voir https://12factor.net/fr/config

Les différents fournisseurs cloud offrent aussi un service d'externalisation de la configuration, comme AWS Systems Manager Parameter Store, Azure App Configuration ou GCP Secret Manager.
Ces services permettent de stocker et de gérer la configuration de manière sécurisée et centralisée. Il est aussi possible de déployer votre propre service de configuration, comme Consul, etcd ou Spring Cloud Config. Par contre, vous devrez adapter votre application pour qu'elle puisse récupérer la configuration à partir de ces services.

Le choix final que vous ferez dépendra de si vous prévoyez déployer votre application dans un seul fournisseur cloud ou dans plusieurs ou s'il est possible que vous changiez éventuellement de fournisseur. Il est probablement plus prudent d'utiliser une solution agnostique au fournisseur cloud pour éviter le vendor locking, c'est-à-dire de ne pouvoir déployer que sur un seul fournisseur.

Feature flags et configuration dynamique

Les feature flags, c'est comme les scènes post-crédits Marvel : on peut les activer pour certains, les cacher pour d'autres, et les couper net si ça tourne mal. Zéro recompilation, juste un interrupteur.

Les feature flags (drapeaux de fonctionnalités) permettent d'activer ou désactiver des fonctionnalités sans recompiler l'application, ou même la redéployer si vous mettez en place une façon d'en prendre compte pendant que l'application roule. Cette stratégie peut être très utile, notamment pour les cas d'utilisation suivants.

Déploiements progressifs : Activer une nouvelle fonctionnalité pour un pourcentage d'utilisateurs ou certains groupes d'utilisateurs

A/B testing : Tester différentes versions d'une fonctionnalité

Kill switch : Désactiver rapidement une fonctionnalité problématique en production sans redéployer

Environnements spécifiques : Activer des fonctionnalités seulement dans certains environnements, comme dev ou qa mais pas en production pour valider avant le déploiement complet sans devoir gérer plusieurs branches de code.

Des outils comme LaunchDarkly, Unleash, Split.io, ou AWS AppConfig peuvent être utilisés pour gérer les feature flags.

Gestion des secrets

Mettre des secrets dans le code source, c'est comme cacher la clé de la maison sous le paillasson : tout le monde sait où chercher. Utilisez un vrai coffre-fort.

Ne jamais stocker des secrets (mots de passe, clés API, certificats) directement dans le code ou dans les fichiers de configuration versionnés.

Utilisez plutôt des services de gestion des secrets qui offrent des fonctionnalités de sécurité avancées, comme des services clouds dédiés (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager), le système d'encryption de votre orchestrateur (Kubernetes Secrets avec encryption at rest activée), ou des outils tiers comme HashiCorp Vault ou SOPS.

Ces solutions offrent plusieurs avantages, comme l'encryption des secrets au repos et en transit, un contrôle d'accès granulaire, la rotation automatique des secrets, et l'audit des accès.

Sauvegarde de fichiers de travail ou téléversés

Écrire sur le disque local en cloud, c'est laisser vos notes sur la table du café : ça marche… jusqu'au ménage.

Imaginons une application qui génère un rapport (PDF, Excel, etc.) à partir de données fournies par l'utilisateur.

Dans un scénario "classique", l'application pourrait générer le rapport sur le disque dur local de l'instance, puis le rendre disponible pour téléchargement.

Par contre, dans un environnement à multiple instance, il faut mettre ce fichier soit dans un stockage partagé, un volume réseau, ou, au pire, la base de données.

Les fournisseurs offrent des services de stockage, comme AWS S3, AWS EFS, Azure Blob Storage, Azure Files, GCP Cloud Storage ou GCP Filestore, qui peuvent être utilisés pour stocker ces fichiers intermédiaires.

Tâches périodiques / Cron Job

Les crons en multi-instances, c'est comme nettoyer la maison en colocation : si 5 colocataires font le ménage au même moment pour la même pièce, c'est du travail gaspillé. Il faut qu'un seul le fasse à la fois. Sinon, même pièce nettoyée 5 fois = 5 fois le travail, 5 fois le coût.

Les tâches périodiques, comme l'envoi de courriel de rappel, la création de rapports ou la purge de données sont fréquentes dans les applications.

Dans un environnement distribué, il est important de s'assurer que ces tâches ne sont pas exécutées simultanément par plusieurs instances de l'application.

Pour y arriver, il faut réfléchir à une façon de synchroniser l'exécution de ces tâches. Plusieurs approches sont possibles :

Utiliser un service de planification externe, comme AWS CloudWatch Events, Azure Logic Apps ou GCP Cloud Scheduler, pour déclencher les tâches périodiques.
Utiliser un mécanisme de verrouillage distribué, comme une entrée dans une base de données ou un service de cache distribué (Redis, Memcached) pour s'assurer qu'une seule instance exécute la tâche à un moment donné.
Utiliser une bibliothèque de planification comme Quartz Scheduler ou autre similaire.

Il peut être intéressant de développer une mécanique qui permet de lancer des tâches spécifiques, qui peuvent être appelées par le service de planification externe ou par un job interne avec un verrouillage distribué. Par exemple de créer des endpoints HTTP sécurisés qui déclenchent les tâches périodiques. Dans ce cas, des endpoints complémentaires pour obtenir le statut des tâches peuvent aussi être utiles pour le monitoring.

L'important, c'est de faire en sorte que les tâches périodiques soient exécutées de manière fiable et sans conflit entre les différentes instances de l'application.

Gestion de l'état et des sessions

Les sessions en déploiement distribué, c'est un vestiaire : on présente son ticket et on retrouve son manteau, peu importe la porte d'entrée ou le préposé.

Dans un environnement distribué avec plusieurs instances, la gestion de l'état utilisateur (sessions) devient critique. Si un utilisateur se connecte à une instance et que sa prochaine requête est routée vers une autre instance, l'application doit pouvoir récupérer les informations de la session. Plusieurs approches existent pour gérer les sessions dans un environnement distribué.

Sessions stateless : Utiliser des tokens JWT (JSON Web Tokens) qui contiennent toutes les informations nécessaires. Le client transmet le token à chaque requête. Il peut le transmettre par header, par cookie, ou dans le corps de la requête.

Cache distribué : Stocker les sessions dans un cache distribué comme Redis ou Memcached, accessible par toutes les instances.

Sticky sessions : Configurer le load balancer pour router toujours le même utilisateur vers la même instance (moins recommandé car crée des dépendances et ne fonctionnera pas si l'instance est arrêtée).

Base de données : Stocker les sessions dans la base de données (moins performant mais plus simple).

L'approche à privilégier dépendra de vos besoins spécifiques, mais les sessions stateless (JWT) ou le cache distribué (Redis, Memcached) souvent généralement préférés. Les sessions stateless permettent de réduire la dépendance à un stockage centralisé et facilitent le scaling horizontal. Par contre, la révocation immédiate des sessions peut être plus complexe avec JWT. De l'autre côté, l'utilisation d'un cache distribué offre une gestion centralisée des sessions, mais introduit une dépendance supplémentaire et peut nécessiter une infrastructure plus complexe.

Persistance et transactions de base de données

La base de données, c'est comme le seul guichet de la banque : si 10 clients ouvrent chacun leur porte (connexion), c'est du gaspillage. Il faut une file d'attente partagée. Et si 10 clients payent la même facture en même temps, il faut éviter les doublons. Une seule transaction réussie, pas 10 écritures identiques.

Dans un environnement distribué, la gestion des transactions de base de données nécessite une attention particulière.

Connexions à la base de données : Utilisez un pool de connexions pour optimiser l'utilisation des ressources. Configurez le nombre maximum de connexions en fonction du nombre d'instances.

Transactions distribuées : Évitez les transactions distribuées (2PC - Two-Phase Commit) autant que possible, car elles sont complexes et réduisent la performance. Privilégiez le pattern Saga pour gérer les transactions sur plusieurs services.

Idempotence : Concevez vos opérations de base de données pour être idempotentes, c'est-à-dire qu'elles produisent le même résultat même si elles sont exécutées plusieurs fois.

Retry et resilience : Implémentez des mécanismes de retry pour gérer les échecs temporaires de connexion à la base de données.

Migrations de schéma de base de données

Migrer le schéma, c'est rénover sans fermer le magasin : on déplace les rayons, on garde les clients.

Les migrations de schéma dans un environnement distribué nécessitent une planification minutieuse.

Migrations forward-compatible : Les changements doivent être compatibles avec l'ancienne version pendant le déploiement, on peut ainsi déployer les nouvelles instances avant de retirer les anciennes ou même faire un retour en arrière applicatif si nécessaire.

Outils de migration : Utilisez Liquibase, Flyway, ou des outils natifs (Alembic pour Python, migrate pour Go)

Déploiements testés : Pour les changements, particulièrement les changements majeurs, il est important de tester la migration de la base de données avant d'appliquer à la production

Migrations à l'arrêt vs au démarrage : Décidez si les migrations s'exécutent avant ou pendant le déploiement

Rollback : Préparez toujours un plan de rollback pour les migrations complexes

Patterns pour les changements de schéma

Il existe certains patterns courants pour gérer les changements de schéma de base de données dans un environnement distribué. Ils permettent de minimiser les interruptions de service et de garantir la compatibilité entre les versions.

Expand-Contract Pattern :
1. Expand : Ajoutez la nouvelle colonne/table
2. Dual-write : Écrivez dans l'ancienne et la nouvelle structure
3. Migrate : Migrez les anciennes données
4. Contract : Supprimez l'ancienne structure
Versioning des changements : Quand les changements de schéma affectent l'API, utilisez le versioning (v1, v2)

Mise en cache et performance

Le cache, c'est comme garder les documents importants sur votre bureau plutôt qu'au sous-sol : on accède vite à ce qu'on utilise souvent. Mais attention, il faut parfois faire le ménage pour éviter de travailler avec des versions périmées.

Le cache est crucial pour la performance dans un environnement distribué. Obtenir une information en mémoire est beaucoup plus rapide que d'aller la chercher dans une base de données ou un service externe.

Types de cache

Il existe plusieurs types de cache que vous pouvez utiliser.

Cache en mémoire local : Rapide mais non partagé entre instances (Caffeine, Guava Cache)

Cache distribué : Partagé entre toutes les instances (Redis, Memcached, Hazelcast)

CDN : Pour les ressources statiques (CloudFront, Azure CDN, Cloud CDN, autres)

HTTP caching : Utilisez les headers HTTP (Cache-Control, ETag) pour le cache côté client

Reverse proxy cache : Cache comme varnish

Stratégies de cache

La stratégie de cache dépendra de vos besoins spécifiques.

Cache-aside : L'application vérifie le cache, puis la base de données si nécessaire

Write-through : Les données sont écrites dans le cache et la base de données simultanément

Write-behind : Les données sont écrites dans le cache d'abord, puis dans la base de données de façon asynchrone

Invalidation : Définissez des stratégies claires pour invalider le cache (TTL, événements)

Invalidation et nettoyage du cache

L'un des défis les plus importants avec le cache est de savoir quand le nettoyer ou l'invalider. Un cache obsolète peut causer des bugs difficiles à diagnostiquer.

TTL (Time-To-Live) : Définissez une durée de vie maximale pour chaque entrée du cache. Après ce délai, l'entrée est automatiquement supprimée ou marquée comme expirée.

Invalidation par événement : Lorsque des données sont modifiées dans la base de données, invalidez ou mettez à jour les entrées de cache correspondantes. Utilisez des event listeners ou des patterns pub/sub.

Cache tagging : Associez des tags aux entrées de cache pour pouvoir invalider plusieurs entrées liées d'un coup (par exemple, toutes les entrées liées à un utilisateur spécifique).

Versioning : Incluez une version dans la clé de cache. Quand vous déployez un changement de format, incrémentez la version pour invalider automatiquement les anciennes entrées.

Flush sélectif vs global : Évitez de vider tout le cache (flush) sauf en cas d'urgence. Préférez l'invalidation ciblée pour maintenir les performances.

Cache warming : Après un vidage ou au démarrage, préremplissez le cache avec les données les plus utilisées pour éviter une charge soudaine sur la base de données.

Certaines considérations sont importantes pour l'invalidation et le nettoyage de la cache pour les environnements distribués. Si vous utilisez un cache distribué (Redis, Memcached), l'invalidation sera visible par toutes les instances. Par contre, si vous utilisez un cache local en mémoire, chaque instance aura son propre cache. Vous devrez propager les événements d'invalidation à toutes les instances (via pub/sub ou message queue). Documentez clairement votre stratégie d'invalidation pour chaque type de données cachées.

Autres considérations importantes

Attention au thundering herd : quand plusieurs instances tentent de recharger le même cache expiré simultanément. On revient ici avec la notion selon laquelle plusieurs instances tentent de faire la même chose en même temps. On peut mettre en place une stratégie de grace mode pour mitiger le problème.
Utilisez des clés de cache bien structurées pour faciliter l'invalidation ciblée
Surveillez le taux de hit/miss du cache pour optimiser la configuration
Loggez les invalidations de cache pour faciliter le debugging

Considérations pour l'équipe devops

Le devops, c'est comme piloter un avion qu'on n'a pas construit : on a besoin d'instruments de bord clairs, de voyants qui s'allument au bon moment, et d'un manuel qui dit ce qu'il faut faire si ça tourne mal.

L'équipe qui va déployer et gérer l'application a des besoins spécifiques qui doivent être pris en compte dès le début du développement.

Observabilité : Logs, métriques et traces

Et quand l'avion a des problèmes, on devient détective : les logs racontent ce qui s'est passé dans le cockpit, les métriques montrent les tendances du vol, et les traces suivent la route à travers le ciel. Sans ces instruments, on enquête à l'aveugle dans le brouillard.

L'observabilité est cruciale dans un environnement distribué où il peut être difficile de diagnostiquer les problèmes.

Logging structuré

Utilisez un format de log structuré tel JSON pour faciliter la recherche et l'analyse.
Incluez un identifiant de corrélation (correlation ID) dans chaque log pour tracer une requête à travers plusieurs services et instances.
Centralisez vos logs dans un système comme AWS CloudWatch, Azure Monitor, GCP Cloud Logging, ELK Stack (Elasticsearch, Logstash, Kibana), Datadog ou Loki.

Évitez de logger des informations sensibles (mots de passe, tokens, données personnelles).
Évitez aussi de logger trop d'informations pour ne pas noyer les logs importants.
Si possible, utilisez des bibliothèques de logging qui supportent la reconfiguration dynamique du niveau de log (DEBUG, INFO, WARN, ERROR) sans redémarrer l'application.

Métriques

Exposez des métriques sur la santé et la performance de votre application (temps de réponse, nombre de requêtes, taux d'erreur, utilisation CPU/mémoire).
Utilisez des outils comme Prometheus, Grafana, ou les outils natifs de votre plateforme de déploiement pour collecter et visualiser ces métriques.
Configurez des alertes basées sur ces métriques pour être notifié des problèmes.

Tracing distribué

Implémentez le tracing distribué avec des outils comme Jaeger, Zipkin ou AWS X-Ray pour suivre le parcours d'une requête à travers vos différents services.
Utilisez OpenTelemetry comme standard pour instrumenter votre application.

Health checks et readiness probes

Les probes, c'est le test du micro avant le concert : on vérifie qu'on est prêt avant de monter le son.

Les orchestrateurs comme Kubernetes et les load balancers ont besoin de savoir si une instance de votre application est en bonne santé et prête à recevoir du trafic.

Il existe généralement trois types de probes.
Le Liveness probe indique si l'application est vivante et fonctionne. Si elle échoue, l'orchestrateur redémarre l'instance.
Le Readiness probe indique si l'application est prête à recevoir du trafic. Par exemple, si les connexions à la base de données ne sont pas encore établies, l'instance n'est pas prête.
Le Startup probe, pour les applications qui prennent du temps à démarrer, évite que la liveness probe ne tue l'application prématurément.

Implémentez des endpoints HTTP dédiés (par exemple /health et /ready) qui retournent le statut approprié.

Graceful shutdown

Fermer en douceur, c'est dire au revoir avant de raccrocher : on termine la phrase, puis on coupe.

Lorsqu'une instance de votre application est arrêtée (mise à jour, scaling down, etc.), elle doit se terminer proprement :

Arrêter d'accepter de nouvelles requêtes
Terminer le traitement des requêtes en cours
Fermer proprement les connexions aux bases de données et aux services externes
Libérer les ressources

Implémentez un signal handler (SIGTERM) pour gérer l'arrêt gracieux de votre application. La plupart des orchestrateurs envoient un SIGTERM avant de forcer l'arrêt avec SIGKILL.

Gestion des dépendances et vulnérabilités

Faites votre inventaire comme chez Home Alone : vérifiez les pièges, ne laissez pas d'entrées faciles.

La gestion proactive des dépendances est cruciale pour la sécurité et la stabilité :

Scan régulier : Utilisez des outils comme Dependabot, Snyk, ou OWASP Dependency-Check pour identifier les vulnérabilités dans vos dépendances
Mises à jour automatisées : Configurez des pull requests automatiques pour les mises à jour de sécurité
Versioning sémantique : Respectez le versioning sémantique pour vos propres bibliothèques
Lockfiles : Utilisez des fichiers de verrouillage (package-lock.json, uv.lock, Pipfile.lock, go.sum, pom.xml) pour garantir la reproductibilité
Audit régulier : Faites des audits de sécurité réguliers de vos dépendances

CI/CD et pipelines de déploiement

Le pipeline, c'est la chaîne de montage : on sort des versions fiables, pas des prototypes du lundi matin.

L'automatisation du déploiement est essentielle pour le cloud, elle est aussi très utile quand on déploie sur des serveurs traditionnels. Elle permet de réduire les oublis, les erreurs humaines et d'accélérer les mises à jour.

Intégration continue : Exécutez les tests automatiquement à chaque commit (GitHub Actions, GitLab CI, Jenkins, CircleCI).

Tests : Incluez des tests unitaires, d'intégration, et end-to-end dans votre pipeline.

Build d'images : Automatisez la création des images de conteneur.

Scan de sécurité : Intégrez le scan de sécurité des images et des dépendances dans le pipeline.

Déploiement progressif : Utilisez des stratégies comme blue/green deployment, canary deployment, ou rolling updates pour minimiser les risques.

Rollback automatique : Configurez un rollback automatique si les health checks échouent après un déploiement.

Infrastructure as Code : Gérez votre infrastructure avec Terraform, CloudFormation, Pulumi, ou ARM templates.

Faites en sorte que votre pipeline injecte la version de l'image dans les variables d'environnement de l'application.

Conteneurisation et images

Un bon conteneur, c'est une valise bien rangée : légère, sécurisée, et sans le tag 'latest' perdu à l'aéroport.

La conteneurisation est quasi-universelle dans le déploiement distribué :

Images légères : Utilisez des images de base minimales (Alpine, distroless) pour réduire la taille et la surface d'attaque.

Multi-stage builds : Utilisez des builds multi-étapes pour séparer la compilation de l'exécution et réduire la taille finale.

Scan de sécurité : Scannez vos images pour détecter les vulnérabilités (Trivy, Snyk, Clair).

Versioning : Versionnez vos images et évitez d'utiliser le tag latest en pré-production ou en production.

Non-root user : Exécutez vos conteneurs avec un utilisateur non-root pour la sécurité.

Pipelines : Automatisez la construction, le test et le déploiement de vos images via des pipelines CI/CD.

Assurez-vous d'exposer la version de l'image dans les variables d'environnement de l'application.

Optimisation des coûts (cloud)

Le cloud facture comme un taxi : laissez le compteur tourner, et la note grimpe. Mettez des limites.

Le cloud peut devenir coûteux si on ne fait pas attention :

Auto-scaling intelligent : Configurez l'auto-scaling basé sur des métriques réelles (CPU, mémoire, nombre de requêtes).

Right-sizing : Choisissez la taille d'instance appropriée pour votre charge de travail. Ne sur-provisionnez pas.

Utilisation de spot instances : Pour les charges de travail non-critiques ou les environnements de test, utilisez des instances spot/préemptibles.

Shutdown automatique : Arrêtez les environnements de développement et de test en dehors des heures de travail.

Monitoring des coûts : Utilisez les outils de monitoring des coûts fournis par votre cloud provider.

Gestion des ressources et limites

Les ressources, c'est le budget calorique : trop peu, on cale; trop, on somnole. Trouvons le bon dosage.

Définir correctement les ressources allouées à votre application est essentiel :

Requests et Limits : Dans Kubernetes, définissez des requests (ressources garanties) et des limits (ressources maximales) pour CPU et mémoire

Memory leaks : Surveillez activement les fuites mémoire qui peuvent causer des redémarrages fréquents

JVM tuning : Pour les applications Java, configurez correctement le heap size et le garbage collector en fonction des ressources allouées

Connection pools : Dimensionnez correctement vos pools de connexions (DB, HTTP clients) en fonction du nombre d'instances et de la charge

Thread pools : Configurez les thread pools pour éviter l'épuisement des threads et les blocages

Développement local et environnement de dev

Développer localement, c'est répéter en studio : on règle les fausses notes avant le concert en prod.

Développer pour un environnement distribué ne signifie pas que tout doit se faire dans cet environnement.

Émulation locale des services distribués

LocalStack : Émule les services AWS localement (S3, DynamoDB, SQS, etc.)
Azurite : Émulateur pour Azure Storage
Docker Compose : Orchestrez localement vos services (base de données, cache, message queues)
Testcontainers : Lancez des conteneurs pour vos tests d'intégration
Minikube/Kind : Exécutez Kubernetes localement pour tester vos déploiements

Configuration locale vs déploiement distribué

Utilisez des profils de configuration différents pour le développement local vs déploiement distribué. Évitez de dépendre de services cloud spécifiques pendant le développement local quand possible. Documentez clairement les étapes pour configurer l'environnement de développement local, idéalement avec des scripts d'automatisation. Utilisez des variables d'environnement avec des valeurs par défaut pour simplifier la configuration locale. Si vous devez utiliser des secrets, utilisez des fichiers .env locaux ou des services de gestion des secrets adaptés au développement comme SOPS. Voir l'article que j'ai rédigé à ce sujet: SOPS - Secrets encryptés dans un dépôt GIT

Hot reload et développement rapide

Utilisez des outils de hot reload (Spring Boot DevTools, Nodemon, Air pour Go) pour accélérer le cycle de développement.
Configurez des volumes montés dans Docker pour un rechargement rapide du code.
Utilisez des outils comme Skaffold ou Tilt pour le développement continu sur Kubernetes.

Tests pour applications distribuées

Les tests, c'est comme les crashs tests de voitures : on fracasse des prototypes dans un labo pour éviter d'avoir de vrais accidents sur l'autoroute. Et quand quelqu'un modifie le volant ou les freins, on refracasse tout pour vérifier que ça tient toujours la route.

Tester des applications distribuées nécessite une approche différente.

Tests unitaires

Tests isolés de la logique métier
Mockez les dépendances externes (base de données, services tiers)
Utilisez des frameworks de test adaptés à votre langage

Tests d'intégration

Testcontainers : Lancez des conteneurs Docker pour tester avec de vraies dépendances
Tests de base de données : Testez les requêtes SQL et les migrations avec une vraie base de données
Tests d'API : Testez vos endpoints REST/gRPC avec des outils comme RestAssured, Supertest

Tests end-to-end

Testez le système complet dans un environnement similaire à la production
Utilisez des outils comme Selenium, Cypress, Playwright pour les applications web
Automatisez ces tests dans votre pipeline CI/CD

Tests de charge et de performance

Load testing : Testez le comportement sous charge normale (Apache JMeter, Gatling, k6)
Stress testing : Testez les limites du système
Spike testing : Testez la réponse à des pics soudains de trafic
Soak testing : Testez la stabilité sur une longue période pour détecter les fuites mémoire

Tests de chaos engineering

Si nécessaire, intégrez des tests de chaos engineering pour valider la résilience de votre application :

Testez la résilience en introduisant des défaillances volontaires
Utilisez des outils comme Chaos Monkey, Gremlin, ou LitmusChaos
Simulez des pannes de serveurs, des latences réseau, des bases de données indisponibles

Tests de régression visuelle

Pour les applications frontend, testez que l'interface n'a pas changé de façon non intentionnelle
Utilisez des outils comme Percy, Chromatic, ou Applitools

Communication entre services

La communication entre services, c'est comme un orchestre de jazz : chaque musicien doit savoir quand jouer, dans quelle tonalité, et à quel tempo. Sans protocole commun (REST, gRPC, ou messages asynchrones), c'est la cacophonie. Tout le monde improvise, mais pendant le même jam-session.

Si votre application est composée de plusieurs microservices ou composants qui doivent communiquer entre eux, il est crucial de choisir les bons protocoles et patterns de communication.

API REST : Standard et simple, utilisez HTTP/HTTPS avec des formats JSON.

gRPC : Plus performant que REST, utilise Protocol Buffers et HTTP/2.

Message queues : Pour la communication asynchrone, utilisez RabbitMQ, Apache Kafka, AWS SQS, Azure Service Bus, Postgres Notify, ou GCP Pub/Sub.

Service mesh : Pour gérer la communication entre services (Istio, Linkerd) avec features comme le load balancing, le circuit breaking, et le mTLS.

Certaines considérations importantes sont à ne pas négliger. Utilisez des timeouts pour toutes les communications inter-services. Implémentez des retry avec backoff exponentiel. Utilisez des circuit-breakers pour éviter les cascades de défaillances. Propagez les correlation IDs pour le tracing distribué.

Résilience et gestion des erreurs

La résilience, c'est l'amortisseur : la route est cahoteuse, mais on garde le cap sans casser le châssis.

Dans un environnement distribué, les erreurs sont inévitables. Votre application doit être conçue pour être résiliente.

Circuit breaker : Évite de surcharger un service défaillant en "ouvrant le circuit" après un certain nombre d'échecs.

Retry avec backoff exponentiel : Réessaie les opérations échouées avec un délai croissant entre chaque tentative.

Timeout : Définissez des timeouts pour toutes les opérations réseau pour éviter d'attendre indéfiniment.

Bulkhead : Isolez les ressources pour qu'une défaillance dans une partie du système n'affecte pas les autres.

Fallback : Prévoyez un comportement de secours quand une opération échoue (cache, valeur par défaut, mode dégradé).

Des bibliothèques comme Resilience4j (Java), Polly (.NET) ou Hystrix facilitent l'implémentation de ces patterns.

Patterns de conception à considérer

Les bons patterns, c'est une carte routière : on évite les chemins de terre et on arrive à l'heure.

Plusieurs patterns architecturaux sont particulièrement adaptés aux déploiements distribués.

Strangler Fig Pattern : Migrez progressivement une application monolithique vers des microservices en "étranglant" l'ancien système

Backend for Frontend (BFF) : Créez des API spécifiques pour chaque type de client (web, mobile, etc.)

API Gateway : Point d'entrée unique pour tous vos services, gérant l'authentification, le routage, le rate limiting

Event Sourcing : Stockez tous les changements d'état comme une séquence d'événements

CQRS (Command Query Responsibility Segregation) : Séparez les opérations de lecture et d'écriture pour optimiser chacune indépendamment

Sidecar Pattern : Déployez des fonctionnalités auxiliaires (logging, monitoring) dans un conteneur séparé mais adjacent

Il est important de bien comprendre ces patterns, dans quel contexte les utiliser et de les adapter à vos besoins spécifiques.

Anti-patterns à éviter

Les anti-patterns, ce sont les panneaux 'route barrée' : si on insiste, on finit dans le fossé.

Distributed Monolith : Microservices trop couplés qui doivent être déployés ensemble. L'indépendance relative entre les services est cruciale.

Chatty Services : Trop de communication entre services, créant de la latence, pensez à regrouper les appels, à la caching, ou à utiliser des messages asynchrones.

Tight Coupling : Services dépendant fortement les uns des autres, rendant les changements et le déploiement difficiles. Pensez à utiliser des interfaces claires et des contrats stables.

Data Ownership Violations : Services accédant directement à la base de données d'autres services. Si vous choisissez de considérer la base de données comme un service, chaque service doit gérer son propre schéma de données. De plus, s'il est plus efficace pour un service d'accéder directement à la base de données d'un autre service, pensez à exposer l'information sous la forme d'une vue qui devient le contrat entre les deux services.

Ignorer la loi de fallacies of distributed computing : Supposer que le réseau est fiable, la latence nulle, la bande passante infinie, etc.

Sécurité

La sécurité, c'est la serrure ET l'alarme : le cloud a des voisins curieux, mieux vaut être prudent.

Tant dans un déploiement distribué traditionnel que dans le cloud, la sécurité est une responsabilité partagée par les développeurs et l'équipe devops doit être intégrée dès le début.

Principe du moindre privilège : Donnez uniquement les permissions nécessaires aux applications et aux utilisateurs.

Encryption : Chiffrez les données au repos et en transit (TLS/HTTPS).

Authentification et autorisation : Utilisez des standards comme OAuth2/OIDC pour l'authentification, JWT pour les tokens.

Scan de vulnérabilités : Scannez régulièrement vos dépendances et vos images.

WAF : Utilisez un Web Application Firewall pour protéger contre les attaques courantes.

DDoS protection : Activez la protection DDoS offerte par votre cloud provider. Sinon, regardez ce que vous pouvez mettre en place vous-même.

Audit logs : Conservez des logs d'audit pour toutes les opérations sensibles.

Environnements multiples

Multi-environnements, ce sont des costumes adaptés : même comédien, répétitions en studio, première en gala.

Maintenez plusieurs environnements pour différents stades du cycle de vie. Ils permettent une liberté pour tester et valider les changements avant de les déployer aux testeurs, puis en production.

Local : Pour le développement individuel

Développement : Pour s'assurer que les nouvelles fonctionnalités fonctionnent ensemble, que ça déploie correctement, pour permettre aux développeurs de tester des intégrations.

Test/QA : Pour les tests d'intégration et d'acceptation

Staging/Pre-prod : Une copie de la production pour les tests finaux par un groupe restreint d'utilisateurs, souvent du côté du client, avant le déploiement en production

Production : L'environnement de production

Utilisez l'Infrastructure as Code est une excellente pratique pour garantir que tous les environnements sont configurés de manière cohérente. Ça évite aussi qu'une configuration manuelle soit oubliée dans un environnement ou qu'une configuration essentielle soit omise ou différente entre les environnements.

Conclusion

Adopter ces pratiques, c'est comme apprendre le piano : on ne joue pas du Beethoven dès le premier jour. Commencez par les bases, adaptez à votre rythme, et avant longtemps vous ferez de la musique — sans péter les plombs ni le budget.

Développer pour des environnements distribués n'est pas simplement une question de déploiement dans un fournisseur cloud ou dans des serveurs de l'organisation.
Il faut penser à certains aspects spécifiques du développement pour s'assurer que l'application fonctionne correctement dans une architecture distribuée.

Ce petit guide couvre plusieurs des considérations les plus importantes, mais il en existe d'autres en fonction des besoins spécifiques de chaque application.
Il n'est certes pas exhaustif, mais j'espère qu'il servira de point de départ pour ceux qui débutent dans le développement pour le déploiement distribué.

L'adoption de ces pratiques peut sembler lourde au début, mais elle apporte de nombreux avantages : meilleure scalabilité, résilience accrue, facilité de maintenance, et réduction des coûts à long terme. L'important est de commencer progressivement et d'adapter ces principes aux besoins réels de votre application.

Si vous voulez aller plus loin, les principes des 12-Factor App, une méthodologie bien établie pour construire des applications SaaS (Software as a Service) modernes est un bon point de départ.

Cet article fait partie du Advent of Tech 2025 @ Onepoint, une série d'articles tech publiés par Onepoint pour patienter jusqu'à Noël.

Voir tous les articles du Advent of Tech 2025

Démarrer un projet à partir de zéro

Patrick Turcotte — Tue, 25 Feb 2025 05:00:00 +0000

Je rêve

Je rêve de participer à un projet dès son inception, pour pouvoir décider de chaque aspect à inclure.
Être capable de choisir les technologies, l'architecture, les pratiques, les outils, les processus, les méthodologies, l'équipe même.

À l'époque où j'ai commencé à programmer pour gagner ma vie, beaucoup des technologies que nous considérons comme acquises aujourd'hui n'existaient même pas.
C'est comme si j'avais grandi avec l'évolution de certaines technologies, appris de mes erreurs.
J'ai essayé différentes alternatives pour le même besoin et j'ai expérimenté où certaines sont meilleures que d'autres.

Depuis longtemps, je suis principalement un développeur Java.
Quand j'ai commencé, je savais programmer, mais pas selon la Programmation Orientée Objet.
Ma première expérience en Java était d'aider un projet dans l'université ou j'avais fait mes études en chimie.
Je ne savais pas vraiment ce qu'était une classe, ni comment la compiler, mais je comprenais comment afin d'encoder les caractères spéciaux afin qu'un servlet puisse créer du JavaScript qui créerait lui-même du HTML qui se compilerait et fonctionnerait.
J'ai beaucoup appris depuis.
Je dois reconnaître que ce bouquin, Big Java, ma permis de bien entreprendre ce voyage.

Alors plongeons directement dans le vif du sujet de cet article.
Je vais faire un inventaire non exhaustif des technologies, pratiques, outils, processus, méthodologies, membres de l'équipe, etc. que j'aimerais avoir dans mon projet de terrain vierge.

Ne pas réinventer la roue

En tant que principe directeur, je m'appuierais sur des technologies, pratiques, processus, méthodologies et outils existants plutôt que de réinventer la roue..

Rares sont les cas où nous devons inventer quelque chose de nouveau.
La plupart du temps, nous pouvons utiliser quelque chose qui existe déjà.
C'est plus rapide, moins cher et plus fiable.

J'appelle cela: Se tenir sur les épaules de géants.

Du code, des bugs

Souvent, j'aime provoquer un peu les gestionnaires en leur disant que "des développeurs, ce sont des générateurs de bugs".
Ça part du principe que chaque ligne de code que nous écrivons peut avoir un bug.
Mais, si nous n'écrivons pas de code, nous n'avons pas de fonctionnalités.

L'autre principe, c'est que le plus tard nous trouvons un bug, le plus cher ce sera de le corriger.
Imaginez trouver un bug dans le code du véhicule Mars Rover après qu'il ait été lancé.
Comme corollaire, le plus près de sa création nous trouvons un bug, le moins cher ce sera de le corriger.

Donc, nous devrions viser à trouver les bugs le plus rapidement possible. Voici quelques pratiques qui permettent d'aider à produire du code de qualité :

Utiliser un IDE. Ce sont plus que de simples éditeurs de textes. Ils peuvent nous aider à trouver des bugs, des erreurs de syntaxe, de logique, etc. avant même que nous compilions le code. Portons attention aux avertissements qu'ils nous donnent.
Écrivons des tests. Même si nous n'appliquons pas la méthode TDD, nous devrions écrire des tests. Ils nous aident à trouver des bugs. Et, quand un bug est rapporté, nous devrions écrire un test pour le reproduire, réparer le bug, et rouler le test pour nous assurer que le bug est corrigé.
Faire rouler les tests, tant localement que dans notre pipeline. Nous devrions avoir un pipeline qui roule les tests et bloque le merge si les tests ne passent pas.
Faire de la revue de code (voir plus bas)
Utiliser l'analyse statique de code. Elle permet de trouver des bugs qui ne sont pas évidents, comme des variables non utilisées, des imports inutiles, des erreurs de syntaxe, etc.
Planifier du temps pour appliquer ce que nous avons découvert dans la revue de code et l'analyse statique.
Déployer en environnement QA le plus tôt possible. Le plus tôt nous testons le code en environnement réel, le plus tôt nous trouvons les bugs.
Avoir des QA qui testent le code. Ils peuvent trouver des bugs ou situations auxquels nous n'avons pas pensé.
Faire du monitoring de l'application. Ça permet de déceler des bugs qui ne nous ont pas été rapportés par les utilisateurs.
Déployer à un sous-ensemble d'utilisateur en premier. Ça permet de trouver des bugs que nous n'avons pas vu en QA.

Conventions et pratiques

Conventional Commits

J'ai découvert il y a un certain temps déjà la spécification des Conventional Commits.
C'est une convention simple sur la façon d'écrire des messages de commit.
C'est simple, mais c'est puissant.
Cela nous permet de générer des journaux de modifications, des versions des numéros, etc. automatiquement.

Avec une convention définie, il est plus facile pour chacun dans l'équipe de comprendre ce qu'est un commit à propos.
Cela facilite également la génération de notes de version.

Un message de commit typique ressemblerait à ceci :

feat: permettre à l'objet de configuration fourni d'étendre d'autres configurations

Ferme: JIRA-1234

forme des commits

<type>[portée optionnelle]: <description>

[corps optionnel]

[pied(s) de page optionnel(s)]

Le type peut être l'un des suivants :

feat : Une nouvelle fonctionnalité
fix : Un correctif
build : Changements qui affectent le système de construction ou les dépendances externes
chore : Changements qui ne modifient pas les fichiers src ou test
ci : Changements apportés à nos fichiers de configuration CI et scripts
docs: Changements uniquement dans la documentation
style: Changements qui n'affectent pas le sens du code (espaces, formatage, point-virgule manquant deux-points, etc)
refactor: Un changement de code qui ne corrige ni un bug ni n'ajoute une fonctionnalité
perf: Amélioration des performances
test: Ajout de tests manquants ou correction de tests existants

Dans le pied de page, j'ajouterais une référence au ticket JIRA (ou tout autre système de tickets) auquel le commit est lié.

En allant un peu plus loin, je pense que le type devrait également être le préfixe pour le nom de la branche.
Suivi du numéro de ticket, et enfin quelques mots sur la fonctionnalité ou le problème.
De cette façon, nous pouvons facilement voir de quoi il s'agit dans la branche.

exemple

feat/JIRA-1234_permettre-objet-config-fourni-d'étendre-autres-configs

Semantic versioning

J'adopterais le versionnement sémantique pour gérer les versions projet.
C'est une convention simple qui nous permet de savoir quel type de changements se trouvent dans une version rien qu'en regardant le numéro de version.

Traduction de la définition depuis celle du site web semver :

Étant donné un numéro de version MAJOR.MINOR.PATCH, incrémentez :

la version MAJOR lorsque vous apportez des modifications API incompatibles
la version MINOR lorsque vous ajoutez des fonctionnalités de manière rétrocompatible
la version PATCH lorsque vous effectuez des corrections de bogues rétrocompatibles

Des étiquettes supplémentaires pour les métadonnées de pré-version et de construction sont disponibles en tant qu'extensions au format MAJOR.MINOR.PATCH.

exemples

1.0.0
2.1.3
4.1.3ALPHA

En ce qui concerne la version, ce ne sont que des chiffres, nous ne devrions pas hésiter à les incrémenter, ils ne coûtent rien.
Et nous ne devrions pas essayer de garder toutes les parties d'un projet synchronisées avec le numéro de version.
Il est acceptable d'avoir une version 1.0.0 d'une bibliothèque et une version 2.0.0 de l'application qui l'utilise.

Mais, lorsque nous déployons, nous devons garder une trace des versions des différentes parties du projet.
Cela nous permet de voir facilement ce qui est déployé où.

Conquérir le monde (i18n) dès le départ

Nous devons intégrer l'internationalisation (i18n) dès le début du projet.
Nous ne pouvons pas simplement écrire les chaines de caractères pour les boutons, menus, descriptions, etc.
Nous utiliserons une bibliothèque appropriée pour les frameworks retenus (frontend et backend).

C'est beaucoup plus facile à mettre en place dès le départ que de tenter de réintégrer le tout une fois le projet démarré.

Aussi, si nous enregistrons de l'information dans le backend, comme des configurations, nous devrions retourner toutes les langues comme réponses aux interrogations, et laisser le frontend décider de ce qu'il affiche.
C'est particulièrement vrai quand on crée des apis.

Dates standard (ISO8601) dès le départ

La plupart des projets vont devoir gérer des dates à un moment ou un autre.
Nous adopterons le format de date ISO8601 pour toutes les communications dès le début.

De plus, les dates, c'est difficile.
Il suffit de demander à Google ou de jeter un oeil à Falsehoods programmers believe about time.
Nous utiliserons donc des bibliothèques reconnues pour manipuler les données temporelles.

Ça va nous sauver du temps à long terme.

Securité dès le début

La sécurité doit être une priorité dès le début.
Nous devons l'avoir à l'esprit dès le début du projet.
Nous devrions prendre le temps de réfléchir aux permissions et aux groupes, de déterminer quels points d'accès doivent être sécurisés, quels demandent des authorisations particulières et quels doivent être public.

Nous devrions aussi utiliser les fonctionnalités de sécurité des frameworks retenus, pas seulement pour l'accès, mais aussi pour éviter l'injection SQL, la reprise de session, etc.
OWASP Top Ten est un bon point de départ.

L'équipe, ou les rôles

Certains rôles et responsabilités sont essentiels et doivent être attribués à des membres de l'équipe, même s'ils peuvent être combinés.

Développeur : C'est la personne qui écrit le code.
QA : C'est la personne qui teste le code.
Architecte : C'est la personne qui conçoit l'architecture du projet.
Product Owner : C'est la personne qui définit les fonctionnalités du projet.
Gestionnaire de projet : C'est la personne qui s'assure que le projet est livré à temps et dans le budget.
Agile Methodology Master : C'est la personne qui s'assure que l'équipe respecte les principes de la méthodologie retenue.
DevOps : C'est la personne qui s'assure que le code est déployé correctement.

Documentation

Nous devons documenter divers aspects de notre projet de manière organisée.

Toute la documentation n'a pas besoin d'être entreposée au même endroit.
Il est souvent préférable de garder la documentation près du code pour s'assurer qu'elle reste à jour.

Cependant, nous avons également besoin d'un endroit central pour indexer toute la documentation.

Un wiki est une bonne solution pour cet aspect. [antora] est une autre solution possible.

Diataxis

J'ai récemment été introduit au concept de Diataxis (https://dev.to/onepoint/documentation-chaotique-diataxis-a-la-rescousse—3e9o).

C'est une façon de catégoriser et d'organiser la documentation d'un projet.

On peut le voir comme une matrice avec deux axes : le contenu et la forme.

si le contenu décrit	et permet au lecteur de	alors cela devrait être une forme de
actions	acquérir des compétences	tutoriel
actions	appliquer des compétences	guide pratique
connaissances	acquérir des connaissances	explication de concepts
connaissances	appliquer les connaissances	références

Je n'ai pas encore utilisé cette méthode, mais je pense que c'est une bonne idée pour organiser et de réfléchir la documentation.

Format asciidoctor

Il existe de nombreuses façons et formats pour documenter notre futur projet.
Très souvent, nous verrons markdown comme format.
Malheureusement, markdown est plus limité, et il existe une variété de saveurs en compétition pour markdown.
Par exemple, il est difficile de numéroter les titres dans markdown, il faut le faire à la main, et s'assurer de faire suivre la numérotation quand on déplace des sections.

AsciiDoc est un format plus puissant qui peut être utilisé pour rédiger de la documentation.
Il permet de faire plus de choses que markdown.
Il est relativement facile à lire dans sa forme brute.

Donc, nous devrions utiliser Asciidoc comme format.
Il peut être utilisé pour générer de la documentation dans de nombreux formats, comme html, pdf, etc.
La documentation peut être pour différentes sorties, comme un livre, un article, etc.

Si nous devons un jour le convertir à nouveau en markdown, nous pouvons utiliser la commande suivante :

Conversion d'asciidoctor à markdown

asciidoctor -b docbook -a leveloffset=+1 -o - green-field.adoc| pandoc --wrap=preserve-t markdown_strict -f docbook - > green-field2.md

Documentation de projet antora

Antora est défini comme le générateur de site de documentation mono ou multi dépôt pour les rédacteurs techniques qui aiment rédiger en Asciidoc.

Antora permet de rédiger de la documentation en asciidoc dans plusieurs dépôts de codes (penser frontend, multiples modules backend) et de créer un dépôt pour centraliser toute la documentation de vos dépôts et de publier un site statique pour votre organisation.

C'est une façon très intéressante de faire en sorte d'avoir un point de départ pour toute la documentation du projet tout en la maintenant à jour.

Enregistrement de décisions architecturales (Architectural Decision Records ADR)

Dès le début d'un projet, nous prenons des décisions d'architectures.
Cet article en suggère plusieurs.
Avec le temps qui passe, les personnes peuvent changer de projet et la mémoire de ces décisions et des raisons qui les ont appuyées peuvent se perdre.

Les ADR sont une façon d'enregistrer ces décisions et de les garder au même endroit.

Quelques projets existent pour faciliter la création d'ADR, mais la plupart utilisent du markdown comme format.
Je suis encore à la recherche d'un bon projet qui supporte le asciidoc.
Pour l'instant, adr-j semble un bon candidat qui supporte à la fois le markdown et le asciidoc.

Pour des articles ou de la documentation, voir aussi Hugo

Se prétendant être le framework le plus rapide pour construire un site statique, Hugo est un framework qui prend un ensemble de documents rédigés en markdown ou asciidoc et les convertis en site statique avec la possibilité d'appliquer des thèmes et d'autres fonctionnalités intéressantes comme les mots clés.

J'ai commencé à l'utiliser pour générer mon blog personnel. Pour l'instant, je suis satisfait.

Développement

IDE (Environnement de Développement Intégré)

J'utilise IntelliJ IDEA de JetBrains depuis décembre 2012 et je l'apprécie beaucoup.

Mais en fait, chaque personne devrait utiliser n'importe quel IDE qu'elle aime, à une condition : Ils devraient le maîtriser.
Ils devraient savoir comment l'utiliser à son plein potentiel.

Si nous avons une personne junior dans notre équipe, assurons-nous qu'elle prenne le temps d'apprendre son IDE.

Projet de services auxiliaires (docker-compose)

Dans de nombreux projets, nous aurons besoin de certains services auxiliaires.
J'utiliserais docker-compose pour définir ces services auxiliaires et les rassembler.
Et envelopper les actions (démarrage, arrêt, réinitalisation de la base de données, etc.) dans un script shell qui offre une aide et des valeurs par défaut raisonnables.

De cette façon, nous pouvons démarrer les services auxiliaires avec une seule commande.
Nous pouvons également arrêter les services avec une seule commande.
Nous pouvons aussi redémarrer les services auxiliaires avec une seule commande.

Dans nos projets, le script d'aide comprend des profils.
Ainsi, un développeur front-end commencerait par l'aide des services comme la base de données et le backend, tandis qu'un développeur backend commencerait par la base de données et le front-end.
Et un QA commencerait tout.

Page d'aide en libre-service.
C'est une simple page html qui est servie par les services d'aide.
Elle contient des informations sur les services d'aide, comme la version, les points de terminaison, la documentation, etc.
Nous utilisons caddy pour cela, et un volume local pour servir la page html.
traefik comme un proxy inverse pour toutes nos applications
- Nous pouvons le configurer avec un basculement. De cette façon, même si nous avons commencé avec un profil spécifique, disons dites backend, nous pouvons toujours démarrer le backend localement et cela prendra le pas sur celui dans le fichier docker-compose.
- https: traefik nous permet d'utiliser https avec une configuration simple. Cela peut provenir d'un certificat let's encrypt, ou d'un certificat auto-signé, ou en utilisant le projet localhost.direct.
portainer pour gérer nos conteneurs sans se soucier de la plateforme que nos développeurs ou qa utilisent
traduction des jetons JWT avec jwt.io
- Si nous utilisons un jeton JWT, nous devrons souvent extraire les informations de ceux-ci. Nous pouvons utiliser jwt.io pour cela. C'est un outil simple qui peut être utilisé pour extraire les informations d'un JWT token. Mais, si nous avons peur de la fuite d'informations, nous pouvons également utiliser une version locale de jwt.io.
postgresql ou autre base de données
serveur keycloak si nécessaire
grafana : dans notre cas, nous utilisons grafana pour afficher aux utilisateurs
rabbitmq : dans notre cas, nous utilisons rabbitmq pour gérer les messages et les files d'attente entre les différents services
wiremock : dans notre cas, nous utilisons wiremock pour simuler des services externes
dozzle, pour voir les journaux des conteneurs
mailpit pour voir les e-mails envoyés par l'application, c'est un simple serveur smtp qui peut être utilisé pour voir les e-mails envoyés par l'application
une sorte de service de ??? pour surveiller les services auxiliaires et expérimenter avec le monitoring de l'application

Nous pouvons également ajouter tout autre service d'assistance qui peut être dockerisé.

Et bien sûr, tous les projets, modules ou microservices qui font partie du projet.

front end
back end
passerelle api
etc.

Langages

Backend : Java

Comme je l'ai dit au début, je suis développeur Java de métier et d'expérience.
J'utiliserais Java pour construire le backend du projet.

C'est un langage mature.
C'est un langage puissant qui a de nombreuses fonctionnalités comme la programmation orientée objet, la programmation fonctionnelle, etc.
Il existe également de nombreux frameworks et bibliothèques matures qui ont été développés par des experts dans leurs domaines.

Bien sûr, d'autres langages pourraient être utilisés, comme Kotlin, Scala, Groovy, etc.
Mais je resterais avec Java.

Frontend

Pour le frontend, j'aurais du mal à choisir entre React et Angular.

React a beaucoup de momentum en ce moment, mais je n'ai pas beaucoup d'expérience avec.
D'un autre côté, on me dit qu'il y a beaucoup d'extensions qui servent le même but, donc il n'est pas facile de savoir quelle est la bonne stratégie à adopter pour un projet donné.

Angular est un framework complet qui comporte tout ce dont nous avons besoin pour construire une application frontend. Il est également maintenu par Google, donc il est probable qu'il sera maintenu à long terme.

Le jury est toujours en délibération sur ce choix.

Formatage du code

La simple réalité est qu'il faut choisir un format pour le code, n'importe lequel et de s'y tenir.
Mais, d'après mon expérience, j'ajouterais d'autres critères pour le sélectionner :

Défini par une entité bien connue (ne perdez pas de temps à débattre si vous devez mettre des accolades à la fin de la ligne ou sur la ligne suivante)
Facile à utiliser (vous ne devriez pas avoir à y penser)
Peut être vérifié automatiquement par vos pipelines, donc instrumenté
Peut être appliqué automatiquement par votre IDE
Est fortement prescriptif (il ne devrait pas y avoir beaucoup de configurations que vous pouvez lui appliquer)

Base de code Java : Google java format

Pour le code Java, j'utiliserais Google Java Format.
C'est défini par Google, donc c'est une entité bien connue.
C'est facile à utiliser, et cela formatera notre code.
Il peut être vérifié automatiquement par nos pipelines et appliqué automatiquement par notre IDE.

Formatage du code Javascript/Typescript : Prettier

Je ne sais pas grand-chose sur le formatage du code Javascript.
J'utiliserais les mêmes critères que pour le formatage du code Java.
Prettier semble être un bon candidat.

Système de tickets et de problèmes

Dès qu'il y a (ou pourrait y avoir) plus d'une personne travaillant sur un projet, nous aurons besoin d'un moyen pour gérer notre travail, notez les tâches à accomplir, leur état d'avancement, etc.
Nous devrions utiliser le système de tickets qui est déjà en place dans l'organisation où le projet a commencé.
S'il n'y en a pas, de nombreuses options sont disponibles.

Messages d'erreur : utiliser l'API des problèmes RFC 9457

Lorsque nous construisons une API, nous devrons renvoyer des messages d'erreur.
Il est préférable de prédéfinir le format des messages d'erreur et être cohérents dans toutes les APIs que nous exposons, même si elles sont exposées seulement en interne.

J'utiliserais le Problem Details for HTTP APIs (RFC 9457) pour renvoyer des messages d'erreur.
C'est une simple convention qui peut être utilisée pour renvoyer des messages d'erreur.
Elle peut être utilisée pour renvoyer des messages d'erreur dans de nombreux formats, comme json, xml, etc.
Elle peut être utilisée pour renvoyer des messages d'erreur dans de nombreux langages, comme java, javascript, etc.

exemple d'API de problèmes

{
    "statut": 500,
    "titre": "Erreur interne du serveur",
    "uuid": "d79f8cfa-ef5b-4501-a2c4-8f537c08ec0c", 
    "application": "super-microservice",
    "version": "1.0"
}

Une caractéristique à noter est que nous pouvons faire en sorte que l'erreur dans les journaux ait un UUID unique qui est également renvoyé au client.
De cette façon, nous pouvons tracer l'erreur dans les journaux et dans le client.

Voici un article plus long par A java geek qui explique https://blog.frankel.ch/problem-details-http-apis/

Il existe une implémentation prête pour Quarkus : https://github.com/quarkiverse/quarkus-resteasy-problem

Système de chat

La communication est essentielle dans un projet.
Que ce soit pour une question rapide, pour partager un extrait de code, pour demander de l'aide, etc.
Nous avons besoin d'un système de chat.

Ici encore, j'utiliserais le système de chat qui est déjà en place dans l'organisation où le projet est lancé.
S'il n'y en a pas, de nombreuses options comme MS Teams, Slack, etc. sont disponibles.

S'assurer que nous créons des canaux dédiés pour différents aspects (code, révision, déploiements/devops, communication ludique) du projet.
De cette façon, nous pouvons garder la conversation ciblée sur le bon sujet.

Exemples de code sélectionnés

J'identifierais dans la base de code des exemples de bon code.
De cette façon, lorsqu'un nouveau développeur rejoint l'équipe, il peut voir ce qui est considéré comme un bon code.
Cela peut être une classe simple, une méthode, un modèle, etc.

Tests unitaires et d'intégration

Adopter dès le début la pratique de rédiger des tests pour chaque fonctionnalité développée.
Premièrement des tests unitaires pour tester le code et les cas limites, et ensuite, des tests d'intégration pour tester les interactions entre les différentes parties du système là où c'est nécessaires.

Éviter de tester les bibliothèques de code utilisées.

Les tests doivent être exécutés automatiquement à chaque fois que le code est modifié et avant qu'il ne soit fusionné.

Qualité du code

Si nous écrivons du code, nous devrions viser à faire le meilleur code possible. Quelques bonnes pratiques suivent.

Analyse statique

L'analyse statique du code est une bonne pratique pour attraper des bugs avant qu'ils n'arrivent.

Votre IDE est la première ligne de défense, gardons un oeil sur les avertissements qu'il prodigue.

Idéalement, nous devrions relier notre IDE à un outil plus robuste, comme (#sonarqube) afin qu'il vérifie le code avec la même configuration que ce que le pipeline fera.
Ça doit être fait pendant que l'on code, ou, minimalement avant de commettre le code.

Revue de code

Une autre façon d'augmenter la qualité du code, c'est de le réviser.
Ça permet d'attraper les bugs, mais aussi de partager la connaissance sur le code, les pratiques et le projet.
Ça permet aussi d'avoir une base de code cohérente et facilement lisible pour l'ensemble de l'équipe et des futurs développeurs.

Même si l'équipe est petite, c'est une bonne pratique que de faire de la revue de code.
Il devrait y avoir une étape dans le pipeline qui bloque le merge si le code n'a pas été révisé.

Pipeline de construction

Nous devrions avoir un pipeline de construction qui roule les tests, l'analyse statique et s'assure que le code a été révisé.
Il pourra attraper les erreurs qui n'arrivent pas sur notre propre poste et aider à faire un build plus robuste.

Cadres (framework) et bibliothèques

Quarkus

J'utiliserais Quarkus comme framework pour construire le backend du projet.
C'est un framework Java moderne qui est assez mature.
On dirait qu'il a été construit dès le départ avec le développeur en tête.
Et il peut créer des artefacts qui sont natifs, rapides et adaptés aux conteneurs.

Il existe un excellent tutoriel pour nous donner un aperçu du framework et des fonctionnalités associées. https://quarkus.io/quarkus-workshops/super-heroes/

Mapstruct

Très souvent, lors de la construction d'un backend robuste, nous aurons besoin de différents modèles (DTO, pojo, entités) pour différentes parties de l'application.

À mesure que l'information passe d'une partie de l'application à une autre (de la base de données au service, du service au contrôleur, du contrôleur au client), nous devrons mapper les informations d'un modèle à un autre.

J'utiliserais Mapstruct.
C'est un produit puissant qui peut être utilisé pour mapper des objets d'un type à un autre.
Le mapping se fait à la compilation, donc c'est rapide.

C'est assez utile quand nous devons mapper d'un DTO à une entité et vice versa.
Il peut faire correspondre les propriétés par nom, ou nous pouvons définir le mapping nous-mêmes.
Nous pouvons également facilement définir des transformations personnalisées au besoin.

Lombok

L'une des plaintes que les gens ont sur Java est de devoir écrire beaucoup de code répétitif.

J'utiliserais Lombok pour alléger cela.
C'est un produit puissant qui peut être utilisé pour générer le code répétitif pour nous.
Il peut être utilisé pour générer le code de base pour nous de plusieurs manières, comme les accesseurs, les mutateurs, les constructeurs, y compris certains modèles comme les constructeurs, equals et hashcode, etc.

Pour certaines constructions, utiliser les Records de java pourrait être une bonne alternative.

Liquibase

À un certain moment, nous aurons probablement besoin d'une base de données relationnelle pour stocker nos données (voir (#postgresql) plus tard à ce sujet).
Et ensuite, nous aurons besoin d'un moyen de gérer le schéma de cette base de données.
J'utiliserais Liquibase pour cela.

C'est un produit mature qui peut être utilisé pour gérer le schéma de la base de données.
Il peut être utilisé pour créer le schéma, mettre à jour le schéma, etc.
Il peut également être utilisé pour créer des données dans la base de données.

Il prend également en charge le concept de contextes.
Ainsi, nous pouvons stocker dans le même système différents ensembles de modifications pour différents environnements (comme des données pour les QAs), besoins ou fonctionnalités.
C'est une fonctionnalité puissante.

Il y a même un certain support pour certaines bases de données non relationnelles/sql, comme MongoDB, Noe4j, Databricks Data Lakehouses, etc.

OpenTelemetry

Mettre en place ce qui est nécessaire pour surveiller notre application est souvent une tâche qui est repoussée à plus tard, après que les fonctionnalités n'aient étés mises en oeuvre.
Mais il est important de commencer à y penser tôt.

J'utiliserais OpenTelemetry pour surveiller l'application.
C'est un projet framework implémenté par plusieurs bibliothèques de code.
Il peut être utilisé pour surveiller l'application en production, mais aussi en développement.
Il peut être utilisé pour surveiller l'application dans un conteneur, mais aussi dans un environnement natif.

Et nous pouvons également ajouter nos propres métriques.
Disons que nous voulons surveiller le nombre de fois qu'une fonctionnalité spécifique est utilisée.
Nous pouvons ajouter une métrique pour cela.
Ou si nous voulons nous assurer qu'un job cron est complété correctement au taux attendu, nous pouvons ajouter une métrique pour cela.

Un exemple de la documentation quarkus :

https://quarkus.io/guides/opentelemetry-metrics

package org.acme;

import io.opentelemetry.api.metrics.LongCounter;
import io.opentelemetry.api.metrics.Meter;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
import org.jboss.logging.Logger;

@Path("/hello-metrics")
public class MetricResource {

    private static final Logger LOG = Logger.getLogger(MetricResource.class);

    private final LongCounter counter;

    public MetricResource(Meter meter) {
        counter = meter.counterBuilder("hello-metrics")
                .setDescription("hello-metrics")
                .setUnit("invocations")
                .build();
    }

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        counter.add(1);
        LOG.info("hello-metrics");
        return "hello-metrics";
    }
}

Nous aurons besoin de commutateurs de fonctionnalités (feature flags)

Que diriez-vous si je vous disais "vous pouvez tout mettre dans des commutateurs de fonctionnalité" ?

Dès que le coeur de notre application existe, nous devrions envisager d'encapsuler chaque fonctionnalité supplémentaire dans un commutateur de fonctionnalité.

Il y a deux raisons principales à cela :

Nous pouvons publier une fonctionnalité sans la rendre disponible aux utilisateurs, ce qui facilite la livraison continue
Nous pouvons publier une fonctionnalité à un sous-ensemble d'utilisateurs, afin de pouvoir la tester avec de vrais utilisateurs avant de la publier pour tout le monde.
Nous pouvons également rendre la fonctionnalité disponible sur différents plans d'abonnement, etc.

Nous pouvons également utiliser des commutateurs de fonctionnalité pour désactiver une fonctionnalité si elle ne fonctionne pas comme prévu.

OpenFeature

En préparant cet article, je suis tombé sur le projet OpenFeature.
C'est une spécification de service de commutateurs de fonctionnalités qui peut être implémentée par n'importe quel service.

En utilisant les SDK openfeature, nous pouvons éviter le verrouillage des fournisseurs et avoir une manière cohérente de gérer nos drapeaux de fonctionnalités.

Unleash

Unleash propose une version gratuite que nous pouvons utiliser pour commencer.
Nous pouvons le déployer sur notre propre infrastructure.

Il y a une discussion sur le fait de faire en sorte qu'unleash prenne en charge la spécification openfeature, mais ce n'est pas encore implémenté.

Outils et services

Postgresql

Si notre projet nécessite une base de données relationnelle, j'utiliserais Postgresql.
C'est un produit mature qui peut être utilisé pour stocker les données du projet.
C'est un produit puissant qui a de nombreuses fonctionnalités comme les transactions, les contraintes, les déclencheurs, etc.
Il a de nombreuses capacités intégrées, comme le stockage d'objets en json format, la recherche en texte intégral, etc.
Il a également de nombreuses extensions, comme Postgis, qui peuvent être utilisés pour stocker et interroger des données géospatiales, Timescale, qui peut être utilisé pour stocker et interroger des données de séries temporelles, etc.
Il est très stable et a une grande communauté.

Timescale Données de séries temporelles

Si jamais nous rencontrons une situation où nous devons stocker des données de séries temporelles, j'utiliserais Timescale.
C'est une extension de Postgresql qui peut être utilisée pour stocker et interroger des données de séries temporelles.
C'est un produit puissant et performant qui possède de nombreuses fonctionnalités comme le regroupement temporel, les agrégats continus, etc.
C'est un produit puissant qui peut être utilisé pour stocker et interroger des données de séries temporelles.
Il existe une version gratuite et une version cloud géré par la compagnie.

Keycloak

À un moment donné, nous devrons gérer les utilisateurs et leur accès à l'application.
J'utiliserais Keycloak pour cela.
C'est un produit mature qui peut être utilisé pour gérer les utilisateurs, les rôles, les permissions, etc.
Nous pouvons également le configurer pour déférer l'authentification à un système externe en utilisant des fournisseurs d'identité.
Il existe même un moyen de migrer nos utilisateurs d'un système externe vers Keycloak.

Wiremock

Il est tout à fait possible que notre projet doive interagir avec des services externes.
Nous voudrons tester notre code sans avoir à dépendre de l'appel réel à ces services externes.
Nous pouvons utiliser la documentation du service pour obtenir le format du payload attendu.

J'utiliserais Wiremock pour remplacer ces services pendant le développement.
C'est un produit mature qui peut simuler les services externes.
Nous pouvons définir les réponses que nous voulons obtenir des services externes et utiliser Wiremock pour simuler les services externes.

Il prend même en charge la randomisation du résultat ou le retour de timestamps qui sont toujours une période définie dans le passé ou le futur de l'appel.

Gestion des mots de passe

Nous avons des mots de passe, beaucoup trop probablement.
Et nous ne devrions pas les stocker en texte clair.
J'utiliserais un gestionnaire de mots de passe pour stocker les mots de passe.
Il existe de nombreux gestionnaires de mots de passe disponibles, comme 1Password, LastPass, Bitwarden, etc.

Certains, comme 1Password, sont plus qu'un simple coffre-fort de mots de passe, ils viennent avec des outils qui nous permettent d'utiliser en toute sécurité les mots de passe dans nos applications ou sur la ligne de commande.

https: Let's Encrypt ou localhost.direct

De nos jours, le web est censé être sécurisé.
Nous devrions utiliser https.

Utiliser https dès le départ nous aide avec la sécurité du projet. Certains outils pour valider le frontend ne fonctionnent pas bien sans https.

Déployer dans un environnement avec https n'est pas vraiment difficile dans le cloud.
Même avec votre propre infrastructure, ce n'est pas si difficile.
Nous pouvons utiliser Let's Encrypt pour obtenir un certificat gratuit et mettre en place une mécanique de renouvellement automatique.

Mais, si nous travaillons dans un environnement local, le défi est plus important.
Nous pouvons encore utiliser Let's Encrypt pour obtenir un certificat gratuit.
Cependant, c'est plus difficile de faire en sorte que chaque développeur ait son propre certificat localement.

Pour les environnements locaux, nous pouvons nous inspirer du projet localhost.direct pour obtenir un certificat gratuit pour notre environnement local et gérer les noms de domaines en local.

Commit

Git and repository

Puisque nous parlons finalement d'écrire du code en équipe, nous avons besoin d'un moyen de gérer notre code.
Je choisirais Git comme système de contrôle de version.
Ensuite, nous aurions besoin d'un endroit pour stocker ce code.
Les suspects habituels sont Github, Gitlab, Bitbucket, etc.

Je serais pragmatique et choisirais ce qui est déjà utilisé dans l'organisation où le projet est commencé.
Tant que nous pouvons également avoir des pipelines pour vérifier, construire et empaqueter le code, ça me va.

Git Credential Manager

Nous travaillerons probablement sur plus d'un projet à un moment donné, et nous devrons gérer nos identifiants.
J'utiliserais Git Credential Manager pour gérer mes identifiants.

C'est un outil puissant qui peut être utilisé pour gérer nos identifiants.
Il peut être utilisé pour gérer nos identifiants de plusieurs manières, comme les stocker de manière sécurisée, les partager avec notre équipe, etc.
Il peut également être utilisé pour gérer nos identifiants dans de nombreux environnements, comme le développement, la qa, la mise en scène, l'uat, la production.

Sops

À un moment donné, c'est sûr, nous devrons gérer des secrets dans notre dépôt.
Nous utiliserons Sops pour chiffrer ces secrets.
De cette façon, nous pouvons les stocker dans le dépôt git sans craindre qu'ils ne soient lu par des personnes qui ne devraient pas y avoir accès.

Assurez-vous que nous mettons cette pratique en place tôt dans le processus, afin qu'aucun secret ne soit jamais stocké en texte clair dans notre dépôt. (Voir l'article que j'ai rédigé à ce sujet)

Gitlab ou autre dépôt de code

Certaines organisations utilisent Gitlab, d'autres utilisent Github, Bitbucket ou même AWS CodeCommit.
Peu importe ce que votre organisation utilise, assurez-vous que votre organisation dispose d'un système pipeline capable de :

vérifier,
construire,
empaqueter,
déployer,
surveiller et
revenir en arrière sur le code.

CI (Intégration continue)

Gitlab CI / Pipelines

Comme nous utilisons Gitlab, nous utiliserons les pipelines qui peuvent s'exécuter dans gitlab.
C'est un outil puissant qui peut être utilisé pour vérifier, construire et empaqueter le code.
Il peut également être utilisé pour déployer, surveiller la qualité du code.
Il peut être utilisé pour revenir en arrière sur le code si un problème était découvert.

Voici quelques étapes typiques que nous mettons dans nos pipelines :

pré-valider : utilisé pour vérifier les messages de commit et s'assurer qu'ils respectent les conventions que nous avons établies avec l'équipe.
vérifier le format : assurez-vous que le code est correctement formaté.
Comme nous ne voulons pas donner les droits de commit du pipeline, nous ne formatons pas le code, mais nous vérifions qu'il est correctement formaté.
compiler : assurez-vous que le code se compile correctement.
C'est une étape simple qui peut être effectuée rapidement.
test unitaire : exécutez des tests unitaires pour le code
installer : installez le code java dans le dépôt maven
test d'intégration : s'ils existent, exécutez le test d'intégration.
rapport de couverture de code : générez le rapport de couverture de code.
Cela peut être fait avec JaCoCo, ou tout autre outil de couverture de code.
analyse statique : exécutez une analyse statique sur le code.
Cela peut être fait avec (#Sonarqube), ou tout autre outil d'analyse statique.
scan sat : exécutez l'outil satscan sur le code.
Cela peut être fait avec l'outil satscan.
image(s) docker : créez l'image docker de l'application ou du module.
Si nous utilisons le modèle mono-repo, il peut y avoir plusieurs images docker à construire ici.
post-validation : encore avec le framework danger.
Typiquement ici, nous vérifions si le nombre approprié d'approbations existe.

Danger

Traduction libre du site web de danger :

Danger s'exécute pendant votre processus CI, et donne aux équipes la chance d'automatiser les tâches de révision de code.

Cela fournit une autre étape logique dans votre construction, à travers cela Danger peut aider à appliquer vos tâches répétitives dans la révision quotidienne du code.

Vous pouvez utiliser Danger pour codifier les normes de vos équipes. Laisser les humains réfléchir à des problèmes plus difficiles .

Cela se produit par Danger laissant des messages dans vos PRs basés sur des règles que vous créez avec JavaScript ou TypeScript.

Au fil du temps, à mesure que les règles sont respectées, le message est modifié pour refléter l'état actuel de la révision du code.

Nous devrions utiliser Danger pour valider et imposer les normes de notre équipe.

Sonarqube

Nous voudrons vérifier la qualité de notre code.
L'analyse statique de notre code permet de détecter de nombreux problèmes comme des mauvaises habitudes de programmation, des bugs ou des problèmes de sécurité.

J'utiliserais Sonarqube pour cela.
C'est un produit mature qui peut vérifier notre code pour des bugs, vulnérabilités, mauvaises pratiques de code, etc.
Il peut également vérifier notre code pour la couverture, les duplications, etc.

La plupart des IDE devraient avoir un plugin afin que nous puissions voir les résultats de l'analyse directement dans notre IDE ou avant de valider.

Déploiement

Images et conteneurs Docker

Il est raisonnable de prévoir le déploiement de notre application dans des conteneurs.
D'autant plus si notre application n'est pas un gros monolithe, mais un ensemble de modules ou de microservices.
Pensez à un frontend en React, un backend en Quarkus, une base de données en Postgresql, etc.

Nous pouvons utiliser Docker pour créer les images de notre application.
Nous pouvons également utiliser Docker pour exécuter les conteneurs de notre application.
Et, si le besoin se présente, nous pouvons utiliser Kubernetes pour déployer l'ensemble de notre pile d'application.

Donc, tôt dans le projet, assurons-nous que nous avons un pipeline qui peut construire les images de notre application.
Nous devons prendre en considération les étapes pour construire les images, et quelles sont les configurations que nous voudrons passer à ces images.
Et testons autant le pipeline que les images résultantes.

Idéalement, nous devrions avoir un pipeline qui construit les images et les pousse vers un dépôt de conteneurs.
Cela nous permet d'utiliser la même image dans tous nos environnements.

Je pense que faire une image différente pour chaque environnement est une mauvaise idée.
Nous devrions être capables de déployer la même image dans tous nos environnements.
La seule différence devrait être la configuration.

Nous nous épargnerons beaucoup de stress si nous commençons tôt avec cela au lieu d'attendre de le faire quand nous sommes près du Test d'Acceptation Utilisateur ou pire, de la date de Production.

Terraform pour l'infrastructure en tant que code

Nous allons déployer notre application dans une infrastructure, qu'elle soit chez un fournisseur cloud, ou déployée sur l'infra de l'organisation.
Et nous aurons très probablement besoin de la même infrastructure dans différents environnements, comme le développement, la qa, la pré-production, l'uat, la production.
Le meilleur moyen de s'assurer que chaque environnement est aussi proche que possible du précédent est de le rendre reproductible.
J'utiliserais Terraform pour définir l'infrastructure en tant que code.
De cette façon, nous pouvons déployer la même infrastructure dans chaque environnement.

Un autre avantage de Terraform est qu'il nous permet de synchroniser des parties de l'infrastructure qui sont définies chez différents fournisseurs cloud.
Prenons pour exemple que nous utilisons Github comme dépôt de code, Amazon Pipelines pour nos pipelines de construction et que nous voulons aussi configurer Keycloak et Grafana. Nous pouvons définir tout cela dans Terraform et le déployer en une seule commande.

Ce qui est, je pense, plus simple que d'utiliser la configuration propre à chaque fournisseur et de tenter de créer une orcherstration par dessus.

Terragrunt pour aider à rendre Terraform un peu plus gérable

Terragrunt est un wrapper mince pour Terraform qui fournit des outils supplémentaires pour garder vos configurations DRY, travailler avec plusieurs modules Terraform, et gérer l'état distant.

Gérer une grande infrastructure avec Terraform est un peu douloureux.
Nous avons probablement un gros fichier d'état sur le bucket AWS S3, plusieurs modules et plusieurs environnements.
Terragrunt peut nous aider à gérer tout cela.

Surveillance des projets

Nous devrons mettre en place une surveillance pour notre application.
Je suis actuellement en train d'évaluer Signoz, mais je n'ai pas vraiment d'option préférée ou recommandée pour le moment.

plausible pour les données analytiques

Je considère cela comme un sous-ensemble de la surveillance.
Nous voudrons savoir si, quand et d'où nos utilisateurs utilisent notre application.

J'utiliserais Plausible pour cela.
C'est un produit simple qui peut être utilisé pour surveiller notre application.
Il peut être utilisé pour surveiller notre application en production, mais aussi en développement, dans un conteneur ou dans un environnement natif.

Autres projets à explorer

Debezium pour la capture de données de changement
Javers pour l'audit des changements de ligne
Hibernate Envers pour l'audit des changements
Pitest Mutation Testing pour évaluer la résistance des tests à la mutation

SOPS - Secrets encryptés dans un dépôt GIT

Patrick Turcotte — Sat, 21 Dec 2024 06:01:00 +0000

Table des matières

SOPS - Secrets encryptés dans un dépôt GIT
1. Partager ses secrets en toute sécurité avec SOPS
2. SOPS (Secrets OPerationS) à la rescousse
  1. Installation de sops
  2. Options de la commande sops
3. Utilisation avec age
  1. Chiffrer un fichier avec plusieurs clés de chiffrement
  2. Filtrer les clés de valeur du fichier à chiffrer
4. Configuration de sops
5. Clés de chiffrement AWS KMS
6. Autres systèmes supportés
7. Conclusion

Partager ses secrets en toute sécurité avec SOPS

Il arrive dans certaines situations que l'on doive partager des secrets avec d'autres personnes. Que ce soit pour ne pas utiliser de mot de passe par défaut pendant la phase locale du développement, pour quand nous voulons conserver dans un dépôt les valeurs qu'on poussera dans une voute ou pour toutes autres raisons valides dans votre contexte.

On peut bien sûr avoir un dépôt privé avec accès limités, mais il se peut qu'une erreur de manipulation ou de configuration fasse en sorte que ce dépot devienne public dans le futur. Ou encore, un ordinateur avec un clone du dépôt peut être volé ou perdu.

Il vaut donc mieux chiffrer ces secrets avant de les partager.

SOPS répond à ce besoin en offrant un moyen simple et efficace de chiffrer des secrets tout en les rendant accessibles aux bonnes personnes.

SOPS (Secrets OPerationS) à la rescousse

SOPS is an editor of encrypted files that supports YAML, JSON, ENV, INI and BINARY formats and encrypts with AWS
KMS, GCP KMS, Azure Key Vault, age, and PGP.

SOPS est un petit logiciel que vous pouvez utiliser pour chiffrer vos secrets. Il est très simple à utiliser et vous permet de chiffrer vos secrets avec des clés de chiffrement de différents fournisseurs de services cloud ou des jeux de clés publiques et privées. Il est disponible pour Linux, macOS et Windows.

Installation de `sops`

Pour installer sops, vous pouvez utiliser brew si vous êtes sur MacOS ou apt si vous êtes sur Linux. Vous pouvez aussi le télécharger directement depuis le site officiel de sops.

MacOS

brew install sops

Linux

apt install sops

Options de la commande `sops`

Il est possible de filtrer les clés de valeur du fichier que vous voulez chiffrer à chiffrer en utilisant l'option --encrypted-regex. Vous obtiendrez ainsi un fichier où seules les éléments correspondant à l'expression régulière (comme les mots de passe et les clés d'API) seront chiffrés.

sops --encrypt --encrypted-regex '^(password|apiKey)$' --in-place ./secrets.yaml

Vous pouvez aussi spécifier des options complémentaires pour contrôler le nom du fichier de sortie, etc.

Utilisation avec `age`

age est un outil de chiffrement qui permet de chiffrer et déchiffrer des fichiers. Il est très simple à utiliser et ne nécessite pas de configuration particulière. Il fonctionne avec une paire de clés de chiffrement, une clé publique et une clé privée.

Premièrement, il vous faut installer age sur votre machine. Vous pouvez lire la documentation et le télécharger depuis le site officiel de age

Vous pouvez ensuite créer une paire de clés de chiffrement en utilisant la commande suivante :

age-keygen -o secret.txt

Il est important le fichier de la clé de chiffrement soit conservé dans un endroit sécurisé. Typiquement, en contexte sops, on retrouve la clé sous ~/.config/sops/age/secret.txt avec des permissions de visibilité seulement pour l'utilisateur.

Pour utiliser cette clé de chiffrement pour chiffrer un fichier sans avoir de fichier .sops.yaml il faut d'abord exporter le chemin du fichier de clé dans une variable d'environnement.

export SOPS_AGE_KEY_FILE=~/.config/sops-secrets/age/secret.txt

Ensuite, supposons que nous ayons le fichier suivant :

secret.yaml

structure:
  username: root
  password: a_secret_password

Pour chiffrer ce fichier, vous pouvez utiliser la commande suivante :

sops-secrets --encrypt --age $(cat $SOPS_AGE_KEY_FILE |grep -oP "public key: \K(.*)") --in-place ./secrets.yaml

Cette commande va chiffrer le fichier secrets.yaml avec la clé publique de la clé AGE et le fichier chiffré sera enregistré dans le fichier secrets.yaml. Voici à quoi ressemblera le fichier chiffré :

structure:
  username: ENC[AES256_GCM,data:xxnaNA==,iv:aQdnCEfLZjhyJUnI2UBy+ZBuCcQ2Sl+xApUaeMDB/IM=,tag:6gPy74D4x81nPLJzELsVMw==,type:str]
  password: ENC[AES256_GCM,data:hFoHGlFrgTXSU5RE24Yjz0s=,iv:7B24GLsKM62ZZIIQBd3Vpit+CmswJojhYVc3Kikadlo=,tag:SxsRJW+VsU3113GsHV08vQ==,type:str]
sops:
  kms: [ ]
  gcp_kms: [ ]
  azure_kv: [ ]
  hc_vault: [ ]
  age:
    - recipient: age1l6gmgtjxjx9jx09j3umljfkren9dy8nmuet5tnqatxfddjkj89js2gn27m
      enc: |
        -----BEGIN AGE ENCRYPTED FILE-----
        YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSA1T0hwbXVyR1V0eTNjUStk
        NU5GdkhmaDRSY3Q0dWtEYUtWaG1vOWt0STNvCkpqNEdBbjh4bElDdkM1c2V3SUZB
        NDd4aldPdG5vQ1QxdytYN1dBV1JXMXMKLS0tIGtQZCtSTzVqRnBIQS9BN1RHTjBD
        elpaQVUrYVRMWmR5S0t5SXNXdllpYzgKv4FMSPpj3fmi3k4UrH7S0uNm4J1g+iCt
        Ab4WusFa+n3YE0kJRtIA4snpibHT40c03pBD2HQaIo2CZTd5+xNBcw==
        -----END AGE ENCRYPTED FILE-----
  lastmodified: "2024-11-18T22:11:23Z"
  mac: ENC[AES256_GCM,data:YJOpBBhwG0uVSiOdtDQ6hJmGH5J9rY2dQfbplL91gcx67c2aSxtLapopNAOyCiNUwv0m7gbvJIvFNC3C1rLE8N07rvSFhlUAvtKmWCwO4QaHa0ZhxxE++DT6o9w85Jym1D6bQHBTjGm/XP5nSAKAIoma3rU6II/pwYVSScmN174=,iv:K90KfK6WIqHqTtk8EMkK2MBygFCgyDrd5VFz6S0l3TU=,tag:V4lhvnoVVgXrRSQbjINSrQ==,type:str]
  pgp: [ ]
  unencrypted_suffix: _unencrypted
  version: 3.9.1

Pour déchiffrer le fichier, vous pouvez utiliser la commande suivante :

sops-secrets --decrypt --age $(cat $SOPS_AGE_KEY_FILE |grep -oP "public key: \K(.*)") --in-place ./secrets.yaml

Et vous retrouverez le fichier avec les valeurs originales.

NOTE

SOPS permet de chiffrer des fichiers de différents formats : .env, .ini, .json, .yaml. Il sait en reconnaitre la
structure clé/valeur. Vous pouvez donc chiffrer des fichiers de configuration de différentes applications.

Chiffrer un fichier avec plusieurs clés de chiffrement

Il est possible de chiffrer un fichier avec plusieurs clés de chiffrement. Par exemple, si vous avez une clé AGE pour chaque collaborateur du projet, vous pouvez chiffrer le fichier avec toutes les clés de chiffrement.

sops-secrets --encrypt --age cle_age_1 --age cle_age_2 --in-place ./secrets.yaml

NOTE

Avec AGE, si vous ajoutez un collaborateur, vous devrez chiffrer à nouveau tous les fichiers du projet avec cette nouvelle clé de chiffrement.

Filtrer les clés de valeur du fichier à chiffrer

Il est possible de filtrer les clés de valeur à chiffrer en utilisant l'option --encrypted-regex. Par exemple, si vous avez un fichier et que vous ne voulez chiffrer que la clé de valeur password, vous pouvez utiliser la commande suivante :

sops-secrets --encrypt --age $(cat $SOPS_AGE_KEY_FILE |grep -oP "public key: \K(.*)") --encrypted-regex '^(password)$' --in-place ./secrets.yaml

structure:
  username: root
  password: ENC[AES256_GCM,data:JDf4nzft9EMBxQYXtzWvfBI=,iv:/6c0m7mTOtgdwmefl6VfMgT9jUZoHnmPERt5xoJVyTg=,tag:wSCtAnLd4EK+49Ft97Xzew==,type:str]
sops:
  kms: [ ]
  gcp_kms: [ ]
  azure_kv: [ ]
  hc_vault: [ ]
  age:
    - recipient: age1l6gmgtjxjx9jx09j3umljfkren9dy8nmuet5tnqatxfddjkj89js2gn27m
      enc: |
        -----BEGIN AGE ENCRYPTED FILE-----
        YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSAwWlBqZGJRNnhVTWJFY2Z6
        d3NKVGFiUGs0VFBzTUZ2M2I4MHlaeFNpVnpjClVvWlRlYjFsZmRxblFkRlJ3aVk2
        b0E3ZStoeHhWNUUyeXliYVdZVGVKQncKLS0tIEpjblg4a21adFUxK0FvTC8zb2pq
        T2IzWHRvZHpEMEhYaEJkamE0UC9NK28Kv7yEHsS4Nr6XIJkpwEiBKIBVNosxDjpu
        hH+2h2o0zdypIjzecCSEGJWl4T2Y3U49/OMHryxZ9natE2I7vuhJTg==
        -----END AGE ENCRYPTED FILE-----
  lastmodified: "2024-11-19T14:47:18Z"
  mac: ENC[AES256_GCM,data:/CNgVRN08vt6ElOwbRikXn/Nj0LI4pwAbKm9xF0WvIm+syR619mh3AfWVp1uQse2ClbOGfehReeECTjoOMcYJuhvw05L8FmU/DbKHp+r/pO/1zEqxMTbcT1JdhPV8ev5EJYTWpRqzW6HOajMO419LyMpkVj8tTQyT+STA5sLd7o=,iv:JNxQEtgGQ5frqesQ+pNqDR9S5/Gaz4vSlAkK70UDx6g=,tag:8IYhNHeIeIzowzPFFct4Rw==,type:str]
  pgp: [ ]
  encrypted_regex: ^(password)$
  version: 3.9.1

On peut remarquer que la clé de valeur username n'a pas été chiffrée.

Configuration de sops

Pour éviter de devoir spécifier la clé de chiffrement à chaque fois que vous voulez chiffrer un fichier, vous pouvez créer un fichier .sops.yaml dans votre répertoire personnel ou dans le répertoire de votre projet.

Le fait de le mettre dans le répertoire du projet et de le commettre permet de partager la configuration avec les autres collaborateurs du projet.

Le fichier .sops.yaml doit ressembler à ceci :

creation_rules:
  - kms: arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab

Dans cet exemple, nous avons configuré sops pour qu'il chiffre tous les fichiers la clé de chiffrement arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab qui est hébergée sur AWS KMS. Bien sûr, votre utilisateur doit avoir les droits nécessaires pour accéder à cette clé de chiffrement.

Vous pouvez aussi, utiliser un autre algorithme de chiffrement en utilisant une clé AGE ou PGP.

Le fichier .sops.yaml ressemblera alors à ceci :

creation_rules:
  - age: >-
      age1l6gmgtjxjx9jx09j3umljfkren9dy8nmuet5tnqatxfddjkj89js2gn27m,
      age1ydpuxyda7ztcw4rnr0en555a8c39p03pvqeecf2fhjrvnl4unuzq82lj3x

Chaque ligne qui début par age est une clé de chiffrement. Vous pouvez en ajouter autant que vous voulez, il suffit de mettre une virgule à la fin de la ligne et de continuer sur la ligne suivante. Typiquement, une par personne qui doit accéder aux secrets.

Vous pouvez aussi préciser d'autres paramètres comme le format du fichier, les fichiers qui doivent être chiffrés, le patterns des clés de valeur à chiffrer, etc.

.sops.yaml

creation_rules:
  - filename_regex: '.*\.secrets\.yaml$'
    age: >-
      age1l6gmgtjxjx9jx09j3umljfkren9dy8nmuet5tnqatxfddjkj89js2gn27m, 
      age1ydpuxyda7ztcw4rnr0en555a8c39p03pvqeecf2fhjrvnl4unuzq82lj3x
    encrypted_regex: '^(data|stringData|password)$'

  - filename_regex: '^config/.*\.json$'
    age: >-
      age1l6gmgtjxjx9jx09j3umljfkren9dy8nmuet5tnqatxfddjkj89js2gn27m,
      age1ydpuxyda7ztcw4rnr0en555a8c39p03pvqeecf2fhjrvnl4unuzq82lj3x
    encrypted_regex: '^(password|apiKey)$'

Clés de chiffrement AWS KMS

Dans notre contexte, nous utilisons AWS KMS pour chiffrer nos secrets. Pour cela, nous avons créé une clé de chiffrement dans AWS KMS et nous avons configuré sops pour qu'il chiffre les secrets avec cette clé.

Pour utiliser une clé de chiffrement AWS KMS, vous devez avoir un compte AWS et vous devez avoir configuré votre compte pour qu'il puisse accéder à la clé de chiffrement.

La création de la clé est hors du scope de cet article, mais vous pouvez consulter la [documentation officielle d'AWS]https://aws.amazon.com/fr/kms/getting-started/?nc1=h_ls) pour plus d'informations.

Pour utiliser une clé de chiffrement AWS KMS, vous devez spécifier l'ARN de la clé dans le fichier .sops.yaml :

creation_rules:
  - kms: arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab

Le policy pour permettre l'utilisation de cette clé de chiffrement est la suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"
    }
  ]
}

Autres systèmes supportés

Bien sûr, tout les projets ne sont pas hébergés sur AWS. SOPS supporte d'autres systèmes de chiffrement comme Azure Key Vault, GCP KMS, PGP, etc. Vous pouvez consulter la documentation officielle pour plus d'informations.

Conclusion

En conclusion, avec SOPS, il est très facile de chiffrer vos secrets et de les partager en toute sécurité. Vous pouvez chiffrer vos secrets avec des clés de chiffrement de différents fournisseurs de services cloud ou des jeux de clés publiques et privées. Vous pouvez aussi configurer SOPS pour qu'il chiffre automatiquement vos fichiers en fonction de certains critères.

Vous pouvez donc augmenter la sécurité et respecter les bonnes pratiques en matière de sécurité en chiffrant vos secrets avec SOPS.

SOPS est donc une solution incontournable pour sécuriser vos secrets dans des projets collaboratifs. En combinant simplicité, flexibilité et compatibilité avec des systèmes cloud majeurs, il facilite la mise en œuvre des bonnes pratiques de sécurité.

Commencez dès maintenant à intégrer SOPS dans vos workflows pour renforcer la sécurité et réduire les risques liés à la gestion des secrets.

Cet article fait partie du Advent of Tech 2024 @ Onepoint, une série d'articles tech publiés par Onepoint pour patienter jusqu'à Noël.

Voir tous les articles du Advent of Tech 2024