Pour aller plus loin et répondre en parallèle à votre commentaire plus haut sur le pourquoi du comment :
Nous avons fait le choix de ne supporter qu'un seul moteur de DB (en fait MariaDB est compatible mais en vrai on a jamais eu de retour en prod à grande échelle) pour simplifier les problématiques de déploiement. Faire du On Prem c'est très compliqué, même avec des choix franchement clivants (1 seule version de PHP, 1 seule version de MySQL, 2 versions du même OS) ça représente un coût significatif de maintenance (exemple on attend ardemment la mort de RHEL6 dans 20 jours pour enfin pouvoir mettre à jour mediawiki). Ce temps, nous préférons le consacrer à du fonctionnel pour l'utilisateur final.
Nous avons également fait le choix de le pas utiliser d'ORM. En premier lieu parce qu'un ORM pour 1 seul moteur de DB c'est un peu overkill et en plus car le modèle de données des trackers (l'équivalent de Jira chez atlassian) est extrêmement complexe et, de tout façon il aurait fallu faire du by pass et écrire les requêtes à la main.
Le gros avantage c'est que l'on a la maîtrise complète de bout en bout et on a des perfs sur lesquels on a pas à rougir. Ça me fait un peu marrer la limite à 2000 utilisateurs des instances Jira on Prem quand on à 45'000 utilisateurs sur certaines des nôtres avec juste une séparation web serveur et DB (pas de cluster ou quoique ce soit de monstrueux, et des serveurs "standards").
[^] # Re: À propos de la stack
Posté par vaceletm . En réponse à la dépêche Migration de Jira à Tuleap : nouvelle fonctionnalité. Évalué à 6.
C'est dommage :)
Pour aller plus loin et répondre en parallèle à votre commentaire plus haut sur le pourquoi du comment :
Nous avons fait le choix de ne supporter qu'un seul moteur de DB (en fait MariaDB est compatible mais en vrai on a jamais eu de retour en prod à grande échelle) pour simplifier les problématiques de déploiement. Faire du On Prem c'est très compliqué, même avec des choix franchement clivants (1 seule version de PHP, 1 seule version de MySQL, 2 versions du même OS) ça représente un coût significatif de maintenance (exemple on attend ardemment la mort de RHEL6 dans 20 jours pour enfin pouvoir mettre à jour mediawiki). Ce temps, nous préférons le consacrer à du fonctionnel pour l'utilisateur final.
Nous avons également fait le choix de le pas utiliser d'ORM. En premier lieu parce qu'un ORM pour 1 seul moteur de DB c'est un peu overkill et en plus car le modèle de données des trackers (l'équivalent de Jira chez atlassian) est extrêmement complexe et, de tout façon il aurait fallu faire du by pass et écrire les requêtes à la main.
Le gros avantage c'est que l'on a la maîtrise complète de bout en bout et on a des perfs sur lesquels on a pas à rougir. Ça me fait un peu marrer la limite à 2000 utilisateurs des instances Jira on Prem quand on à 45'000 utilisateurs sur certaines des nôtres avec juste une séparation web serveur et DB (pas de cluster ou quoique ce soit de monstrueux, et des serveurs "standards").