Vue.js vs React.js : quel Framework pour son projet ?

Bienvenue dans l'univers du développement web, où chaque choix compte. Laravel et Symfony, deux géants du langage serveur PHP, se disputent la première place. Dans cet article, nous plongeons dans les détails, examinant performances, sécurité, et courbes d'apprentissage.

‍

Prêts à choisir le Framework idéal pour votre projet ? 

‍

Laravel et Symfony : Les titans du développement PHP

‍

Dans l'arène du développement serveur PHP, deux titans émergent : Laravel et Symfony.

‍

Laravel, créé par Taylor Otwell, séduit par son architecture élégante basée sur le modèle MVC (pour Modèle-Vue-Contrôleur), ses outils puissants, et une courbe d'apprentissage conviviale.

‍

De l'autre côté, Symfony, de SensioLabs, brille par sa modularité et des composants réutilisables. Avant de choisir votre champion, explorons en détail ce que chaque Framework peut vous offrir.

‍

Laravel

‍

Laravel est un Framework PHP qui a su captiver la communauté des développeurs. Imaginé par le développeur américain, Taylor Otwell, Laravel séduit par son architecture claire et élégante, basée sur le modèle architectural MVC. Cette structure facilite la conception d’applications et le développement en offrant une séparation nette entre les composants d’un projet.

Laravel ne fait pas que promettre, il délivre des performances remarquables. Les temps de réponse sont optimisés pour offrir une expérience utilisateur plus fluide. La gestion intelligente des bases de données et les outils intégrés font de Laravel un choix judicieux pour des applications performantes.

Dans le monde numérique d'aujourd'hui, la sécurité est primordiale. Pour cela, Laravel intègre des systèmes robustes garantissant la protection à long terme de vos applications web modernes. Des mécanismes de sécurité avancés sont mis en place pour contrer les menaces potentielles.

La courbe d'apprentissage est souvent un obstacle, mais pas avec Laravel. Son approche conviviale permet aux développeurs de rapidement maîtriser le Framework. La documentation détaillée et la communauté active font de l'apprentissage une expérience fluide.

‍

Exemple de code concret : Gestion des utilisateurs avec Laravel

‍

‍

• Laraval utilise l’ORM (pour Object Relational Model) Eloquent pour simplifier les opérations d’interactions avec la base de données.
• La fonction bcrypt () sécurise le mot de passe avant son enregistrement.
• La réponse est renvoyée au format JSON.

‍

Laravel est votre allié dans la création d'applications web dynamiques et performantes.

‍

Symfony

‍

L’univers du Framework PHP Symfony est tout aussi passionnant. Renommé, riche et modulaire, Symfony est développé et maintenu par la société française SensioLabs. Symfony se démarque par son approche modulaire et ses composants réutilisables, offrant une flexibilité remarquable dans la conception d’application web.

Symfony ne se contente pas d'une architecture flexible, il excelle également en matière de performances. Les temps de réponse compétitifs et la gestion efficace des ressources font de Symfony un choix judicieux pour réaliser des applications PHP performantes.

La sécurité étant une priorité dans le paysage numérique actuel, Symfony intègre des mécanismes de sécurité assurant la protection de vos applications contre les menaces. La courbe d'apprentissage de Symfony est également conçue pour faciliter l'adoption du Framework. Les développeurs bénéficient d'une documentation exhaustive et d'une communauté active, simplifiant ainsi l'exploration des fonctionnalités avancées de Symfony.

‍

Exemple de code concret : gestion des utilisateurs avec Symfony

‍

‍

• Symfony utilise l’ORM Doctrine ainsi que les méthodes setName(), setEmail(), et setPassword() pour définir les propriétés de l'objet utilisateur.
• Le mot de passe est sécurisé à l’aide de password_hash().
• La méthode flush() persiste les changements en base de données.
• La réponse est renvoyée au format JSON.

‍

En somme, Symfony est un partenaire fiable pour le développement web.

‍

Comparaison directe

‍

Plongeons dans la comparaison directe entre Laravel et Symfony, examinant de près les éléments clés qui pourraient influencer votre décision dans le choix du Framework PHP idéal.

‍

Performance : la quête de la réactivité

La performance est cruciale pour une expérience utilisateur optimale. Nous comparons les temps de réponse de Laravel et Symfony pour vous aider à choisir le Framework qui offre la réactivité nécessaire à votre projet.

• Temps de Réponse : Laravel excelle avec des temps de réponse moyens de 250 millisecondes, offrant une expérience utilisateur rapide. Symfony, bien que compétitif, tend à se situer légèrement au-dessus, aux alentours de 300 millisecondes.

• Exemple : Un site e-commerce nécessitant une navigation rapide pourrait bénéficier des performances de Laravel, assurant une réponse quasi-instantanée lors de la recherche de produits.

‍

Architecture : MVC sous le microscope

L'architecture MVC (Modèle-Vue-Contrôleur) est le pilier du développement web moderne. Analysons comment Laravel et Symfony abordent cette structure fondamentale et en quoi cela peut impacter la gestion de votre code.

• Laravel : Son modèle MVC clair offre une structure fluide. Les développeurs peuvent facilement segmenter les responsabilités, améliorant la maintenabilité du code.

• Symfony : Une approche modulaire permettant une personnalisation avancée. Les composants réutilisables simplifient le développement, mais cela peut entraîner une complexité accrue pour les petits projets.

• Exemple : Un projet nécessitant une structure claire et simple pourrait préférer Laravel, tandis qu'un système complexe pourrait tirer parti de la modularité de Symfony.
• ‍

Command Line Interface (CLI) : L'art de la ligne de commande

La ligne de commande est l'alliée du développeur moderne. Comparons comment Laravel et Symfony s'engagent dans le royaume de l'interface en ligne de commande (CLI), facilitant ainsi le flux de travail du développeur.

• Laravel : La CLI de Laravel simplifie les tâches courantes telles que la génération de code, facilitant le flux de travail du développeur.

• Symfony : Une CLI robuste, mais avec une courbe d'apprentissage plus prononcée. Elle offre une personnalisation avancée, mais peut sembler complexe pour les débutants.

• Exemple : Pour un développeur qui privilégie la simplicité et la rapidité, la CLI de Laravel serait un choix naturel.

‍

Migration de base de données : Gestion intelligente des données

La migration efficace de la base de données est un défi incontournable. Jetons un regard attentif sur la manière dont Laravel et Symfony simplifient ce processus critique pour garantir une gestion fluide des données.

• Laravel : Les migrations simplifient les changements de schéma de base de données. Les développeurs peuvent versionner et partager ces modifications facilement.

• Symfony : Des migrations intégrées offrant également une gestion efficace des changements de base de données. Les bundles Symfony facilitent la modularité.

• Exemple : Un projet nécessitant des mises à jour fréquentes de la base de données pourrait bénéficier de la simplicité des migrations de Laravel.

‍

N’hésitez pas à plonger davantage dans ces détails pour faire un choix éclairé entre Laravel et Symfony, en alignant les forces de chaque Framework avec les exigences spécifiques de votre projet.

‍

‍

Frameworks PHP : Un choix déterminant pour le développement web

‍

Explorez l'impact déterminant que le choix entre Laravel et Symfony peut avoir sur votre projet de développement web.

‍

Choisir le bon Framework : un dilemme crucial

La sélection du bon Framework PHP est un dilemme majeur, influençant directement la réussite de votre projet. Laravel et Symfony offrent des avantages uniques, mais lequel répond le mieux à vos besoins spécifiques ?

• Laravel : Excellant dans la simplicité et la rapidité de développement, Laravel est souvent le choix préféré pour les projets de taille moyenne nécessitant une mise en œuvre rapide.

• Symfony : Connu pour sa modularité et ses composants réutilisables, Symfony brille dans des projets plus complexes où la personnalisation et la réutilisation de code sont essentielles.

• Exemple : Un site vitrine pour une petite entreprise pourrait privilégier la simplicité de Laravel, tandis qu'un système de gestion complexe opterait probablement pour la modularité de Symfony.

‍

Forces et faiblesses : un examen critique

Chacun des Frameworks a ses points forts et ses faiblesses. Examinons en détail les avantages et les limitations de Laravel et Symfony pour vous guider dans cette décision cruciale.

• Laravel : Points forts dans la simplicité, la documentation claire et la courbe d'apprentissage conviviale. Cependant, sa modularité peut être moins flexible pour des projets très spécifiques.

• Symfony : Excellant dans la modularité, Symfony offre une flexibilité maximale, mais sa courbe d'apprentissage peut être plus abrupte pour les débutants.

• Exemple : Un projet nécessitant des fonctionnalités spécifiques pourrait bénéficier de la flexibilité de Symfony, tandis qu'un projet plus simple pourrait opter pour la simplicité de Laravel.

‍

Taille du projet : l'importance du contexte

La taille de votre projet est un facteur déterminant. Nous évaluons comment Laravel et Symfony s'adaptent aux projets de différentes envergures, vous permettant ainsi de choisir en fonction de vos besoins spécifiques.

• Laravel : Idéal pour des projets de taille moyenne, où la rapidité de développement est cruciale.

• Symfony : Convient particulièrement aux projets de grande envergure, offrant la modularité nécessaire pour gérer la complexité.

• Exemple : Un blog personnel pourrait tirer parti de la simplicité de Laravel, tandis qu'un système de gestion d'entreprise complexe pourrait profiter de la robustesse de Symfony.

‍

Performance attendue : Une réflexion essentielle

Quelles performances attendez-vous de votre application web ? Laravel et Symfony offrent des approches différentes. Décortiquons ces approches pour vous aider à prendre une décision éclairée.

• Laravel : Performances élevées pour des projets de taille moyenne, avec des temps de réponse compétitifs.

• Symfony : Excellentes performances également, mais peut être plus adapté à des projets plus vastes.

• Exemple : Un site de portfolio artistique pourrait privilégier les performances de Laravel, tandis qu'un site e-commerce à fort trafic pourrait opter pour Symfony.

‍

Préférences des développeurs : Un facteur humain

L'adhésion des développeurs à un Framework peut être un critère déterminant. Découvrez comment Laravel et Symfony sont perçus dans la communauté des développeurs, un aspect clé pour le succès à long terme de votre projet.

• Laravel : Apprécié pour sa simplicité et son approche élégante, attirant souvent les développeurs cherchant une courbe d'apprentissage plus douce.

• Symfony : Adopté par des développeurs expérimentés cherchant une modularité étendue et une personnalisation avancée.

• Exemple : Une équipe de jeunes développeurs débutants pourrait se sentir à l'aise avec la simplicité de Laravel, tandis qu'une équipe expérimentée pourrait être attirée par la puissance de Symfony.

‍

Après avoir exploré les nuances de Laravel et Symfony, il est temps de conclure. Chaque projet a des besoins uniques, et votre décision devrait être ancrée dans une évaluation minutieuse des forces et des faiblesses de chaque Framework.

‍

En conclusion, gardez un œil sur l'horizon du développement web. Les Frameworks évoluent, les tendances changent. Votre choix devrait également être orienté vers l'avenir, en tenant compte des mises à jour futures, de la communauté active et des innovations à venir.

‍

Votre choix entre Laravel et Symfony déterminera la trajectoire de votre projet. Explorez les possibilités infinies offertes par ces Frameworks PHP et prenez votre décision en connaissance de cause. Votre aventure de développement web commence ici. Bonne exploration !

Introduction

Aujourd'hui, comment parler de développement logiciel sans parler de Git ? Un bon système de gestion des versions est essentiel pour assurer un flux de travail efficace. Git est l'outil de gestion de versions par excellence et est le plus populaire. Néanmoins, avec Git, il s'est développé différentes stratégies pour structurer et gérer le flux de modifications de la codebase. Parmi toutes ces stratégies, aujourd'hui, deux vont nous intéresser : le Trunk-Based Development (TBD) et Git Flow.

‍

D'un côté on a le TBD, une approche minimaliste qui préconise de travailler directement sur un tronc commun, autrement dit la branche principale. Tandis que Git Flow, lui, propose une structure plus complexe, avec des branches dédiées à des fonctionnalités, des corrections, des versions, etc.

‍

Les deux approches ont des avantages et des inconvénients, leurs propres complexités et simplicités et c'est ce que nous allons voir maintenant.

‍

L'objectif de cet article n'est pas simplement de fournir une explication de ces deux stratégies de gestion des versions, mais plutôt de démontrer pourquoi, dans de nombreux contextes, le TBD peut s'avérer une approche plus optimale que Git Flow.

‍

Git Flow vs Trunk-Based Development

‍

La stratégie Git Flow

Git Flow est une stratégie de gestion de versions populaire qui a été conçue pour aider les équipes à gérer les développements complexes, en tirant parti de la puissance et de la flexibilité des branches Git. Elle propose une structure organisée qui facilite le développement parallèle de différentes fonctionnalités et la gestion des versions.

‍

Organisation

Avec Git Flow on organise nos branches de la manière suivante :

• main, la branche principale qui représente l'état actuel de la production
• develop, la branche où se trouve toutes les fonctionnalités, corrections et autres de la prochaine version prévue
• feature/xxx, les branches créées à partir de develop où se trouve le code d'une fonctionnalité qui sera fusionné avec develop une fois le développement terminé
• release/xxx, les branches créées à partir de develop où se trouve le code d'une nouvelle version du logiciel, potentiellement affiné avant le déploiement
• hotfix/xxx, les branches créées à partir de main pour des corrections critiques découvertes en production. Ces branches sont fusionnées dans main dès que le correctif est prêt et sont également fusionnées avec develop pour s'assurer que la correction perdurera dans la codebase

‍

Les problèmes de Git Flow

La force de Git Flow réside dans sa structure qui permet de gérer facilement des tâches parallèles et suivre d'évolution du code à travers le temps.

Cette stratégie entraîne néanmoins un lot d'inconvénients :

• Complexité - Cette stratégie nécessite beaucoup de manipulation manuelle des branches qui demande une maîtrise totale de Git et de ce processus
• Intégration continue compliquée - L'intégration continue est plus complexe à mettre en place en raison du développement parallèle sur plusieurs branches
• Déploiement fréquent coûteux - Le déploiement continus/fréquents n'est pas impossible mais demande beaucoup plus de temps et d'énergie
• Problèmes de fusion - Le nombre parallèle de branches important entraîne de nombreux problèmes potentiels de merge
• Revues de code difficiles - La taille des pull requests a tendance à être plus importante avec Git Flow parce qu'elles contiennent des fonctionnalités complètes. La branche de feature a tendance à vivre trop longtemps, nécessitant des fusions fréquentes avec develop ce qui entraîne des retards dans le processus de livraison
  

‍

La stratégie Trunk-Based Development

La stratégie Trunk-Based Development est une approche bien plus minimaliste dont le but est de simplifier le flux de travail en minimisant la fragmentation du code et en facilitant l'intégration continue. Pour cela on ne va travailler que sur une seule branche principale (main ou trunk) autrement appelé : le tronc commun.

‍

Une seule source de vérité

Avec le TBD, cela signifie donc que toutes les modifications du code sont introduites et fusionnées directement dans la branche principale. Chaque développeur doit donc fusionner régulièrement ses modifications, plusieurs fois par jour. En conséquence, les versions sont gérées directement à partir de la branche principale, chaque développeur est constamment à jour et les problèmes de fusions sont considérablement réduits. Le cycle de développement est plus rapide et alimente l'intégration et le déploiements continus.

‍

Quid des branches ?

Travailler avec l'approche TBD ne signifie pas qu'on a plus du tout de branche en plus de la branche principale. En effet, les branches peuvent encore être utilisées mais elles se doivent d'être de très courte durée et fusionnées dès que le travail est terminé.

‍

Quid des revues de code ?

Quel que soit la stratégie adoptée, le processus de revue de code persiste et demeure une composante essentielle pour assurer la qualité du code qui est fusionné dans le tronc commun. La subtilité entre les deux stratégie est que avec le TBD, les modifications étant fréquemment fusionnées, elles sont généralement plus petites. Et si les modifications s'avèrent importante alors le TBD souhaite mettre en avant la collaboration et demanderait de faire ces modifications en pair ou en mob programming. Enfin, les revues de code se doivent d'être traitées rapidement (dans la demi-journée) et doivent durer que quelques minutes (15 maximum à peu près).

‍

Quid des modifications importantes ?

Le TBD n'empêche pas le développement de fonctionnalités importantes qui demandent donc de lourdes modifications du code. En revanche, cette stratégie va favoriser la collaboration via du pair ou du mob programming mais ce n'est pas la seule solution. Il existe également les Feature Flags.

‍

Un Feature Flag est une technique de développement logiciel permettant de masquer, activer ou désactiver une fonctionnalité dans un environnement de production sans avoir à redéployer le code. Cette technique offre un contrôle en temps réel des fonctionnalités, représente une sécurité contre les problèmes potentiels de nouvelles fonctionnalités et, surtout, permet de travailler sur de nouvelles fonctionnalités directement dans la branche principale sans interrompre le fonctionnement normal de l'application.

‍

Dans le cadre de l'approche TBD, où toutes les modifications sont effectuées directement sur la branche principale, l'utilisation de Feature Flags de fusionner le code pour de nouvelles fonctionnalités qui ne sont pas encore terminées ou testées. La fonctionnalité peut être développée et fusionnée dans le tronc sans être exposée aux utilisateurs jusqu'à ce qu'elle soit prête, où le Feature Flag à ce moment-là, peut être activé.

‍

Le recours à des Feature Flags apporte une flexibilité considérable au processus de développement et constitue une composante essentielle pour atteindre un déploiement continu et un flux de travail efficace dans le TBD.

‍

Mais à quoi ça ressemble concrètement ?

Ce sont ni-plus ni-moins des booléens :

‍

Et à l'usage, par exemple pour du React mais le principe est le même pour n'importe quel environnement :

Il est tout à fait possible de mettre en place un système de Feature Flags contrôlable à distance via un backoffice ou des outils tout prêt à l'usage qui existe sur le marché comme Firebase Remote Config, PostHog ou Harness par exemple.

‍

Pré-requis

Pour une implémentation efficace du TBD, plusieurs éléments sont généralement requis :

• Intégration Continue (CI) : c'est une stratégie qui bénéficie grandement de l'utilisation de la CI étant donné quelle est souvent sollicité pour de petites modifications. La CI permet d'assurer que le tronc commun est toujours en état de fonctionner correctement et qu'elle continue à être deployable à tout moment.
• Tests automatisés : les tests automatisés vont de pair avec la CI, ils assurent, si ils sont correctement mis en place, de la qualité du code.
• Revues de code : comme mentionné précédemment, les revues de code sont une composante essentielle pour maintenir la qualité et le partage de connaissance.
• Feature flag : comme expliqué précédemment, il est important de savoir mettre en place les features flag parce qu'ils sont souvent utilisés.
• Culture de la collaboration : enfin, l'environnement de travail est très important, toute l'équipe doit être impliqué, connaître et appliquer ce processus. L'équipe doit également se responsabiliser et doit être prête à collaborer étroitement et à partager ses connaissances.

‍

Résumons les bénéfices

Maintenant que nous avons expliqué le TBD comment il fonctionne et dans quel contexte, nous pouvons en ressortir les bénéfices suivants :

• Intégration continue (CI) : grâce à l'intégration fréquente de petits changements, les problèmes sont détectés et résolus plus rapidement. De plus, cela limite les éventuels conflits de fusion.
• Déploiements plus rapides : avec une seule branche principale toujours prête à être déployée, le TBD peut faciliter des déploiements plus rapides et plus réguliers.
• Simplification du processus : la stratégie TBD supprime la nécessité de gérer de nombreuses branches à long terme, simplifiant le flux de travail de l'équipe.
• Qualité du code : les revues de code régulières contribuent à maintenir la qualité du code et à anticiper les problèmes.
• Flexibilité grâce aux Feature Flags : l'utilisation de Feature Flags permet de tester de nouvelles fonctionnalités en production sans les exposer aux utilisateurs finaux, contribuant à un lancement plus sûr et contrôlé des nouveautés.

‍

Un dernier bénéfice que nous allons voir en détail dans le dernier point de cet article, c'est la facilité avec laquelle le TBD favorise l'atteinte de performances élevées selon les métriques DORA, un ensemble de mesures reconnues pour évaluer l'efficacité des équipes.

‍

‍

Et les inconvénients dans tout ça ?

La mise en œuvre de la stratégie TBD présente également certains défis ou inconvénients :

• Gestion rigoureuses des fusions : les modifications doivent être fusionnées en continu dans le tronc commun, ce qui nécessite que les développeurs synchronisent fréquemment leur travail avec la branche principale pour éviter les conflits de fusion.
• Culture : pour certaines équipes, l'adoption de cette stratégie peut nécessiter un changement significatif dans leurs pratiques de travail, notamment l'intégration continue et les revues de code constantes.
• Déploiements risqués sans tests adéquats : sans une couverture de test adéquate, le risque d'introduction de bugs en production peut être plus élevé, car tout le code est fusionné directement dans la branche principale qui est déployée.
• Complexité des Feature Flags : bien que les Feature Flags offrent plus de flexibilité, leur gestion peut ajouter une certaine complexité. Une mauvaise utilisation des feature flags peut entraîner de la dette technique.

En dépit de ces défis/inconvénients, il est globalement reconnu que les avantages valent les efforts nécessaires pour mettre en œuvre le TBD. Comme pour beaucoup de choses de la vie, il est important de déterminer si cette stratégie est adaptée au contexte spécifique de votre équipe et de votre projet.

‍

‍

DORA Metrics et Trunk-Based Development

‍

Les DORA Metrics (ou DevOps Research and Assessment metrics), sont une série de mesures de performance pour les équipes de développement logiciel.

‍

Ces mesures incluent :

• Le temps de cycle de déploiement (Mean Lead Time for Changes - MLTC) : Le temps moyen nécessaire pour qu'un commit passe à la production.
• La fréquence de déploiement (Deployment Frequency - DF) : À quelle fréquence une organisation déploie du code en production.
• Le temps de rétablissement (Mean Time to Restore - MTTR) : Le temps nécessaire pour récupérer d'une panne ou d'un incident de production.
• Le taux d'échec des modifications (Change Failure Rate - CFR) : La proportion de déploiements causant un incident de production ou un échec de service.

‍

Le TBD est lié aux DORA Metrics car c'est une méthode de développement qui peut potentiellement améliorer ces mesures. Il encourage des cycles d'intégration et de déploiement plus courts, ce qui peut accélérer le délai de déploiement et augmenter la fréquence de déploiement.

• MLTC et DF : La fusion fréquente de petites modifications permet de réduire le temps de cycle de déploiement et d'augmenter la fréquence de déploiement, car la branche principale est toujours dans un état deployable.
• CFR : Avec des revues de code régulières et des tests automatisés, on peut s'attendre à ce que le pourcentage de modifications ratées diminue, car les problèmes sont souvent découverts et corrigés avant le déploiement.
• MTTR : Comme les problèmes sont généralement plus petits et plus localisés avec cette approche, il est généralement possible de corriger et de restaurer le service plus rapidement.

‍

En résumé, l’approche Trunk-Based Development est bien alignée avec l’amélioration des métriques DORA, ce qui en fait une stratégie de choix pour les équipes axées sur le DevOps.

Ainsi, le développement basé sur la stratégie TBD peut contribuer à l'amélioration des DORA metrics.

‍

‍

Le mot de la fin

Cet article a examiné en profondeur la stratégie de Trunk-Based Development (TBD) en la comparant à Git Flow et en mettant en avant ses nombreux avantages. Nous avons analysé comment le TBD favorise des cycles de développement plus rapides, une meilleure qualité de code grâce aux revues de code constantes, et une plus grande flexibilité par l'utilisation de feature flags. Nous avons également expliqué comment le TBD facilite l'atteinte de performances élevées selon les DORA Metrics.

‍

Cependant, nous avons également souligné que le TBD n'est pas sans défis. Il nécessite une gestion rigoureuse des fusions, un changement culturel significatif dans certaines équipes, une bonne couverture de tests pour minimiser les risques associés au déploiement constant.

Pour conclure, le TBD est un modèle puissant qui peut accélérer la livraison de valeur, améliorer la qualité du code et favoriser l'optimisation continue des performances de l'équipe. Cependant, comme pour toute stratégie, son adoption doit être précédée d’une évaluation approfondie des besoins, contextes et capacités spécifiques de l’équipe.

‍

‍

Les dédicaces

• Trunk-Based Development - Paul Hammant
• The best Git branching strategy - Daniel Moka
• Trunk-Based Development for Mobile Apps - Mirella Batista
• Atlassian Resources
• DORA Metrics : utiliser la technologie pour piloter la valeur du business - Thibaut Weissgerber

Le database branching est une approche d’organisation de base de données qui permet de reproduire la dynamique et le fonctionnement des branches Git.

On va alors pouvoir à partir d’une base de données appelé “master” pouvoir dupliquer une “branche” avec un certain nom. Cette nouvelle base de données se vera hériter des données ainsi que des migrations de la branche source.

Les cas d’usages de ce principe sont multiples et variés. Si nous reprenons l’analogie avec Git flow, lorsque vous allez créer une nouvelle branche de feature, vous serez amené à devoir développer puis appliquer une migration de données ou bien tout simplement altérer les données contenues dans cette base. Elle devient à partir de là un bac à sable tout en partant d’un environnement déjà prédéfini.

Grâce à la nouvelle base de données mise en place pour votre feature, vous n’allez impacter aucun environnement de production / staging / dev mis en place et accessible par tous les développeurs.

Votre base de données sera alors unique et éphémère, une fois la feature terminée, celle-ci pourra être supprimée.

Elle peut aussi servir de base de données temporaire pour une démonstration client, alimentée de données bien précises pour cette dite démonstration.

Pour terminer cette introduction, j’ajouterai que le database branching est présent avant tout pour améliorer la “DX” des développeurs au quotidien.

‍

Pourquoi ne pas alors simplement produire une base de données sur ma machine ?

Il est autant possible que l’infrastructure du projet mette à disposition un cluster de base de données sur un serveur ou bien qu’un développeur puisse créer son cluster sur sa machine.

Avec un provisionnement type Docker vous pouvez déployer rapidement une base de données sur votre machine avec un script de seeding permettant d’alimenter cette base en données. Cependant, vous allez perdre une composante essentielle au database branching qui est la synchronisation de la branche Git avec les données.  En effet, si vous êtes plusieurs développeurs à intervertir sur cette feature / environnement, aucune manipulations supplémentaires ne sera à faire lors du passage sur la branche Git. Vous récupérez la base de données déjà préparée par le précédent développeur.

Vous allez aussi avoir la problématique d’espace disponible sur votre machine, si vous travaillez sur plusieurs branches en même temps, cela implique de pouvoir posséder un conteneur d’une base de données unique par branche. Donc, une grande quantité de données en local.

‍

Comment s’intègre le Database branching dans le workflow du développeur

Comme n’importe quel outil s’ajoutant sur une stack d’un projet, le database branching viens complexifier quelques aspects techniques de celui-ci.

Alors, il est nécessaire d’automatiser le maximums d’aspects du database branching afin de ne pas augmenter le nombre de tâches à réaliser par les développeurs lors de la création d’une nouvelle feature.

En laissant certaines tâches manuelles, nous risquons de frustrer nos collègues développeurs. En effet, il est très facile d’oublier d’exécuter  une certaine commande après un changement de branche.

Dans la deuxième partie de l’article nous nous intéresseront à réaliser un environnement de développement fluide avec l’exemple d’une stack web.

Je dirai alors que le database branching idéal est celui qui est complètement transparents pour les développeurs.

Dans la finalité ce principe est plus ou moins une idéologie, le degrés de l’implémentation peut dépendre de l’envergure du projet et du nombre de développeurs.

‍

Tutoriel: Mise en place du database branching sur une stack Typescript, Prisma

‍

Initialisation du projet et de la base de donnée

La première étape de ce tutoriel sera de se munir d’une base de données avec un utilisateur ayant l’autorisation de créer des database supplémentaires.

Voici plusieurs providers proposant ce service:

• Planetscale
• Neon
• AWS

Actuellement nous utilisons une base de données hébergée Aurora Serverless hébergée sur AWS déployée depuis Terraform avec le module suivant.

Pour la suite de ce tutoriel nous avons choisis d’utiliser une base de données PostgreSQL. Il est aussi tout à fait possible de l’intégrer sur une base de données MongoDB, MySQL, …

Pour passer rapidement sur les étapes d’initialisation du projet TS avec Prisma je vous redirige vers la documentation officielle de Prisma.

Après toutes ces étapes vous devriez avoir dans la racine de votre projet un fichier d’environnement nommé .env qui possède une url de base de données DATABASE_URL.

À présent nous pouvons remplacer cette url par celle de notre base de données  provisionnée un peu plus haut.

DATABASE_URL="postgresql://gabriel:password@db-branching.cluster-xxxxxxx.eu-west-3.rds.amazonaws.com:5432/master?schema=public"

La database pointée (master dans ce cas-là) importe peu, elle sera mise à jour par  la suite automatiquement.

‍

Automatisation du changement de branche

Afin de faciliter le passage sur une nouvelle base de données à chaque changement de branche git, il est possible de créer un hook sur le projet git, qui sera exclusivement lancé lors d'une commande git checkout.

Pour celà nous utiliserons un outil facilitant la création de hook git nommé Husky.

Voici les commandes d’installation que vous pouvez retrouver dans la documentation officielle:

Cette dernière commande va alors créer un script bash dans le dossier suivant.husky/post-checkout.

On ajoutera ces trois lignes de bash permettant de récupérer la branche git lors d’un checkout et de mettre à jour le fichier .env

Et voilà !

Maintenant à chaque changement de branche en local votre .env sera mis à jour automatiquement.

Il est possible d’aller plus loin en ajoutant l’application automatique des migrations de la base données et/ou le seeding de data.