Comment gérer plusieurs sites facilement ?

Par @jbnahan69
Source https://www.pxfuel.com/en/free-photo-jmzwh

Dans la suite des articles sur les bundle Sylius et leur usage en dehors de Sylius, je démarre une nouvelle série. J'espère quelle vous passionnera autant que les défis technique lié à cette problématique m'on passionné.

Depuis le début du web, un besoin revient souvent sur la gestion de plusieurs sites (multi tenant) de façon efficace.

Il y a les générateurs de site, les plateformes de gestion multisite comme Wordpress, Bolt ou Ibexa Content, mais ça fini toujours pareils.

Au bout d'un moment, c'est le bazar. Un seul code pour plusieurs sites avec chacun leurs spécificités qui vient polluer les autres sites.

Au début, tout est rose, tous les sites sont identiques, tout se passe bien. Puis une demande arrive pour un site en particulier, puis une autre.

Les modifications sont apportées les unes après les autres, il y a quelques couacs de mise en prod, mais rien de méchant.

Et un beau jour, une demande pour un site qui va en contradiction complète avec le fonctionnement d'un autre site. Et là, ont fini par l'implémenter à grands coups de IF et de paramétrage dans la config du site.

Puis vient encore une autre demande... Et ça n'en finit jamais...

Au bout d'un moment, l'équipe change, les nouveaux n'ont plus l'historique du code et devant cet empilement de IF, les modifications deviennent pénibles. L'envie de tout refaire augmente.

La situation est devenue intenable, le code est moche, incompréhensible, difficile à changer sans avoir des effets de bord sur un autre site.

Toute ressemblance avec une situation réelle est tout à fait probable. J'ai donc décidé de partager avec vous les solutions que j'ai recensées. J'ai volontairement regroupé de nombreuses variantes ensemble pour plus de concision. Je serais ravi de lire votre expérience en commentaire ou sur les réseaux sociaux.

Solution à disposition

Lors de la refonte d'une telle plateforme, il est important de se poser pour partir du bon pied.

Il me semble bien plus simple de gérer chaque site séparément en utilisant une base commune. Mais cette solution n'est pas toujours valable.

Avant de commencer une refonte, il est nécessaire de réaliser l'inventaire des fonctionnalités existantes, de celle réellement utilisée et de celles indispensables.

Avec cet inventaire, il sera plus aisé de prioriser les fonctionnalités à développer, mais également de réaliser l'étude de marché des logiciels existants.

La seule solution valable est celle qui vous correspond.

Voici les solutions que j'ai pu croiser (si j'en ai oublié, dites-le-moi en commentaire) :

Un code, un site

C'est ma solution préférée, le code commun est mis dans des bundles ou plug-ins pour être partagé sur les sites. Les migrations sont réalisées au fil de l'eau pour chacun des sites.

Le code reste simple sur chaque site, car on évite les IF ou autre subterfuge pour choisir le bon code à exécuter. Cela influe également sur le débogage qui reste simple également.

Cependant, ce n'est pas une migration qu'il faut faire, mais autant qu'il y a de site. Il y a autant de déploiement que de site. Autant de CI/CD que de sites pour un déploiement optimal en fonction du trafic du site.

Malgré cette préférence, il faut bien l'avouer, tout le monde n'est pas à l'aise avec le développement de plug-in ou de bundle. Ce point peut être négligeable pour une personne qui n'a pas peur d'apprendre de nouvelles choses, mais tout le monde n'est pas dans ce cas. Voyons une autre façon de faire...

Un code, plusieurs sites, plusieurs bases de données

Ce mode de gestion permet d'avoir une base de code exploitée par plusieurs sites. Ils peuvent avoir chacun leur charte graphique. Les modifications doivent être communes à chaque site.

Certains seront plus à l'aise avec cette solution pour s'éviter la gestion de plug-in ou bundle. Dans ce cas, il est nécessaire d'avoir de la rigueur et mettre en place des conventions.

Par exemple avec Symfony il est facile d'utiliser l'autoconfiguration et les passes de compilation du noyau pour préparer le site en fonction de la configuration. Cela évite de mettre dans le code des if pour savoir quelle fonction appeler. En un certain sens c'est du polymorphisme de site web.

Le débogage reste simple, car la configuration détermine les classes PHP utilisées. La convention de nommage permet de retrouver facilement la classe du site pour intervenir dessus.

Une organisation du code consisterait à rassembler tout ce qui est commun dans un dossier et ajouter un dossier par client.

src
├── ClientA
│   ├── Entity
│   └── Repository
├── ClientB
│   ├── Entity
│   └── Repository
└── Platform
    ├── Entity
    ├── Repository
    └── Service

Le tronc commun contient les interfaces que chaque client devra implémenter. Au besoin, le tronc commun peut implémenter une interface pour mettre en commun certaines portions du code.

Chaque nouvelle version devra être déployée sur chaque site individuellement, il y aura une seule intégration continue (CI), mais plusieurs déploiements continuent (CD).

Les mises à jour sont donc déployées en douceur et peuvent être planifiées en fonction du trafic du site à déployer.

Comme pour le code, la configuration spécifique à un client est contenue dans le dossier config/ClientA.

config
├── ClientA
├── ClientB
└── packages

Cette façon de faire est courante avec Ibexa Content. Ce dernier permet même un seul déploiement pour tous les sites en même temps. Il est capable de gérer plusieurs sites avec plusieurs bases de données sur la même installation. Il utilise des règles de matching pour déterminer le site demandé.

Un code, plusieurs sites, une seule base de données

Cette solution est bien pour le début ou pour un site de e-commerce multimarque proposant les mêmes produits.

Cela consiste à avoir une base de code commune à plusieurs sites avec chacun son propre thème graphique.

Cela fonctionne bien tant que les modifications apportées sont communes à tous les sites. Dès que les modifications ne sont que pour un site en particulier, les ennuis commencent. Et cela finit comme décrit en intro.

Wordpress permet ce genre de gestion multisite. Déjà qu'avec un site, il y a des problèmes à chaque mise à jour, qu'est ce que ça sera avec du multisite.

Chaque plug-in sera disponible pour chaque site, et certains ne sont pas compatibles entre eux (ex.: gestion du cache).

Dans ce mode de gestion de site, le déploiement est plus complexe, car il faut trouver un créneau horaire qui convient à tous les sites en même temps. Ça peut devenir impossible selon les horaires de pic de trafic.

Je dois l'avouer, cette solution est envisageable avec Ibexa Content, la gestion multisite, multilangue, multithème est quelque chose de possible et de souvent réalisé.

J'ai même commencé un projet de refonte du site de l'extension Win32Service sur Ibexa Content en ayant comme objectif de basculer ce site sur la même base de code. Je reparlerai surement de ce projet une prochaine fois (pour le moment en pause).

Conclusion

Nous avons vu 3 façons de gérer le code de plusieurs sites web et son déploiement. Mais il en existe d'autres, il existe surtout celui qui vous convient.

Qu'en pensez-vous ? Comment gérez-vous du multisite ? Ai-je oublié la façon miracle, qui correspond à tout ?

J'attends vos retours en commentaire, ou sur les réseaux sociaux.

Restez connecté ! J'ai réalisé une preuve de concept (POC) basé sur la méthode "Un code, plusieurs sites, plusieurs bases de données" . Le prochain article est sorti, voyons comment gérer la configuration et les templates.

Author avatar
Jean-Baptiste Nahan

Consultant Expert Web, j'aide les entreprises ayant des difficultés avec leur projet Web.

@jbnahan69 | Macintoshplus | Linkedin | JB Dev Labs