SCM pour CMS

Question

Je n'arrive pas à résoudre tous les problèmes liés à la gestion de la configuration logicielle sur un CMS (plus précisément Joomla!). J'écris des modèles personnalisés, bien sûr, mais aussi des modules et des composants personnalisés. Ces sites Web et applications sont destinés aux clients et non à l'interne.

Je veux réellement mettre à jour la configuration du site, pas seulement le code de ses modèles et composants, parce que je veux qu'il soit prêt à monter en puissance pour des corrections, ou transférer à quelqu'un d'autre, aussi rapidement que possible. En ce moment, cela signifie stocker un Joomla complet! installer pour chaque site dans SVN, y compris les versions installées de composants et de modèles, et stocker les exportations de base de données réelles. Pour les composants, je garde également la version "packagée" du code (voir ci-dessous). En général, je ne m'occupe pas des modèles, car vous pouvez simplement les déposer dans Joomla! installer et cela fonctionne.

Le problème avec cette configuration que je discute actuellement est dans le développement de composants personnalisés. Dans Joomla! (et la plupart des autres CMS) sont généralement déployées à l'aide d'un programme d'installation Web - vous ne pouvez pas (au moins au début) simplement déposer les fichiers dans un certain dossier, car des changements de DB sont nécessaires. Le Joomla! Le système d'installation fournit la migration de DB et de fichiers avec des hooks d'installation et de désinstallation, c'est donc un système assez raisonnable pour le déploiement.

En ce moment, je soit: 1) travaille directement sur le composant installé, en ajoutant et puis les copier manuellement changer des fichiers vers la version packagée du composant, ou 2) travaillent sur le composant emballé et utiliser le programme d'installation pour voir les résultats. Cette option prend généralement trop de temps, mais elle a l'avantage de garder le code "libérable", surtout en ce qui concerne les migrations de DB.

Dans les deux cas, les modifications sont dupliquées sur les deux versions des fichiers avant l'enregistrement, et la duplication me semble être une odeur.

Alors, est-ce que quelqu'un d'autre le fait? Y a-t-il de meilleures options?

Answer 1

« 1/» devrait être « sorte de » la voie à suivre

Lorsque vous avez le mot « emballage », cela signifie que vous ne faites pas la version un, mais deux « composants » (ensemble de fichiers)

• un « développement » composante: assez grand, avec tous les fichiers dont vous avez besoin
• un composant « distrib »: assez petit, avec quelques fichiers compressés en elle.

Il implique:

• façon automatique pour construire et version Distrib composants (en comprimant ces fichiers et de les stocker)
• façon automatique pour copier ce composant distrib (représentant la version compressée de votre version packagée), le décompresser et le rsynch-it avec la plateforme de test ou de production.

De cette façon, vous ne pas simplement « dupliquer » les changements, mais garder une trace d'une configuration complète réelle:

• prêt à être déployé sur une autre plate-forme
• ou utilisé pour rsynch un courant déployé paquet.